Can't connect to web interface when WAN is down
-
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.