loopback address being blocked?

[ludejim]

Hello,
I am attempting to use the pfSense FauxAPI. It is mostly working, except one slight issue. When the FauxAPI attempts to make a change to the configuration, it attempts to load a pfSense page using the loopback address - 127.0.0.1.

For whatever reason this is being blocked? I have opened a ticket on the pfSense FauxAPI github page, it is linked here, there is more information in that ticket:
pfSense FauxAPI Open Ticket

Doing something as simple as:

curl https://127.0.0.1/index.php

from the shell of pfSense yeilds these results:

curl: (7) Could't connect to server

whereas,

curl https://192.168.1.1/index.php

works without a hitch.

Here are my LAN rules:

[kiokoman]

idk curl from localhost work for me
maybe floating rules or bogon list

[JKnott]

@ludejim

Is it even possible to block the loopback? That's considered a separate interface that's not even in pfsense. I'd say your problems are elsewhere.

BTW, if it were blocked, then networking wouldn't work at all, as everything goes through it.

[ludejim]

@JKnott I wasn’t aware of a way to block the loop back address either. The only place I have seen a reference to loop back addresses is where @kiokoman mentioned, which is bogon. I haven’t enabled those block lists for my LAN, only my WAN.

My next thought was my DNS settings, but my impression is that the loop back address would never cause the server to reach out to any DNS server. What is best practice for the DNS setting? Here I have mine pointing to my loopback. Then under each DHCP Server I have the DNS Server pointing to a piHole instance that runs on my local network.

[johnpoz]

What what exactly is suppose to be listening on 443 (https) on loopback?

If something is actually listening on 443 on loopback then you would get an answer with your curl command. If nothing is, then no you wouldn't

🔒 Log in to view

As you can see nothing on my pfsense listening on all or loopback on 443, so no not going to get a response trying to talk to that.

[kiokoman]

that's because you moved the web gui to port 9443 @johnpoz
he didn't, afaik, change it. he need to talk to the webgui

[johnpoz]

Yeah I know what I moved to 9443 ;) haproxy is listening on that port, Web gui is on 8443..

My point was lets see his output showing that something is actually listening on 443.. There are no firewall rules that would block pfsense from talking to itself.

🔒 Log in to view

[ludejim]

In my first post I kinda showed that a curl command to https://192.168.1.1/index.php was functioning. I’m sure you guys are aware that https runs naturally on 443...

But the same request to https://127.0.0.1/index.php was getting a couldn’t connect message

[johnpoz]

@ludejim said in loopback address being blocked?:

I’m sure you guys are aware that https runs naturally on 443...

Yeah doesn't mean anything.. .Like I showed you my gui not listening on 443..

all we know you have haproxy bound to 192.168.1.1 on 443.. Or openvpn, or something else..

Let me state this again.. There is NOT A FIREWALL RULE - that blocks pfsense from talking to itself.. If your on pfsense and you can not talk to loopback on port X - then nothing is listening on X... Its that simple..

Show us something bound to all or loopback listening on 443.. Take all of 0.3 seconds to do that command.. Or better yet

sockstat | grep :443

Are you even running that curl command on pfsense? If your running it on some machine - that machine trying to talk to itself via loopback, etc..

[ludejim]

@johnpoz

Here are some screens demonstrating the output you requested:

Success on https://192.168.1.1:443:

Fail on loopback:

Edit:
I am using haproxy, but only on port 80 that I am aware of...

[johnpoz]

And still not the commands I actually asked for.. Lets see the output of netstat or sockstat actually showing something bound to loopback.

Sockstat prob better because would actually show "what" is bound to that port.

Again - there is no firewall rule that could block pfsense from talking to itself.

You could have some race condition where something else is binding to 443 on loopback?? The gui will try and bind to everything.. So maybe you have something trying to bound to 443, before the gui can bind to it on loopback? So lets see sockstat " grep :443 showing what process if anything is bound to the loopback on that port.

[ludejim]

My bad. I just saw your screen shot and thought that’s what you were referring to. Here is a sockstat | grep :443

[ludejim]

@johnpoz Now that we know multiple things are bound to loopback, is there a command that could help me determine what those things are. I can see they are Nginx servers, but I don’t know what they are associated with.

I do have OpenVPN and HAProxy running. My OpenVPN instance is using the default port of 1194. HAProxy is bound to port 80 for a web server.

Unless those two items do something in the background I am unaware of, I’m not sure what the other items are that are binding to port 443 on the loopback.

[johnpoz]

nginx is the gui..

Those are the pids of the processes, 2 workers and the main one.. on mine for example

[2.4.5-RELEASE][admin@sg4860.local.lan]/root: ps -ax | grep 82772
82772  -  Is        0:00.00 nginx: master process /usr/local/sbin/nginx -c /var/etc/nginx-webConfigurator.conf (nginx)
38899  1  S+        0:00.00 grep 82772

Again there is no firewall rule that would prevent access to itself.. Lets see the output of your curl with the -v so we can see exactly what is going on.

[2.4.5-RELEASE][admin@sg4860.local.lan]/root: curl -v https://127.0.0.1:8443
*   Trying 127.0.0.1:8443...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate in certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html

Also sniff on the localhost while you try and do your test.. So you can actually see the connection attempt, and the source IP, etc..

So here example you see me doing that above test while doing a packet capture on localhost for my port 8443

🔒 Log in to view

For grins check your loopback rules

[2.4.5-RELEASE][admin@sg4860.local.lan]/root: pfctl -sr | grep loopback
pass in on lo0 inet all flags S/SA keep state label "pass IPv4 loopback"
pass out on lo0 inet all flags S/SA keep state label "pass IPv4 loopback"
pass in on lo0 inet6 all flags S/SA keep state label "pass IPv6 loopback"
pass out on lo0 inet6 all flags S/SA keep state label "pass IPv6 loopback"

You do show your lo up and on 127.0.0.1? with an ifconfig

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: lo

Also so we are sure.. Is this baremetal or is pfsense on some VM?

[ludejim]

curl command and response:

Packet capture during curl command captured nothing:

loopback rules:

ifconfig lo0 is up:

Great question, my pfsense is being hosted on eSXI.

[johnpoz]

do you have a route for loopback?

example

[2.4.5-RELEASE][admin@sg4860.local.lan]/root: netstat -rn | grep 127
127.0.0.1          link#7             UH          lo0
[2.4.5-RELEASE][admin@sg4860.local.lan]/root: 

There is mine..

That error in curl
Immediate connect fail for 127.0.0.1: Can't assign requested address

Can you ping localhost?

[2.4.5-RELEASE][admin@sg4860.local.lan]/root: ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.128 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.063 ms

[ludejim]

I can’t ping localhost:

Netstat results:

[kiokoman]

it's in the wrong interface
127.0.0.1 link#4 UH lo0

should be lo0, not vmx0
idk how you ended up with something like this

[johnpoz]

Yeah that is clearly Borked!!

[ludejim]

Borked it is! I can see how to assign all other interfaces. Anyway to reassign the loopback?