In the process of resolving the issue they recommended the bridge configuration and reconfigured the firewall for me. I find it quite hard to believe that the bridge was recommended. Maybe fixed so it worked, but not recommended. On what interface did you make the VLANs? I do not find it hard to believe that it's that bridge getting in the way somehow. I would get rid of it. This is much easier-done from an interface that is NOT a member of the bridge as it is trivial to lock yourself out playing around with Layer 2 there. I would: In the Web GUI got to Interfaces > (assign), Bridges Edit the bridge. Remove the interface corresponding to igb3 from the bridge. Edit the igb4 interface, Enable it, set an IP address in some throwaway IP network. Add a pass any any firewall rule there Statically configure your management laptop on the same network and directly-connect it to igb4. Log into the web gui there. Patch the LAN into igb2 instead Go to Interfaces > (assign), Bridges Edit the bridge. Remove the interface corresponding to igb1 from the bridge. Go to Interfaces > (assign) Change the assignment for LAN from BRIDGE0 to igb0. Patch LAN from igb2 back to igb0. You should now be off the bridge interface. Connect back to your LAN switch and you should get DHCP, etc if configured and log into the web gui there. Go to Interfaces > (assign), Bridges and delete the bridge and bid it a hearty good riddance. Lots of possibilities for lockout and downtime so you probably want to do this in a maintenance window. One of several reasons bridging router interfaces like that is undesirable.

So you have user in Vlan A doing a copy from vlan B to vlan C.. With a copy paste highlight file in B and paste on machine in C.. So yeah all those copies go through PC on vlan A.. Through multiple hairpins..  Not going to be good.. Talk about a hairpin nightmare.. your flowing all the traffic through pfsense multiple times, and the pc multiple times all over the same interfaces.. If they need to move a file from B to C.. Then rdp to B or C and copy or paste the file directly - don't have it flow through the PC on A..  Is that better??  Either way that many vlans that all do intervlan traffic using 1 interface is going to be horrible..  Hope your devices are all set to use 10mbps and your trunk is gig.. [image: trafficflow.png] [image: trafficflow.png_thumb]

No worries, the progress remains firmly undisturbed by any complaints here or elsewhere.  ;D ::)

@Fabio72: For the first problem, check dns. In my case the pfsense resolver was unable to work on the backup WAN. The solution should be activate default gateway switching OR set dns resolver in forwarding mode. That's because you set policy routing for LAN but pfsense itself does not follow the LAN rules. Howtos are not so clear because there's a mix of older and newer approaches to multiwan. Thanks, that actually solved the first problem, now the second problem still remains

Your first page shows that link to 192.168.0/24 is via bge0, your next posts shows its out your vpn connection ovpnc1 So if you need to go out ovpnc1 to get there, and you have it on your bge0 which looks to have a 10.20.61/24 network on it - then yeah its not going to work. [image: differentroutes.png] [image: differentroutes.png_thumb]

State Killing on Gateway Failure Flush all states when a gateway goes down The monitoring process will flush all states when a gateway goes down if this box is checked. The problem I have with this is when one gateway goes down ALL states on ALL gateways are killed. Like I said I have a primary WAN that is fiber and an unreliable Comcast connection as secondary. When this option is enabled and the Comcast connection goes down the calls going through the primary connection drop.

I've determined I needed to do this with VLANS.  Here is an excellent reference that really help me get things configured.

I got it working for now. Thanks guys. Working on firewall rules at this time.

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!