3.4.23_1 - Not possible to connect locally (i.e. mytools.management)

adam:ONE®
1

From the adam:ONE / [Settings] : Installed version, 3.4.23_1

At one time it was possible to look at detailed information about what was happening in the local router. I.e. I could see DNS requests, filter by device, etc. This was tremendously important to detecting anomalous behavior, unwanted behavior, etc. I am now completely blind with respect to Adam:One, and now can only use pfsense logs. What gives? What might be causing this situation.

Unless I’m forgetting, the ability to connect to port 443 of the router was why
we had to change the pfsense admin port to another port number.

The MyTools link:

http://mytools.management/

$ dig mytools.management

; <<>> DiG 9.11.31Mageia-1.1.mga8 <<>> mytools.management
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12866
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mytools.management. IN A

;; ANSWER SECTION:
mytools.management. 60 IN A 192.168.8.254

;; Query time: 0 msec
;; SERVER: 192.168.8.254#53(192.168.8.254)
;; WHEN: Mon Oct 18 16:26:15 CDT 2021
;; MSG SIZE rcvd: 52

It doesn’t matter if I use the name or the IP address. The browser says:
ERR_CONNECTION_REFUSED.

There still is a firewall LAN rule to unblock port 80 to this firewall. It is
labelled “adam:ONE allow HTTP to mytools.management”. The rule set has not
changed of late. I doubt that I have had MyTools working since I let the
firewall update to 2.5.2-RELEASE (amd64) built on Fri Jul 02 15:33:00 EDT 2021
FreeBSD 12.2-STABLE, but I could not say this is when this feature quit
working.

In the past, I’d been advised to look for anmgr in sockstat -4 output:

Shell Output - sockstat -4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root anmgr 38139 17 udp4 127.0.0.1:53 :
root anmgr 38139 18 udp4 142.79.124.183:53 :
root anmgr 38139 19 udp4 192.168.8.254:53 :
root anmgr 38139 21 tcp4 127.0.0.1:53 :
root anmgr 38139 22 tcp4 142.79.124.183:53 :
root anmgr 38139 23 tcp4 192.168.8.254:53 :
root anmgr 38139 25 tcp4 127.0.0.1:80 :
root anmgr 38139 26 tcp4 142.79.124.183:80 :
root anmgr 38139 27 tcp4 192.168.8.254:80 :
root anmgr 38139 30 udp4 *:5353 :
root anmgr 38139 32 udp4 192.168.8.254:137 :
root anmgr 38139 34 tcp4 142.79.124.183:36150 34.120.84.240:443
root anmgr 38139 35 tcp4 142.79.124.183:36151 104.196.219.250:44353
dhcpd dhcpd 58760 8 udp4 *:67 :
root php-fpm 88253 4 udp4 : :
root php-fpm 42372 4 udp4 : :
root php-fpm 25876 4 udp4 : :
root php-fpm 55380 4 udp4 : :
root php-fpm 34999 4 udp4 : :
root php-fpm 36122 4 udp4 : :

2

@kbulgrien thank you for using adam:ONE® we always appreciate hearing feedback. There are two possibilities here as to what may be happening:

Possibility #1 is that your pfSense firewall isn’t allowing TCP port 80 traffic on your LAN to “This Firewall”. That would be easy to check by just running this from a linux/mac terminal or windows powershell:

curl -v http://192.168.8.254

If you get output from that connection, the firewall is allowing the traffic, so firewall settings aren’t the root cause of your symptom. If you don’t get a response, check the LAN firewall rule to allow TCP port 80 to “This firewall”.

Possibility #2 is that your browser now has an HSTS cookie, which pfSense’s ngnix could have issued if you ever accessed the pfSense GUI using the fqdn of mytools.management. You can turn OFF HSTS in pfSense → System → Advanced (that’ll take care of future issues like this).

The easiest way to check this is with a browser you don’t normally use, launch a private/incognito window and try http://mytools.management

Another way to try it is by just using a direct IP in your browser at http://192.168.8.254

On a sidenote, you might have noticed we released 4.8 and the how-to is at adamnet.io/pfsense if you want to try an upgrade sometime. I mention it only because we have new features in v4 for mytools you might like.

3

Wow, my bad on this one. It wasn’t the pfsense firewall rejecting traffic, but a firewall on the local system that is set up to be paranoid. A new zone had been created for the pfsense firewall address, and rules were created to permit https to the new zone, but not http… Oof… Thanks for the reply. For some reason the curl command did what I needed to think about checking local firewall rules even though the browser was giving similar indication.

4

Yeah, with good intentions, modern-day endpoint firewalls tend to be cautious for local/LAN connections because that’s how DNS rebinding attacks work.