@emc This issue has been fixed. NAT is working. It was a firewall issue in the PBX. I've whitelisted the IPs on the PBX's firewall and it works. Thank you everyone for your help.

@uz890ed so you disabled the 80 redirect on pfsense? Validate that pfsense is not listening on 80, simple sockstat [23.05.1-RELEASE][admin@sg4860.local.lan]/var/unbound: sockstat -l | grep :80 root nginx 90402 9 tcp4 *:80 *:* root nginx 90402 10 tcp6 *:80 *:* root nginx 90166 9 tcp4 *:80 *:* root nginx 90166 10 tcp6 *:80 *:* root nginx 90115 9 tcp4 *:80 *:* root nginx 90115 10 tcp6 *:80 *:* [23.05.1-RELEASE][admin@sg4860.local.lan]/var/unbound: I then turn off the redirection.. [image: 1688120946720-redirect.jpg] [23.05.1-RELEASE][admin@sg4860.local.lan]/var/unbound: sockstat -l | grep :80 [23.05.1-RELEASE][admin@sg4860.local.lan]/var/unbound:

Adding a network diagram, which I hope helps better describe the problem. [image: 1688062198225-dual-wan-issue-page-2.drawio.png]

@johnpoz thanks for the tip and i did the same test. Window on top is WAN and on the bottom is LAN. I just captured 10 packets from each interface and seems it is pretty fast so the culprit is not the NAT. [image: 1688031638913-a243489b-bc55-49e5-87b2-747bd73a304f-image.png] Found though two solutions but still not why it is happening. Remove Accept-Encoding header from the http request - result is very fast. Using a reverse proxy with https is still fast with and without the Accept-Encoding header

@viragomann Thank you very much for your answer and explanation, it worked.

@riahc8 hey there, shouldn't it be enough to work with rules? iE IF WAN allow WAN Net (network between pfsense and ISP router), all port, destination IP PC IF LAN allow LAN Net (or just IP pc), all port, destination WAN Net (or just IP PC2). That way, pfsense allows connecting net with pc (LAN) to net with pc2 (WAN) and vice versa. If that works, reconfigure so only the needed ports are allowed (and only needed clients in those nets). Or did the heat here damage my brain? :)

@JonathanLee hahahahhahahha lol

@viragomann To access it via VPN was my solution before, but then i realised that it is inconvenient to open a vpn connection on my phone 10 times a day. Sure i could stay connected all day long, i'm using WireGuard, but i don't like that either. To my knowledge the Home Assistant web interface is pretty secure and i've also enabled 2FA, but there is always a risk in making a web interface accessible to everyone.

I believed I explained the issue incorrectly. Here is the correction: I have a NAT for SMTP port 25 that works with no problem from external IP addresses (public IP) to a Virtual IP. But not from other WAN Virtual IPs. So I had to create a 1:1 rule for all IP aliases with NAT reflection enabled and now the NAT rule works connecting from other Virtual IPs. There is one problem: the destination host is showing the private IP of the source and not the public IP.

@riahc8 said in Setup pfSense behind a ISP router that cannot be put into bridge mode (Double NAT): @Dobby_ said in Setup pfSense behind a ISP router that cannot be put into bridge mode (Double NAT): Will the devices on the LAN interface on the pfSense work? pfSense DHCP: On ISP router DHCP: Off In my case, I need to leave both on as devices are hanging off the ISP router Related subject: https://forum.netgate.com/topic/180704/access-network-behind-a-double-nat

@viragomann Yes, it is, but in the customers environment they can't access the hosts native address from the 10.3.3 segment and I was hoping to replicate that limit as well.

@SteveITS Trying to use NAT to translate destination addresses. I have multiple connections over VPNs with colliding subnets that cannot change (and I have no control over those networks), and I need the addressing to be transparent. I want to be able to send traffic to 10.a.b.server on my side and translate it to the customersub.server as it goes out the ipsec tunnel.

OK, so it seems to be good news. Whatever is causing this bootup issue in 2.6 doesn't appear to be an issue in 2.7. There are other buggy behaviours (CARP, specifically seems to have some issues), but I would expect this as it's still in development. My only concern now is when 2.7 is actually likely to release. It's been coming for a while now.....