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!
You must log in or register to comment.
Could it be an MTU issue? Networking van be weird if packets get fragmented unexpectedly, but I see this mostly for IKEv2 and other VPN Services. Try to lower your MTU on the WAN side Maybe?
Gave it a shot (1472) but no luck.
Precision guesswork here, but I’ve had nginx (not on opnsense) redirecting me to the
defaulthost quite a few times recently - all times it was me cocking up its config. It could be that nginx is waiting for the actual target until it times out and then just gives a your opnsense gui as the most reasonable response.I’d start checking its config. Or pasting it here, after removing secrets, it any.
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.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters DHCP Dynamic Host Configuration Protocol, automates assignment of IPs when connecting to a network HTTP Hypertext Transfer Protocol, the Web IP Internet Protocol VPN Virtual Private Network nginx Popular HTTP server
4 acronyms in this thread; the most compressed thread commented on today has 7 acronyms.
[Thread #790 for this sub, first seen 8th Jun 2024, 04:35] [FAQ] [Full list] [Contact] [Source code]
>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 is critical info. You have been configured for IP Passthrough for exactly however long ago you updated.
I’m not sure what you’re suggesting but I am confident that IP Passthrough was set to DHCP Fixed on the BGW320-505 with the MAC of the Opnsense NIC before and after the Opnsense upgrade, if that helps.
@bluetrain
> 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!).This corroborates my assessment. You were previously in a double NAT situation. You saw your WAN IP on your gateway because your WAN IP was your gateway, not your interface IP. You now see the ISP’s head end IP as the gateway due to IP passthru
Any suggestions on what to try?
@bluetrain
> The strongest example I’ve uncovered of this is, from my WAN (or LAN) directly accessing my WAN IP.What have you been testing from? Laptop pointed to LAN IP, laptop pointed to WAN IP, and cellphone with WiFi disabled pointed to WAN IP?
Good question.
LAN device(s) pointed to WAN IP. LAN devices pointed to LAN IPs resolve fine and display webserver content. Cellphone (no WiFi) pointed to WAN IP does not exhibit the appended Opnsense webui port behavior.
