What I suggested completely bypasses the round-robin configuration since you are explicitly policy routing to that WAN. As long as those policy routing rules are higher in the rule set.

Use frr instead of OpenBGPd. It appears to be fixed if using that combination.

@chpalmer: @rast4man: Now that I think about it, bridging the modem would lose my NanoBeam bridge over 5ghz. This is how I currently get my network so that's a bust. Using their modems built in Wifi? Yes. Since I rely on the NanoBeam for the bridge, if I put the modem in bridge, I'd have to put an AP on their side and recreate the bridge. I don't have the ability to hard wire their modem to my equipment. Essentially, this is a huge PITA.

Thank’s for yours replies, I try it.

Thank you very much for a very clear answer. Cheers

What? Does that have to do with anything?  Outbound nat has zero to do with access to other segments.. Pfsense doesn't even nat between networks on the lan side.  It only would nat between a lan side interface and a wan (one with gateway set on it directly).. I attach my outbound nat rules so that you can figure it out.. even if comments are in italian :-) 192.168.10.0/24 is a subnet leading via an Ubiquiti Antenna to my house. To let this have access to the OpenVPN via the pfbox i had to create that rule.. otherwise… no result... 192.168.4.0/24 is another subnet under which i have a couple of machines that need access to the VPN as well.. so i natted it... You cold have 100's of vlans on your switch.. .Doesn't make it layer 3 routing… Did you set a SVI (Switched Virtual Interface) on these vlans? Ie set an IP address on these vlans? I set 2 different virtual interfaces on the respective Vlans and gave them IP address, ending .1 for each subnet. I imagined that natting was not the top, but creating the firewall rules for each interface was not enough to allow traffic, for example, from "madhouse" to "openvpn". And actually, from the other end of the vpn i cant access "madhouse"… the vpn tunnels in 192.168.30.0/24, and the subnet on the other hand is 192.168.0.0/24, so not conflicting with any other of the interfaces... [image: NAT.png] [image: NAT.png_thumb]

Thanks. I will give it a try  :)

Thank you for your reply, I really appreciate. I've double/triple checked and the pfsense/os interface names are following on both nodes: WAN: vmx0 (WAN1) LAN: vmx2 (LAN) OPT1: vmx1 (WAN2) OPT2: vmx3 (SYNC) OPT3: vmx4 (DMZ) not used yet edit: LAN and WAN2 description swapped.

Faced the same issue. Can't avoid using gateway switching since pfsense itself will not be able to reach Internet in this case. Any suggestions?

Thanks for the info and all the help. Cheers. 8)

That would be great. Might see if I can spin up a test setup & see what happens.

Thank you!  :D Your help will always be appreciated here, at least by me anyway! I'm happy to share anytime! I'm one of the odd-balls that is doing everything with actual hardware and NO Virtualization… I hear ya; learning new information all the time! However this is all new to me and this community has been absolutely crucial! I'm the type of person that simply loves to learn something new anytime or even all the time!  :D Good luck to you as well in your endeavors!

Should this be listed as a bug, or is this an intended feature?  If UDP maintains state longer than the default timeout, it seems like a bug.