Remote admin via HTTPS

Bob Simmons

I am new to pfSense. Have used other open source UTM/firewalls (Untangle, Endian, etc.) over the years, but this is my first exposure to pfSense. I have deployed the latest version on a mini PC. Have it up and running but want to continue configuring and managing this remotely. I do not want to use SSH or a VPN to connect to it. I simply want to use HTTPS on a non-standard port and a ridiculously complex password. I have enabled remote admin on a non-standard port and created firewall policies to restrict access to only two IP addresses. Can't seem to access it. What am I missing here folks?

keyser

@bob-simmons said in Remote admin via HTTPS:

I am new to pfSense. Have used other open source UTM/firewalls (Untangle, Endian, etc.) over the years, but this is my first exposure to pfSense. I have deployed the latest version on a mini PC. Have it up and running but want to continue configuring and managing this remotely. I do not want to use SSH or a VPN to connect to it. I simply want to use HTTPS on a non-standard port and a ridiculously complex password. I have enabled remote admin on a non-standard port and created firewall policies to restrict access to only two IP addresses. Can't seem to access it. What am I missing here folks?

The Webadmin by default listens on all IPs, so your firewall rule should be on WAN interface and have “WAN Address” as destination. No NAT port forward to LAN or other trickery needed (won’t work properly)

Bob Simmons

@keyser Thanks. I will look at it again. Pretty sure that is the way I have it configured.

johnpoz

@bob-simmons lets see your firewall rules on the wan.

AS mentioned gui listens on all IPs. As long as your not behind a nat for pfsense wan, and the isp your connected to allows whatever port your trying to use be out from where your at, or in to where pfsense is at all that is needed is a firewall rule to allow access to the wan address to the ports, or what source IPs you want to allow.

Common mistake see is users set the source port, when that would be any..

Please post your wan rules and we can see if something wrong..

Bob Simmons

@johnpoz I got back over there and see nothing that would stop my remote admin via HTTPS. I grabbed the config file and created a test file with the firewall rules. It is attached. Perhaps you can see something that I am missing. Note that I substittued XXs for the two public IPs that are in the alias. Thanks pfSense fw rules.txt

rcoleman-netgate

@bob-simmons what did the firewall logs say in regards to your public IPs?
That should be the first place to check about firewall rules not working. Status->System Log->Firewall tab

johnpoz

So you hand edited that file.. Because its messed up..

		<rule>
			<id></id>
			<tracker>1664897587</tracker>
			<type>pass</type>
			<interface>wan</interface>
			<ipprotocol>inet</ipprotocol>
			<tag></tag>
			<tagged></tagged>
			<max></max>
			<max-src-nodes></max-src-nodes>
			<max-src-conn></max-src-conn>
			<max-src-states></max-src-states>
			<statetimeout></statetimeout>
			<statetype><![CDATA[keep state]]></statetype>
			<os></os>
			<protocol>tcp</protocol>
			<source>
				<address>STSAdminIPs</address>
			</source>
			<destination>
				<network>(self)</network>
				<port>20443</port>
			</destination>
			<log></log>
			<descr><![CDATA[Remote Admin]]></descr>


<rule>
			<id></id>
			<tracker>1664897587</tracker>
			<type>pass</type>
			<interface>wan</interface>
			<ipprotocol>inet</ipprotocol>
			<tag></tag>
			<tagged></tagged>
			<max></max>
			<max-src-nodes></max-src-nodes>
			<max-src-conn></max-src-conn>
			<max-src-states></max-src-states>
			<statetimeout></statetimeout>
			<statetype><![CDATA[keep state]]></statetype>
			<os></os>
			<protocol>tcp</protocol>
			<source>
				<address>STSAdminIPs</address>
			</source>
			<destination>
				<network>(self)</network>
				<port>20443</port>
			</destination>
			<log></log>
			<descr><![CDATA[Remote Admin]]></descr>
			<created>
				<time>1664897587</time>
				<username><![CDATA[admin@192.168.51.54 (Local Database)]]></username>
			</created>
			<updated>
				<time>1666712761</time>
				<username><![CDATA[admin@192.168.51.83 (Local Database)]]></username>
			</updated>
		</rule>

You have what looks like a duplicate rule.. there is not /rule close tag.. Same tracker. And if that rule is to allow access to your wan, it really should just be wanip vs (self).

A screenshot is so much easier and faster to digest..

Is that alias the actual IP your coming from? And you edited your gui to listen on 20443?

A screenshot would of shown if the rule had ever even been evaluated or if just showing 0/0 for states..

Bob Simmons

@bob-simmons I assume that you are referring to the alias IPs? I will look in the logs for them. As for the public IP of the pfSense router, I can ping it from either of the IPs that I put in the alias. Just can't connect on port 20443.

Bob Simmons

I just cut and pasted the rules into a txt document to attach here. May have pasted one twice.

Bob Simmons

Yes the alias addresses are the actual "from" addresses that I will use. I have not edited the config file manually. Yes, I changed the remote admin port to 20443. I am not on-site. The unit is at a client site. So can't do anything more tonight.

rcoleman-netgate

@bob-simmons Check your firewall log file when you get back to the system. That's going to tell you if your rule is working or not, and if there's something different happening. A partial config file leaves many things omitted that could be the actual cause and we'll be barking up the wrong tree for you.

Bob Simmons

@rcoleman-netgate I could find absolutely nothing in the logs regarding this issue. I find that amazing! I saw someone comment, on another forum, that the default rules for blocking private networks and bogon IPs would need to be turned off to get WAN HTTPS web configurator access to work. This has become the most time expensive goofiness that I have encountered in years. Perhaps trying pFsense was a bad idea.

