While you researching tcpdump, pfSense has an option for logging matching rules (this is configured on rule itself). Try it.

Not seeing where your lan network is called out.. is it also 192.168.1/24??  Or some other sub of 192.168.1 that overlaps with 192.168.1/24 - if so then NO you can not do it that way.. You for sure could have multiple routes to different IPs on your wan that is your transit network..  But you can not expect it to work if your lan side clients are on 192.168.1/?  And you want them to go to the internet or this other 10.200 network

this is a hairpinned vlan setup, in production, around 300 clients behind it. "LAN" is the parent interface for all the vlans. (oh yea, pfsense is running on esxi) [image: 1OMSm2M.png]

Hi PacketLoss I guess so far my biggest issue seems to be the return route. The router is effectively hosting the core of the network, an SVI for each vlan etc. I can either set the default route to the be the IP of the LAN interface of the pfSense or I can use PBR to point vlans to the LAN interface of the pfSense box. That works fine and traffic goes out. However, my issue arrises when it comes back in, the router because its directly connected to every VLAN can just pass the packet back to the host completely bypassing the pfSense WAN port thus creating an asymmetric route which pfSense then goes on to block further traffic. How do you get around the return route issue for packets coming back in. Currently in my design im only using 1 internet connection which is sitting in the mgmt vlan. The current configuration is: pfSense WAN is in vlan 102 pfSense LAN is in vlan 101 I am using a 3650 as my router, the internet connection is in vlan 100. I am using ip route  0.0.0.0 0.0.0.0 10.59.219.10 (pfSense LAN) and then the pfSense WAN has a router IP (10.59.219.2 vlan 100). Going from LAN -> Internet or LAN <-> LAN is fine, its when the packet comes back in from the router interface in vlan 100, it bypasses the pfSense box and sends it directly to the client vlan (21,22,23 etc) thus thats where the asymmetric routing shows up. How do I force the packets to go back via the WAN interface of the pfSense? Thanks

@jimp: System > Advanced, Firewall & NAT tab, check "Bypass firewall rules for traffic on the same interface" See also: https://doc.pfsense.org/index.php/Asymmetric_Routing_and_Firewall_Rules https://doc.pfsense.org/index.php/Why_do_my_logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection "Bypass firewall rules for traffic on the same interface" was already checked. Maybe it's not working. I setup a manual rule with sloppy states and it appears to be fixed! There were no rules for this route before - simply a static route and gateway in System > Routing. It really does sound like that option isn't working as it did in older pfSense versions. Thanks much! Months of changing routes directly on workstations can finally be retired!

Is the wireless handled by an external access point on the local network? Or is a wireless card in the firewall? That would make a massive difference in if or how the goal can be achieved.

Yes, that is another option if you can reliably identify all the traffic.

My laptop is wire connected to the same switch. And an another router makes the Wi-Fi. I have some problems here, but first I need to set up my laptop connection.

The only thing that will be effective there is WANGroup. It will match all traffic. The other rules will never be hit. As is evidenced by the traffic counters on them. If you want different behavior, delete the other two rules.

Because they are covering all the bases. You only need one failover group to get one failover behavior (ie WAN1 (Tier 1) to WAN2 (Tier 2)).

Thanks. I originally chose "General" as this is a crossover topic - both DYN and multi-wan. My question is more about DYN, but your answer was spot-on! :)

That's called policy routing https://doc.pfsense.org/index.php/What_is_policy_routing https://doc.pfsense.org/index.php/Multi-WAN#Policy_Route_Negation

nope just change the wan interface to static vs dhcp.

What version are you running? On 2.3/2.4, dpinger doesn't immediately bring the gateway back up on the first successful ping, it has to return to below-threshold levels before it is considered 'up'. If it's not stable when it's within the configured parameters, fix the configured parameters to suit your circuit.