Accessing the GUI via the WAN interface - the connection is closed by pfSense (I do not care about security)
-
Hi All,
I have an isolated pfSense VM (2.6.0) used in a lab situation, so I do not care about security and would like to enable access to the WebGUI via the WAN interface.
Based on https://docs.netgate.com/pfsense/en/latest/recipes/remote-firewall-administration.html#i-don-t-care-about-security-how-do-i-open-access-to-the-gui, this should be relatively simple by just adding a firewall rule to allow the traffic. Unfortunately, pfSense (10.161.0.2 - WAN interface)) closes the connection with a FIN/ACK after the handshake. I'm unsure what I might need to twiddle to get this functional (or what I have twiddled to make it fail).
Regards,
-
@swinster
Did you disable blocking of private sources in the WAN interface settings? -
@viragomann its not a firewall rule blocking him.. If there was a firewall rule on the wan blocking the traffic, there wouldn't be a syn,ack sent back.
Off the top, maybe the login protection? You could try adding your source IP to the login protection? I have never had any issues accessing the gui.. Doesn't seem to finish even the tls handshake.. Just a fin sent..
Can you access the gui from the lan side?
-
@viragomann Yes, I disabled both "Block private networks and loopback addresses" and "Block bogon networks" (the last one was a just-in-case but futile act).
-
@johnpoz said in Accessing the GUI via the WAN interface - the connection is closed by pfSense (I do not care about security):
You could try adding your source IP to the login protection
You might be on to something here. The original intent of the pfSense box was to demo some OpenVPN login (with user and certs) capabilities, so I wonder if I changed something here. It was over a year ago that I sat this up, so I can't remember what I did :|
And yes, accessing the GUI from the LAN is no issue.
-
@johnpoz said in Accessing the GUI via the WAN interface - the connection is closed by pfSense (I do not care about security):
You could try adding your source IP to the login protection?
Unfortunately not :(
-
@swinster ARGGHHHH - Year-old me tried to work around a limitation in another system and setup an OpenVPN Server to listen on port 443 : This makes much more sense now.
-
@swinster ah!!!! there you go - that is why not return of the handshake - but syn,ack... Odd that is was nice enough to send a fin ;)