that is still not a route.. But sure if device answers (your modem) for an IP on your network then it would show in the mac address table. Here I tried pinging a bunch of different addresses in my /23 and you can see them now in my arp table, with the mac address of my modem. [image: 1581159820494-arptablemodem.jpg] If you had done some sort of scan of /22 then yeah you would of see mac address of your cable modem for all of the IPs.

It's similar, but different, since I am talking about the phase 2 selectors, not phase 1 counterparts. The point with phase 2 selectors on VTI is, that they should be ignored for routing. pfSense seems not to support defining routes just via a particular interface, but relies on the remote gateway IP that is derived from the phase 2 network. Consequently, the adjacent 0.0.0.0/0 "network" is parsed as the default route in my case. At least that's my theory.

@johnpoz Sorry to bump this thread but I have related question. Does this downstream router need to be on its own network, or can it just stay on a VLAN different from the clients I need to route? Let's say I already have a SERVICES VLAN, none of the hosts on this VLAN will be routed via this Wireguard gateway. Would placing this downstream router on this VLAN solve the asymmetric routing issue you explained?

You could send some of that /27 across OpenVPN to the other site if the /27 is routed to you. If the interface is a /27 that's going to be much more difficult.

I just figured it out. I wasn't setting the PVID of the switch ports correctly. Once I set the PVID of the untagged ports to the same VLAN ID as what I wanted the packets entering those ports tagged as, as I was able to connect to the cameras. Yet again the need to be explicit in your instructions proves itself.

Just needed to add the subnet im trying to reach to my Windows 10 VPN connection and it's now working: Add-VpnConnectionRoute -ConnectionName "VPN Name" -DestinationPrefix 10.xx.xx.0/22 -Passthru

Just uploaded a video, no, the monitor IP is default. Also, I'm not sure why both gateways show up as online, shouldn't one of them stay in "pending" since they're not on the same tier? I did try using different monitor IP such as google dns servers, but that didn't fix the problem.

I determined that sometime in the last year my ISP (Cox) made it so I can send a hint for a 56-bit prefix and use track interface to obtain a separate /64 for each of my VLANs. This didn't work a year ago but it does now. Oddly enough Cox tech support still says they only issue 64-bit prefixes. However that's not what I am seeing now.

I found the problem, and It was not easy, under firewall -> rules, you have to edit (or create) the rule "default allow LAN to any rule", this one is created in the default LAN by default, either copy the data or create a new one based on that one, but this one is for the second LAN, for my example, the LAN_DMZ, and here is where the tricky part comes: you have to display the advanced options, and there almost at the end there is the possibility to specify the gateway: Gateway Leave as 'default' to use the system routing table. Or choose a gateway to utilize policy based routing. Gateway selection is not valid for "IPV4+IPV6" address family. For my example I put as gateway the WAN_DMZ, as this WAN is dedicated to our external services, so all the traffic in this LAN will be redirected to that WAN interface. The rest is to add a rule so from LAN1 I can manage the machines in the LAN_DMZ (for maintenance purposes). Now a port fordwarding will map the selected port from the outside to the port from the machines in the LAN_DMZ. Another tricky point is that the access from the WAN_DMZ work but if you try to access to the public IP address in the WAN_DMZ from inside the LANs, It will fail. For that you have to add another rule to redirect the traffic, this time from the LAN instead of the WAN_DMZ. This happens because the external IP address is transformed (NAT) to the internal IP addess, and there is no rule to access to the port that It's mapped to access the service from the outside. This means, you have to MAP from WAN_DMZ 8080 -> your host 80 but also from LAN1 8080 (self firewall) to your host 80. With these two rules and the trick option for selecting the gateway the work was done and everything works as expected. Thank you

https://www.netgate.com/resources/videos/nat-on-pfsense-23.html

How did you setup your transit in the end? Trying to do the same and it isn't working. Currently using management as my transit. Are you able to describe how you setup the transit as I have contacted netgear and they don't seem to have a concept of a transit vlan and are asking me to create a vlan on pfsense for it. Pfsense: Pfsense lan default gateway 192.168.10.246 Created gateway 192.168.10.1 Inc static routes etc on pfsense under routing. Switch: Created management vlan (15) 192.168.15.0 Ip: 192.168.15.2 Default gateway: 192.168.15.1 but it won't let me set it and defaults to 0.0.0.0 Static route also changes to 192.168.15.1 rarther than 192.168.10.246 Created vlan (10) 192.168.10.0 Default gateway 192.168.10.1 Untagged a port for all vlans and set its pvid to 10. Plugged the pfsense lan port into this switch port (transit link) I'm clearly not doing it right please help.

@jimp Deploying the patch, I have encounter an issue when ipsec rules generation is not disabled, since the rules are taking all pfsense traffic (self) for the same destination. I will add into the patch a test in filter.inc to disable the ipsec rules generation just for those phases 1. The option would be, in summary, "allows you to use duplicate gateways but you are responsible for the routing settings". If you prefer, I can also change the from clause from the generated rules to use the phase 1 interface address instead of (self) when this option is enabled.