I finally decided to upgrade my opnsense box after a couple of years of deferring and, in the heat of the moment, forgot to double-check I had configuration backups. After the upgrade to OPNsense 23.1.11_2-amd64 (FreeBSD 13.1-RELEASE-p8), there were some issues with LAN clients accessing the WAN that I solved by resetting to default settings. (I have not modified much, so it’s somewhat trivial to add back aliases and rules.)

Now, however, I am facing a novel problem where some port forwarded services work perfectly, while others do not. Chief among them is that my webserver (80/443) is no longer resolving–despite the ports showing as open. I am running Nginx Proxy Manager to handle the various web services on my LAN and the setup has served me well for years. I have made no changes to Nginx PM, to my port forwarding rules, or to the individual services and their boxes. Put simply, everything was working 100% without issue until I foolishly upgraded.

I suspect the issue is a double NAT issue with my godawful BGW320-505 gateway. I have had this configured to IP passthrough mode without issue for years. But, after the Opnsense upgrade (and defaults), I did notice that my gateways were configured differently. Previously, my upstream WAN gateway was the IP address of the BGW320-505 box. Now, my upstream WAN gateway is my WAN IP address with a .1 substituted for the final digit. This doesn’t seem to be an issue and comports with everyone’s guides online for configured IP passthrough mode on the BGW320-505 and, in fact, Opnsense does show my WAN IP address as my actual address (something it did not before!).

Despite all of the above, there seems to be some weird DNS issue/NAT issue. The strongest example I’ve uncovered of this is, from my WAN (or LAN) directly accessing my WAN IP. While this should show me my http-facing webserver, the request times out for a while then eventually resolves to a 404 page but–and this is the bizarre part–not before appending :440 (my webgui port for Opnsense) to the WAN IP in the address bar. I’m hoping that is the key to solving this but, after more than 12 hours spent researching this and trying various solutions available on forums/reddit/etc., I have not found anything to work.

Please help!

  • bluetrain@lemm.eeOP
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 months ago

    So I’ve tried spinning up new turnkey containers for nginx to eliminate this as a potential issue. Everything can be accessed internally but new or old config alike, it’s the same inaccessible from WAN issue.