Remote admin via HTTPS
-
I just cut and pasted the rules into a txt document to attach here. May have pasted one twice.
-
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.
-
@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.
-
@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.
-
@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..
-
@johnpoz Here is a txt of the config file with the WAN IP address removed.
config-Wright-lessWANIP.txt -
@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.
-
@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.
-
@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.
-
@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> -
@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
-
@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!
-
@bob-simmons said in Remote admin via HTTPS:
https://docs.netgate.com/pfsense/en/latest/recipes/remote-firewall-administration.html#example-firewall-rule-setup
See here for allowing on the wan
Clearly showing wan address in the rule on the wan.. This firewall is set on the lan side interfaces.. That would allow you to hit any IP on pfsense.
-
@johnpoz Well ... I finally got past this issue. Went on-site again yesterday and drilled into the AT&T router and found that they had not setup IP Passthrough (bridge mode) properly. I got that fixed and then I could access the pFsense router remotely. Moving forward this morning installing packages and doing other config tasks. By the way, "this firewall" as the destination address in the policy works fine. I suspect that either "wan address" or "this firewall" would work. Thanks for your help guys!
-
@bob-simmons "this firewall" is an alias that includes all IPs. So for instance if one set up rules like:
block from LAN to pfSense-LAN-IP
...LAN devices could connect to the pfSense WAN IP.
I didn't reread all the above but you'll want to limit access to your own IP as the Source.
-
@steveits Thanks. Yes, I did set up an alias for the 2 IPs that I want to have remote admin access and only those source addresses are allowed in the policy.
