I do. I needed to add an early rule that passes traffic destined for This Firewall. With that, all is good.

Thank you.

@ibeadam To answer my own query as it may just help others.

Found an old Microserver. Installed pfsense. Put Huawei in to bridge mode. Internet just worked. Set up L2TP client on pfsense. Set routing default to use it. External IP address as if by magic.

Thanks. The interesting thing here is that I can remote into the network using the IP reported by the cellular modem on its internal status page. But, on failover, the IP being reported by the Dynamic DNS service and "What's my IP" is different than the IP being reported by the cellular modem. On failover, the IP address does change from my WAN address to another IP, this new IP address does get reported by the Dynamic DNS service, its just not the same IP as the modem displays on its internal status page.

In other words, if the cellular modem was being reported to my Dynamic DNS service then I'd be able to remote into the network on failover. But, as its now stands, I have no way (that I know of) of determining the actual IP address of the cellular modem on failover. So, there something odd going on with how the IP is being determined.

@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.