@viragomann still requires that I remotely access the server, authenticate and then run the command which is a bit of a hassle. I also wanted to figure out a low-touch solution because we've had occasional WoL related issues at work. I was able to figure out a solution though. I created a DHCP reservation and static ARP entry on my client device network for an unused IP, 192.168.3.254 and MAC of FF:FF:FF:FF:FF:FF I then created a port forwarding rule on my server device subnet that redirects any UDP port 9 traffic destined for a device on the client device network to 192.168.3.254:9 . This causes the packet to be sent as broadcast.

@mw2u said in Access OpenVPN Client LAN from PFSense LAN: I installed openvpn client on windows and i checked if server push route and if i can access all devices behind that router and everything its good. So it's exactly the same as from the point of pfSense in B. pfSense can access all clients in A as well. Configure the Windows computer as a router, set it as default gateway and try to access A from the network behind it, if you want a true comparison.

@rod-it okay, got it, thanks.

@stijnrosaer said in Two WAN on one physical interface: I create a new vlan interface in PfSense whith DHCP I only get 0.0.0.0 as IP. Your second WAN connection must also be on a VLAN with the same ID as the one you set on pfSense. @stijnrosaer "One cable is connected between my modem and PfSense router (no extra are possible)" so do you have only ONE ISP CPE? (modem)??? from this, that you get a second WAN option, then there is no redundancy, so what do you need a second WAN for?

@vizi0n Ahh ... Now i see. But i doubt you can do that w. pfSense. I think you have either physical interfaces , or vlan tagged interfaces.

@viragomann I believe I found what I'm looking for. I have pfSense running in KVM under Ubuntu. I am going to use Libvirt to create 2 MacVTaps, instead of using a brctl bridge for the LAN connection. This should also be a faster connection than the linux bridge, according to some web articles. This is not a pfSense config issue, so may not be appropriate for this forum.

@satisifed-stew Great news! Glad you got it working, and sorry for sort of dropping off this thread. I'm a pretty casual forum user myself though and didn't have other ideas at the time. Thanks for following up for anyone who may have the same issue.

@katiasishost Looking here is a great start https://docs.netgate.com/pfsense/en/latest/index.html

Thank you, I’m banging my head on that issue for days, it would be nice if a mention was made in the documentation that reply traffic doesn’t go through PBR. My solution will be to setup a dedicated pfSense that will have a default route through VPN (OpenVPN in my case)

It wasn't supported back then. That is ancient.

@wtw I figured this out. I will create a new post with a resolution, since it encompases more than this specific post. This issue is closed.

@wtw This is not resolvable without changing OpenVPN to incorporate a 1:1 NAT to completely hide/isolate the conflict from pfSense. I consider this issue closed.

Was hoping to see some other responses, but clearing the rules and re-adding them in a specific order fixed my problem.

@chpalmer I tried. Unfortunately not.

@bhjitsense Here is a screenshot of where you can access those settings. Go to the location shown for your Cellular gateway. Then click on the "Display Advanced" button at the bottom. [image: 1607441357897-1b341c15-c6ba-4103-8ebf-b2d3dc33ab78-image.png] After expanding the advanced options, you will see the screen below. [image: 1607441746685-dbac8604-8e10-4a8f-8a70-cd96184f6613-image.png] In order to do what you're requesting, it sounds like you have to change the lower and upper Packet Loss threshold to 100. The Time Period is the time that the sampled data is averaged over. This is set to 1 minute (60000). Therefore, with that remaining with the default value, the 100 percent loss would have to occur for more than a minute since the 100 percent loss would be averaged in with the time before the failure and the time after the failure which had zero loss or close to it. At least that's what I would think. I could be wrong. Alternatively, you could do what I did and simply Disable Gateway Monitoring all together for the Cellular link. In my case I don't care if my backup Cell link is down since there's not much I could do if that happened to go down at the exact same time my main link went down anyway. That's just a scenario I'm willing to accept. If I wanted anything more bullet proof, I would invest the money in a much more robust solution.