Can't connect to web interface when WAN is down
-
I picked up a cheap celeron j1900 to have around as a backup pfsense router (primary is a rangeley atom c2758 config).
I installed pfsense on teh celeron mini-pc and imported the configuration from the atom router. Everythign is fine if I actually connect the Celeron and have it routing traffic.But If i opt not to connect the celeron to anything (except wiring my laptop into the LAN port) the laptop gets an IP address via dhcp but can't connect to the web ui or ssh in. From the console, the router's IP address is correct, netstat shows the proper ports are listening (and a local curl actually receives a response from the web ui).
The filter.log doesn't show anything being filtered when I try accessing the webui.
Any thoughts why the router wouldnt be reachable in this case?
-
Just checking :
@dopey:…. (except wiring my laptop into the LAN port)
A direct LAN-port (pFSense) to LAN-port (PC) cable connection ? I hope your ports are auto-sensing.
Neeed to know more about your setup.
Loosing a WAN connection never made my pfSEnse box (GUI web server) unreachable.
-
Yeah, same here, losing a WAN connection never made the LAN go down before either. And in this case, it looks like losing the WAN connection doesn't cause it to occur either (i connected when everything was fine, and pulled the WAN cable and was stlil able to conenct to the UI), but not having a WAN connection on initial boot causes it.
So here's exactly what I did:
- install pfsense 2.3.3 on the qotom celeron j1900 mini PC
- at initial boot, the router LAN ip is 192.168.1.1 (the default
- connect my thinkpad ethernet directly to the LAN port (port #2) on the router
- thinkpad gets assigned a 192.168.1.x DHCP IP - everything works :) I'm able to connect to the ui, i skip the initial configuration wizard and import the export from my primary router.
- i did the above steps multiple times to make sure i wasn't crazy and also walked through the configuration side by side with my in-production router to confirm that there weren't any changes that were different or didn't make sense.
After doing the router reboots and is up the console shows the LAN interface with my LAN subnet (i use a 172 network instead of the default 192.168.1.1)
I then (and i've done this multiple times as well) either release and reacquire the DHCP lease (to get a new ip address instead of the preious 192.168.1.x address) or i pull the cable and plug it in and let NetworkManager release and request it automatically. In both cases I end up with a 172.x.x.x ip address as expected).The router is pingable from the thinkpad, but i can't ssh or use http/https into it. With a tcpdump all I see are tcp retransmissions eventually followed by a couple of ICMP unreachable packets.
-
I also found this thread:
https://forum.pfsense.org/index.php?topic=80891.45But disabling checksum offloading didn't make a difference.
-
"i skip the initial configuration wizard and import the export from my primary router."
I would say this is most likely the root of your problem.. Why not run through the wizard - get it working.. Then apply your config from your primary router. Or just do your config from scratch..
-
"i skip the initial configuration wizard and import the export from my primary router."
I would say this is most likely the root of your problem.. Why not run through the wizard - get it working.. Then apply your config from your primary router. Or just do your config from scratch..
Oh I agree that this is the root of the problem. I'm trying to get some ideas to troubleshoot this because I have a pretty extensive configuration (multiple LAN zones, multiple VPNs, a ton of dhcp/dns exception/static mappings, etc etc). The ability to do export/import would be huge given the purpose of this second device is a cheap backup router in case the first one goes kablooey.
I've walked through the wizard enough to get the basic configuration working and then imported the config from the primary router and it failed when WAN wasn't connected on reboot.
It doesn't make any sense that if WAN isn't up, that i wouldn't be able to connect to any of the usual ports from any of the LAN interfaces.
The next step I'm planning on doing is comparing the xml dumps of the configurations to see if there's anything obvious I'm missing, but really I was hoping someone else had an idea of an area to target to look at.
-
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.
