Can't connect to web interface when WAN is down
-
So you did a clean install.. walked through the wizard and it WORKS on reboot when wan it there.
You then reboot this working config with your wan disconnected and you can not get to web gui?? This is before you did any sort of import of your config???
-
So you did a clean install.. walked through the wizard and it WORKS on reboot when wan it there.
You then reboot this working config with your wan disconnected and you can not get to web gui?? This is before you did any sort of import of your config???
No, it works fine until I import my config. I just tried it again and discovered something new. If I pull the cable and reconnect it, the web ui actually works fine for a little while then it stops working (same symptoms as before (tcp retransmissions + eventual icmp unreachable)
But only after I Import my config.
So yeah, sometime in the next few evenings when I have time, I'm going to walk through my configuration and redo everything by hand and see if the problem still occurs to try to see if I can isolate it.
-
You sure your config isn't just changing the port the web gui listens on?
What are you lan rules? Can you ping your lan interface?
-
You sure your config isn't just changing the port the web gui listens on?
What are you lan rules? Can you ping your lan interface?
Yeah, i'm definitely sure it's not changing the port the web gui listens on. The LAN IP is pingable.
LAN rules are
the anti-lockout rule (allow all to the LAN adress port 443/80/22)
and the default outbound rules for ipv4 and ipv6 -
Interesting. At the console, 'pfctl -d' lets me connect. So it's definitely the firewall filtering out the connection. I don't get it though, the anti-lockout rule is enabled but with 0/0B state.
It seems like the firewall isn't recognizing the LAN Address destination.
The filter log isn't showing what's blocking it either
-
Hi,
Just a guess :
Can yuo login locally (using screen/keyboard) and check if sshd (the ssh demaon) and nginx (the GUI web server) are bound to your local LAN 'pfSEnse' IP when using the 172.x.x.x ? -
Just a guess :
Can yuo login locally (using screen/keyboard) and check if sshd (the ssh demaon) and nginx (the GUI web server) are bound to your local LAN 'pfSEnse' IP when using the 172.x.x.x ?Yeah, that was one of the first things I checked. According to 'netstat -an' both are bound to *. <port>for both tcp4 and tcp6. And it definitely is listening since once i disable the firewall 'pfctl -d' the client can connect no problems.</port>
-
So I think I finally figured out what's going on.
I have some port forwards from the router to my ssh/web server. I added an internal redirect that does the same thing from the LAN interface to the WAN address to redirect port 22/80/443.
I did this because when I'm connected to my work VPN I need to use their DNS server and they, obviously, don't resolve my internal hosts properly :)I think what's happening is when the WAN interface doesn't come up, the "WAN Address" entry gets confused :)
If I disable this rule, then I have no problems accessing the web interface (and ssh) when the WAN is down.
When I was previously testing it, I was only testing my router connected to a single client (without any of the other hosts on the router). Today I had to do a router swap and actually had all my real clients in place (and i screwed up my WAN configuration so didn't get a WAN address) and ran into the same problem except that when i tried to ssh or conect to the web interface i got redirected to the port forward destination :)
-
It 'sounds' like a bug, rules jumping to a different interface.. Can you share what your nat rule looks like 'exactly' ? And perhaps how your wan/lan/other interfaces are assigned? ppp ? dhcp?
I tried to reproduce the behavior but could not. Granted i tried it on 2.4beta so maybe it was fixed, or maybe i just didn't check it the right way..
-
I'm going to reset the backup router and start from scratch on it and try adding just the Port Forward rule to see if I can reproduce it. It's possible that it's a combination of that rule + something else I did.
The specific rule that I disabled to allow connecting to the interface is:
Port Forward
Interface: LAN
Protocol: TCP
Source Address: *
Source Ports: *
Dest. Address: WAN address (not the actual IP address, but the actual "WAN address" entry)
Dest. Ports: ExternalPorts (this is an alias declared for ports 22, 80, 443
NAT IP: <ip address="" of="" the="" destination="" port="" forward="">NAT Ports: ExternalPorts (same alias as Dest. Ports)My LAN configuration is just a simple static IPv4 with IPv6 tracking the WAN interface.
The WAN interface is a PPPoE+VLAN configuration (centurylink fiber) and ipv6 6rd tunnel. Nothing too crazy</ip> -
This is pretty easy to reproduce. I just started with a fresh pfsense install. 2.3.4
I have nothing wired to the router except for a single laptop on the LAN port. WAN is configured for dhcp with no cable connected, so it's "down" and has no address.Added the following rule (see attached screenshot)
interface: lan
protocol: tcp
source address: *
source ports: *
Dest.Address: WAN address
Dest Port: 443
NAT IP: 192.168.1.12 - i picked a random address - actually it wasn't random, it was the example address on the rule page :)
NAT port: 443I did this, applied the filter rules and within a short period of time the laptop was unable to reach the web ui.
From the pfsense console pfctl -d allowed me to reach it again.
Rebooted it and the same thing happened on the reboot. There definitely appears to be a problem when 'WAN address' is not actually assigned.If someone has 2.4 to try it'd be neat to see if it's reproducible there. If it still is I can file a bug on this.
-
that seems to reproduce 'nicely' on 2.4beta.. The thing that did the trick to reproduce it was putting the portforward on the LAN interface.. which is i suppose a little strange, but still wouldn't have expected this result..
p.s. ill try and see if/how maybe it can be easily fixed..
-
Yeah I agree it's strange. My real use case is a little different. I have a DMZ interface that's accessed through the WAN address by external hosts but directly accessible via direct internal IP addresses from my LAN interface.
When I'm connected to VPNs where I need to use a different DNS server, I can't reach them since the hosts resolve to the WAN address. This was a simple, low-maintenance solution to that problem :)
Apparently not a problem-free solution.
-
made a little fix for 2.4beta.. https://github.com/pfsense/pfsense/pull/3782
-
Awesome. Thank you. I don't really know the process for how things are handled by pfsense. Should I still open a bug in redmine on this for tracking, or if someone has a fix for it that's good enough?
-
You could make a redmine ticket, and put a link to the pull-request as well there.. Personally i usually only send pull-requests on github, except for things i cant fix myself.. Sometimes its appreciated though to by the netgate guys to have a ticket anyway..
-
ticket filed
https://redmine.pfsense.org/issues/7697Thanks for the help and the fix.
