Regarding the first problem, setting the mtu and the mss really solved my problem. Thank you. I just set the MTU to 1400 and the MSS to 1360. How can i easily find out the highest i can get?

@Rico said in Multi WAN Routing Split: Check out the great Multi WAN hangout by jimp: https://www.netgate.com/resources/videos/multi-wan-on-pfsense-23.html -Rico Thanks, exactly what i needed. Was thinking i needed to add the gateway to the WAN rules....doh!

Routes are not to be mixed up with Firewall rules. Firewall rules are for traffic that comes IN to an interface. pfSense is the "inside" in this point of view. Firewall rules do not apply to outgoing traffic (just forget about floating rules right now, themselves rarely being used) To be sure that firewall rules are not an issue, put on any (V)LAN type interface a first rule that is a pass-all rule. Routes : every LAN type network that is not declared as a WAN type can reach other because an (LAN's) network mask matches. If there is no match with an existing local network, then a WAN type network is used to send the traffic out to have the traffic being handled by an upstream router. In the vast majority of all possible network scenarios, there is no need to manipulate the routing table. I know, I'm probably not answering your question. What I want to say is : routing tables is never a problem. They can seem to be a problem if the network structure is fckd up severely. In that case the network's logical structure needs to be redone. Not the routing table. Example : Like you, I'm using the OpenVPN server build into to access my companie's nerwork. My LAN is 192.168.1.1/24 - all companie's PC's, printers, file servers, backup units, etc are on this LAN. A second LAN network uses 192.168.2.1/24 My VPN tunnel network is a third local network 192168.3.1/24 (and surely not 192.168.1.1/24 which will conflict with LAN - breaking the routing) So, when I connect remotely, my PC @home will have a 192.168.3.2 IP. Traffic going to my OpenVPN server comes into pfSense and can go 192.168.1.0/24 which is local Anywhere else : the Internet, so it's leaving on the WAN interface.

I been having this Issue for a long time as well, It will not fail back to the primary circuit, i have to go to the secondary circuit and mark getaway as down and force to fail over.

I think what I'm after is a gateway between guest and WAN. Usually the last visible rule created is what's allowed out. I say visible because the actual last rule is to block everything (built in / default rule). So if you create a pass rule at the end of the list to allow, (your previous rules will block to LAN, WiFi, VPN) then you should be sweet.

I would use Split DNS there.

I fixed the problem by removing the virtual ip, then putting it back in.

@mohkhalifa said in Gateways drop: Problem Solved by un-check "Flush all states when a gateway goes down" in the advanced setting. That box is not checked on my pfSense. I think most of that is still set at the defaults. Never had a reason to change it. At some point if all this doesn't get resolved, I'll just revert to pfSense 2.4.4 p3 till it's fixed.

@viragomann Thanks alot, this worked. So dumb of me :)

@Rico The video you pointed me to was very useful, and I now have MultiWAN set up, mostly working. The two weirdnesses I have are: I have a group set with Tier 1 on my Fiber connection, and Tier 2 on my cable connection. My LAN uses this group. When I pull the cable on my Fiber it seems that TCP connections fail over, but things like ping (ICMP etc) out the failed over to WAN do not. I can't see where that is set :-( Second issue is that I have my mail server in a subnet called DMZ, off it's own port from the router. It is set to have it's WAN traffic to only go to the cable connection - which works. What I cannot do is get it to make connections to the LAN. Even if I set up a rule for DMZ-net to LAN-net all I can't ping or ssh from DMZ. I really need/want just Bonjour and ping to be able to initiate DMZ->LAN but I can't even get DMZ-net -> LAN-net all to work, even though on the LAN I have LAN-NET - RFC1918 set and working, and I did try it as LAN-net -> DMZ-net and that works too. Thank you Cheers, Liam

Regarding the NordVPN issue, i use 2 NordVPN connections and one VPN connection from another provider at the same time on one pfSense gateway. I have checked the "Don't pull routes" and "Don't add/remove routes" as those would be problematic with the pfSense configuration. I have not experienced any DNS resolver issues. As it is now, i only have one internet connection. The Netflix issue have been described in other posts using pfBlockerNG. Hope it helps a little.

Right. Chances are the ISP was intermittently forwarding the traffic to you so you were therefore intermittently able to forward the traffic inward. Can only work on what you receive. Glad it looks like they found it.

@Jeonetgate Having this same issue as well on 2.4.4p3. No flush settings are enabled. Traffic is getting blocked by this default rule. ICMP traffic about 75% of it gets lost due to this. Do have two WANs configured.

