Just started getting this error again. Any thoughts on cause / how to address?

It would make sense in something like a colo or metro-e environment. Or anywhere where RFC1918 is the exception not the rule. Which should be everywhere, actually.

routerA and routerB is activated dhcp server. That's error prone. Don't use DHCP to assign IPs for a WAN-type interface if you can avoid it. Use static IPs that are not in use by the IP Pool of net A or net B and aren't in use. Also those two interfaces need the gateways router A/B. You should have used WAN for VLAN100 on em0 and WAN2 for VLAN200 on em0. Defining WAN without anything may result in errors as it is the default internal WAN IF.

Port forward WAN connections like this: Destination: 38.yyy.XXX.240 port 443 Target IP 192.168.xxx.22 port 443 Destination: 38.yyy.XXX.240 port 49700 NAT Target IP 192.168.xxx.22 port 49700 Destination: 38.yyy.XXX.241 port 443 Target IP 192.168.xxx.21 port 443 Destination: 38.yyy.XXX.241 port 49500 Target IP 192.168.xxx.21 port 49500 Destination: 38.yyy.XXX.242 port 443 Target IP 192.168.xxx.20 port 443 Destination: 38.yyy.XXX.242 port 49000 Target IP 192.168.xxx.20 port 49000

Update: it got much better when I replaced the Fritz!box 7582 with a Zyxel XMG3927 this morning. Tests still in progress, but in this case it seems pfSense was not the issue at all. [2.4.4-RELEASE][admin@pf.insign]/root: ping -c 10 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=60 time=4.159 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=3.865 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=4.053 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=4.342 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=60 time=3.719 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=60 time=3.745 ms 64 bytes from 1.1.1.1: icmp_seq=6 ttl=60 time=3.957 ms 64 bytes from 1.1.1.1: icmp_seq=7 ttl=60 time=3.731 ms 64 bytes from 1.1.1.1: icmp_seq=8 ttl=60 time=3.973 ms 64 bytes from 1.1.1.1: icmp_seq=9 ttl=60 time=4.102 ms --- 1.1.1.1 ping statistics --- 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 3.719/3.965/4.342/0.195 ms (until now it was around 60-100ms for any external IP).

It's not simple. It's asymmetric. It breaks TCP through stateful firewalls as you have found out. I can't make anything out of that "diagram". I'll need more detail. Like interface addresses, subnets, etc.

Easy. Setup VLAN 4094 on the interface, you'll plug in WAN. Switch/configure WAN to <physical interface>:4094 configure static IP as per your connection details set up LAN as per your LAN details with pfSense getting .17 enter NAT settings, go to Tab outbound switch to manual mode remove all NAT entries besides the 127.0.0.x ones so you have NO NAT rules besides the localhost ones. enter Firewall rules create a WAN rule "block from any to firewall address port any" rule so no access to your firewall from the outside internet is possible create a WAN "pass any to LAN net" rule to allow anything else check LAN that "pass any to any" (default) is still there. if you want to manage pfSense via a special third interface you should use that as "lan" and setup the third interface as "DMZ" or "SRV" and create a block firewall address and pass anything else rule there. -> Now you have no NATting from LAN to WAN and pass traffic from WAN->LAN and LAN->WAN without blocking anything. So you're routing only. I'd advise to go the extra mile and add a third interface and use a dedicated interface to manage your pfSense so to not allow traffic to the webUI from WAN or you "server network".

SOLVED The following LAN rule solved the problem StatesProtocol Source Port Destination Port Gateway Queue Schedule Description 66/4.92 MiB IPv4* 10.10.122.0/24 * * * * none Thanks to viragoman !!!

@roniskitea Please also describe the situation What are the antennas?

Check https://www.netgate.com/resources/videos/pfsense-244-short-topics.html (32:25). -Rico

I rebooted the clients on the remote computers and reinitiate the connections and I am able to reach them after the openVPN connections were established. So I did not do much really. Meanwhile the error "static route 192.168.101.1 (mask 0xffffffff) --> 192.168.101.1 impossibly lacks ifp" is still present in the status/system logs/system/routing. I guess it has nothing to do with the problem I faced. Its just a noise.

Perfect! Thanks, I didn't think of browsing the system advanced settings. That's what I needed!

Hi talaverde, I am new at this, so please take whatever I say wit ha grain of salt or two, but you may want to examine the settings used to determine "Member down". The testing is usually based on a monitored IP. It is quite possible that transient instability is causing the rule to trigger your tier2 connection. Below are my settings from System -> Routing -> Gateways -> Edit. [image: 1560199687345-8a256521-9131-4277-9323-b3194b2a5788-image.png] If you are seeing more hits on your tier2 connection, you may need to adjust these values to account for any transient events that are triggering member-down.