OPNsense Forum
English Forums => General Discussion => Topic started by: gflasins on September 29, 2015, 04:09:53 pm
-
I updated two opnsense devices using the built-in update from the console and on one of them I lost the ability to connect to the web interface. They are both running 15.7.14 and have very similar configurations. Both web interfaces were accessible before the updates. Can someone tell me some troubleshooting steps? I'm not a big linux user and I'm kind of at a loss for what to do beyond the obvious "select option 11 to restart the web service" step. Thanks.
-
On the "broken" one choose (8) to go to the shell and run:
# opnsense-update -pf
Does that bring back the GUI? May have to try (11) afterwards, too.
-
That doesn't seem to have fixed the problem. However, I was able to access the web interface through the LAN connection today since I'm on site. Still can't get to it from anything on the WAN, though.
-
This sounds odd. It may just be a configuration issue and I am assuming a reboot of the offending firewall did not help?
-
No. I've tried rebooting. I've done a side-by-side comparison of the two routers to find any discrepancies (other than the obvious like IP address) and I don't see anything that would be causing this. I had a colleague look at it, too. I even asked around to see if there were any networking changes made. Nothing. We're baffled.
-
So am I. How should we proceed? A checklist:
o The webserver is running... # pgrep lighttpd
o The webserver is reachable via at least one interface.
o Firewall logs show no block rule for GUI access via WAN.
o If there is traffic being blocked, click symbol in first column to reveal which rule blocks.
o Port and NAT for GUI active? HTTP or HTTPS?
o Is WAN an internal network? IPv4 or IPv6. Bogons and private stuff being blocked by default?
-
Okay, I've narrowed this down a bit. For some reason traffic is blocked from the WAN that the router is connected to. That makes no sense as the only change that occurred was an update of the Opnsense router. Still can't find a local firewall reason for that, but I'm continuing to troubleshoot. Thanks for all the input!
-
I'm having the same problem...... Watching this thread with interest.
-
o The webserver is running... # pgrep lighttpd
- This returns a number. Also, it appears to be running anyway since it's accessible from the LAN.
o The webserver is reachable via at least one interface.
- Accessible from LAN.
o Firewall logs show no block rule for GUI access via WAN.
- Can't find any block rule.
o If there is traffic being blocked, click symbol in first column to reveal which rule blocks.
o Port and NAT for GUI active? HTTP or HTTPS?
- Appears to be the case? Both HTTP and HTTPS.
o Is WAN an internal network? IPv4 or IPv6. Bogons and private stuff being blocked by default?
- WAN is a public network. IPv4. Web interface is not accessible from other IPs on the WAN.
- I know I've seen the bogon option before, but I'm not finding it again. I feel like it's buried at the bottom of another config. page. Someone remind me?
-
Most items pass the check list, still a bit weird. Bogon and private options are under Interfaces -> WAN at the bottom, but I am guessing they won't help in this case.
Does pinging the WAN IP work from the outside?
-
I just realised pinging requires enabling ICMP on WAN. ;)
-
"Block private networks" and "block bogon networks" are both unchecked. (This is true on both routers.)
-
There's something obvious we're both missing, either es subtlety in the config that is different or the network setup itself. Can you please elaborate?
-
I'd elaborate if I could. I'm kind of getting to the point of giving up since it's not effecting functionality, especially since several technicians have looked at this already.
-
Is the box still active? Have you tried to restore the box with the other box's config? Have you tried to swap place to see if the box or the network setup is the root cause? So many things to try. Alternatively, Deciso offers support if this is still of (business) interest.