I've switched over to AON NAT now, I didn't originally see all of the rules. Turned out that I didn't have an upstream gateway set. Once Set I see the rules automatically generated. I added my rule to disable NAT to create a routed network from my two servers. I still see an issue however. Can anyone suggest a fix or maybe a better way to achieve what I'm trying to do? I'll try and detail what the issue is... [image: 1585176123237-screen-shot-2020-03-25-at-3.41.24-pm.png] So it seems like it's an L2 issue... Here are the test details... Ping from Site1 Nested ESXi VM fails... The path is: Request: "n-esx1" -> "p-esx1" -> "p-esx2" -> "n-esx7" Reply: "n-esx7" -> "p-esx2" -> dfGW.... where I need it to go back to "p-esx1" n=Nested p=Physical [root@stevelab-n-esx1:/vmfs/volumes] ping 192.168.2.17 PING 192.168.2.17 (192.168.2.17): 56 data bytes For reference... Site1 WAN: 60:ac:a6 Site2 WAN: 7b:81:88 WAN GW: ff:fd:90 [root@stevelab-n-esx1:/vmfs/volumes] ping 192.168.2.17 PING 192.168.2.17 (192.168.2.17): 56 data bytes Destination Nested ESXi sees the request and replies to the request. [root@stevelab-n-esx7:/vmfs/volumes/3a3b5bc8-88bd4760] pktcap-uw --uplink vmnic0 --dir 2 --ip 192.168.1.11 -o - | tcpdump-uw -enr - 22:23:35.839598 00:0c:29:7b:81:9c > 00:0c:29:35:9b:0d, ethertype IPv4 (0x0800), length 98: 192.168.1.11 > 192.168.2.17: ICMP echo request, id 55660, seq 0, length 64 22:23:35.839758 00:0c:29:35:9b:0d > 00:0c:29:7b:81:9c, ethertype IPv4 (0x0800), length 98: 192.168.2.17 > 192.168.1.11: ICMP echo reply, id 55660, seq 0, length 64 Then the Physical host is sending the reply to the WAN GW. It doesn't send it back from where it came... [root@stevelab-p-esx2:/vmfs/volumes] pktcap-uw --uplink vmnic0 --dir 2 --ip 192.168.1.11 -o - | tcpdump-uw -enr – 22:24:09.239994 00:0c:29:60:ac:a6 > 00:0c:29:7b:81:88, ethertype IPv4 (0x0800), length 98: 192.168.1.11 > 192.168.2.17: ICMP echo request, id 55660, seq 18, length 64 22:24:09.240589 00:0c:29:7b:81:88 > 00:08:e3:ff:fd:90, ethertype IPv4 (0x0800), length 98: 192.168.2.17 > 192.168.1.11: ICMP echo reply, id 55660, seq 18, length 64 22:24:10.241698 00:0c:29:60:ac:a6 > 00:0c:29:7b:81:88, ethertype IPv4 (0x0800), length 98: 192.168.1.11 > 192.168.2.17: ICMP echo request, id 55660, seq 19, length 64 22:24:10.242331 00:0c:29:7b:81:88 > 00:08:e3:ff:fd:90, ethertype IPv4 (0x0800), length 98: 192.168.2.17 > 192.168.1.11: ICMP echo reply, id 55660, seq 19, length 64 [root@stevelab-p-esx2:/vmfs/volumes] esxcli network ip neighbor list Neighbor Mac Address Vmknic Expiry State Type 10.33.72.65 00:0c:29:60:ac:a6 vmk0 928 sec Unknown 10.33.72.64 00:0c:29:8c:15:73 vmk0 1196 sec Unknown 10.33.72.62 00:11:32:a6:9a:3f vmk0 1020 sec Unknown 10.33.75.253 00:08:e3:ff:fd:90 vmk0 1198 sec Unknown Reply never arrives back at Site1 (Of course, because the packet went to the WAN GW of Site2. [root@stevelab-p-esx1:~] pktcap-uw --uplink vmnic0 --dir 2 --ip 192.168.1.11 -o - | tcpdump-uw -enr - 22:24:24.270369 00:0c:29:60:ac:a6 > 00:0c:29:7b:81:88, ethertype IPv4 (0x0800), length 98: 192.168.1.11 > 192.168.2.17: ICMP echo request, id 55660, seq 33, length 64 22:24:25.271133 00:0c:29:60:ac:a6 > 00:0c:29:7b:81:88, ethertype IPv4 (0x0800), length 98: 192.168.1.11 > 192.168.2.17: ICMP echo request, id 55660, seq 34, length 64 22:24:26.271396 00:0c:29:60:ac:a6 > 00:0c:29:7b:81:88, ethertype IPv4 (0x0800), length 98: 192.168.1.11 > 192.168.2.17: ICMP echo request, id 55660, seq 35, length 64 Willing to try just about anything... Thanks.