johnpoz

@bob-simmons said in Remote admin via HTTPS:

private networks and bogon IPs would need to be turned off to get WAN HTTPS web configurator access to work.

Not unless you were coming from a private IP or a bogon - that sure not going to work across the internet in the first place.

How about you post a simple screen shot of your rules.. That would tell just from the states column if ever even evaluated..

You want to admin pfsense from the wan - all that is required is a simple rule that allows access to the wan address on the port your web gui is listening on..

Bob Simmons

@johnpoz Here is a txt of the config file with the WAN IP address removed.
config-Wright-lessWANIP.txt

johnpoz

@bob-simmons post a picture.. The xlm rules are not going to show us if rule triggered.

Here took 2 seconds to do, created rule - turned off wifi on my phone, and I am in. See the hits and states in the state colum

For all we know traffic isn't even getting there, or your source doesn't match.. If the rule has been trigged it would show in the interface rules listing.. See my highlighted section.

If your rule shows 0/0 then it never triggered, ever.. Means pfsense never saw traffic that matched that rule.

Bob Simmons

@johnpoz Sorry John! I am not on-site and, since I have no remote access, a picture is not an option right now. You can see in the rule in the config file. You will also see the ICMP rule right below it. I can remotely ping successfully and see the traffic. In fact I have a ping monitor pinging the WAN IP of the pFSense router every five minutes. So that rule is working. I don't believe that traffic is making it to the Remote Admin firewall rule. Trying to figure out what is blocking it? In all other respects traffic is normal. The users are surfing the web, etc. Everything is working, albeit not as securely as I want it. None of the other packages that I want to deploy have been added. have to get this remote admin issue resolved first.

johnpoz

@bob-simmons for all we know your pinging something else.. etc..

A picture of the rules would show us if the rules are being triggered, and if there is any active connections to it. Say if you have ping monitor up, then your icmp rule should show a state..

Notice on mine there are currently 7 active states - I also have monitors running on my home connection externally.

If the rule was triggering you would have access.. See my phone.. The gui listens on all interfaces so if your rule allowed the traffic you would be on the gui remotely. So either the source IP is not correct in your alias, the port is wrong - or the traffic is never getting there. The states column would show if your combo of settings in the rule actually triggered.

Bob Simmons

@johnpoz As I said, when I was on site last, the ICMP rule was showing hits and the Remote Admin rules was not. The puzzlement is what is keeping the traffic from hitting the Remote Admin rule? There has to be some other default rule or setting that is stopping the inbound packets from hitting this firewall rule:
<rule>
<id></id>
<tracker>1664897587</tracker>
<type>pass</type>
<interface>wan</interface>
<ipprotocol>inet</ipprotocol>
<tag></tag>
<tagged></tagged>
<max></max>
<max-src-nodes></max-src-nodes>
<max-src-conn></max-src-conn>
<max-src-states></max-src-states>
<statetimeout></statetimeout>
<statetype><![CDATA[keep state]]></statetype>
<os></os>
<protocol>tcp</protocol>
<source>
<address>STSAdminIPs</address>
</source>
<destination>
<network>(self)</network>
<port>20443</port>
</destination>
<log></log>
<descr><![CDATA[Remote Admin]]></descr>
<created>

johnpoz

@bob-simmons said in Remote admin via HTTPS:

There has to be some other default rule or setting that is stopping the inbound packets from hitting this firewall rule:

No there doesn't have to be.. Maybe your ISP is blocking, or where your coming from is blocking that port outbound.

The only rules that would block are the wan rules, and or floating rules. Unless your source IP was rfc1918 or bogon - the 2 default rules there would not be stopping it. As you can see those rules are active on mine and still able to access it.

What I would do is go to say can you see me . org - test from there to the port. If it says down - then do a sniff on your wan while you test. Do you see the packets actually hit the wan..

This seems odd

<network>(self)</network>

If you notice in my rules that are set for wan address... It actually shows wan IP, are you picking this firewall as the destination. While that should work, the rule on your wan for destination should be wan IP.

	<rule>
		<id></id>
		<tracker>1668192451</tracker>
		<type>pass</type>
		<interface>wan</interface>
		<ipprotocol>inet</ipprotocol>
		<tag></tag>
		<tagged></tagged>
		<max></max>
		<max-src-nodes></max-src-nodes>
		<max-src-conn></max-src-conn>
		<max-src-states></max-src-states>
		<statetimeout></statetimeout>
		<statetype><![CDATA[keep state]]></statetype>
		<os></os>
		<protocol>tcp</protocol>
		<source>
			<address>testalias</address>
		</source>
		<destination>
			<network>wanip</network>
			<port>8443</port>
		</destination>
		<descr></descr>
		<updated>
			<time>1668192451</time>
			<username><![CDATA[admin@192.168.9.100 (Local Database)]]></username>
		</updated>
		<created>
			<time>1668192451</time>
			<username><![CDATA[admin@192.168.9.100 (Local Database)]]></username>
		</created>

edit: so for sure can you see me not going to be in my alias, so the rule would not trigger and allow it. But from a sniff I can see that the traffic got there

Bob Simmons

@johnpoz I will first try using WAN Address for the destination in my rule. I was just doing what was in the documentation. See https://docs.netgate.com/pfsense/en/latest/recipes/remote-firewall-administration.html#example-firewall-rule-setup . Then I may sniff and test further. I am betting that we found the quirk. Will post the results. Thanks John!