You are not logged in.

Pages: 1

#1 2024-01-27 15:27:46

thfischer
Member
Registered: 2017-01-03
Posts: 6

[SOLVED] Connections to 127.0.0.1 appear to come from NIC's address

I have a strange phenomenon: if I make any network connection to localhost (127.0.0.1), for the connected service the source IP address appears to be my network card's IP address (192.168.x.y).
This can be reproduced across various implementations and protocols (TCP and UDP).

Example 1: I have systemd-resolved running and there is a DNS stub listening on 127.0.0.53, port 53/UDP. Running 

dig @127.0.0.1 name-to-resolve

results in error message ";; communications error to 127.0.0.53#53: timed out". In the systemd journal, the following message appears: "Got packet on unexpected (i.e. non-localhost) IP range, ignoring.". I checked systemd's source code; this messages is created if the resolver is connected from a source address that does not start with 127.
Similar network setups and identical experiments on other ArchLinux machines in the same LAN work without problem.

Example 2: I have fetched a simple TCP echo server/client Python code example from https://realpython.com/python-sockets/. Running the two Python scripts creates output "Connected by ('192.168.1.100', 38904)", i.e. not using 127.0.0.1 despite having the client script connecting to 127.0.0.1.

As mentioned above, running 

dig @127.0.0.1 name-to-resolve

does not work, but querying any other DNS server, such as the one on my router, works fine, e.g. 

dig @192.168.1.1 name-to-resolve

Overall, my network setup is quite boring:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 44:8a:5b:d0:ce:48 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.100/24 metric 1024 brd 192.168.1.255 scope global dynamic enp3s0
       valid_lft 12253sec preferred_lft 12253sec
    inet6 fe80::468a:5bff:fed0:ce48/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
$ ip r
default via 192.168.1.1 dev enp3s0 proto dhcp src 192.168.1.100 metric 1024
192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.100 metric 1024
192.168.1.1 dev enp3s0 proto dhcp scope link src 192.168.1.100 metric 1024
$ grep -E '^[^#].*(127|local)' /etc/hosts
127.0.0.1 localhost localhost.localdomain
$ cat /etc/systemd/resolved.conf.d/fallback_dns.conf
[Resolve]
FallbackDNS=185.181.61.24#ns1.no.dns.opennic.glue 95.216.99.249#ns5.fi.dns.opennic.glue 128.76.152.2#ns1.dk.dns.opennic.glue
$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Sep 23 21:03 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
$ grep -E '^[^#]' /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search .

I have not seen similar problems before. It is actually hard to find information on that, as searching for such network problems turns up a ton of results from people having all kinds of problems.
Any ideas were to look for the cause of this misbehaviour?

Last edited by thfischer (2024-01-28 21:13:10)

Offline

#2 2024-01-27 16:14:54

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 68,329

Re: [SOLVED] Connections to 127.0.0.1 appear to come from NIC's address

1 != 53

dig @127.0.0.53 google.com

In doubt

resolvectl status
sudo nmap -sU -p 53 127.0.0.1 127.0.0.53

You're not routing over the lo device, that's common and typically not a problem at all and I don't think it's here.

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Offline

#3 2024-01-27 17:05:58

thfischer
Member
Registered: 2017-01-03
Posts: 6

Re: [SOLVED] Connections to 127.0.0.1 appear to come from NIC's address

seth wrote:

1 != 53

dig @127.0.0.53 google.com
$ dig @127.0.0.53 google.com
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out

; <<>> DiG 9.18.21 <<>> @127.0.0.53 google.com
; (1 server found)
;; global options: +cmd
;; no servers could be reached
$ dig @127.0.0.1 google.com
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused

; <<>> DiG 9.18.21 <<>> @127.0.0.1 google.com
; (1 server found)
;; global options: +cmd
;; no servers could be reached
seth wrote:

In doubt

resolvectl status
$ resolvectl status
Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
Fallback DNS Servers: 185.181.61.24#ns1.no.dns.opennic.glue 95.216.99.249#ns5.fi.dns.opennic.glue 128.76.152.2#ns1.dk.dns.opennic.glue

Link 2 (enp3s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1
seth wrote:
sudo nmap -sU -p 53 127.0.0.1 127.0.0.53
$ sudo nmap -sU -p 53 127.0.0.1 127.0.0.53
Starting Nmap 7.94 ( https://nmap.org ) at 2024-01-27 17:59 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000021s latency).

PORT   STATE  SERVICE
53/udp closed domain

Nmap scan report for 127.0.0.53
Host is up.

PORT   STATE         SERVICE
53/udp open|filtered domain

Nmap done: 2 IP addresses (2 hosts up) scanned in 13.34 seconds
seth wrote:

You're not routing over the lo device, that's common and typically not a problem at all and I don't think it's here.

Does the information above provide any new hints?

Offline

#4 2024-01-27 20:29:47

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 68,329

Re: [SOLVED] Connections to 127.0.0.1 appear to come from NIC's address

Communication to 127.0.0.53 "just" times, the port is filterd out and resolved doesn't mention it at all

ss -tulpen | grep 53

Do you run any kind of firewall? (firewalld, wfw, basic iptables or nftables, be wary of https://wiki.archlinux.org/title/Nftabl … e_firewall )

Also the configured DNS for enp3s0 is 192.168.1.1

dig @192.168.1.1 google.com

As expected, 127.0.0.1:53 is closed - nothing surprising there.

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Offline

#5 2024-01-28 15:17:48

thfischer
Member
Registered: 2017-01-03
Posts: 6

Re: [SOLVED] Connections to 127.0.0.1 appear to come from NIC's address

seth wrote:

Communication to 127.0.0.53 "just" times, the port is filterd out and resolved doesn't mention it at all

ss -tulpen | grep 53
$ sudo ss -tulpen | grep 53
Failed to open cgroup2 by ID
Failed to open cgroup2 by ID
udp   UNCONN 0      0                127.0.0.54:53         0.0.0.0:*    users:(("systemd-resolve",pid=651,fd=22)) uid:975 ino:4779 sk:3 cgroup:/system.slice/systemd-resolved.service <->                                                   
udp   UNCONN 0      0             127.0.0.53%lo:53         0.0.0.0:*    users:(("systemd-resolve",pid=651,fd=20)) uid:975 ino:4777 sk:4 cgroup:/system.slice/systemd-resolved.service <->                                                   
udp   UNCONN 0      0                   0.0.0.0:5353       0.0.0.0:*    users:(("systemd-resolve",pid=651,fd=15)) uid:975 ino:4772 sk:7 cgroup:/system.slice/systemd-resolved.service <->                                                   
udp   UNCONN 0      0                   0.0.0.0:5355       0.0.0.0:*    users:(("systemd-resolve",pid=651,fd=11)) uid:975 ino:4762 sk:8 cgroup:/system.slice/systemd-resolved.service <->                                                   
udp   UNCONN 0      0                      [::]:5353          [::]:*    users:(("systemd-resolve",pid=651,fd=16)) uid:975 ino:4773 sk:b cgroup:/system.slice/systemd-resolved.service v6only:1 <->                                          
udp   UNCONN 0      0                      [::]:5355          [::]:*    users:(("systemd-resolve",pid=651,fd=13)) uid:975 ino:4770 sk:c cgroup:/system.slice/systemd-resolved.service v6only:1 <->                                          
tcp   LISTEN 0      4096                0.0.0.0:5355       0.0.0.0:*    users:(("systemd-resolve",pid=651,fd=12)) uid:975 ino:4763 sk:12 cgroup:/system.slice/systemd-resolved.service <->                                                  
tcp   LISTEN 0      4096             127.0.0.54:53         0.0.0.0:*    users:(("systemd-resolve",pid=651,fd=23)) uid:975 ino:4780 sk:16 cgroup:/system.slice/systemd-resolved.service <->                                                  
tcp   LISTEN 0      4096          127.0.0.53%lo:53         0.0.0.0:*    users:(("systemd-resolve",pid=651,fd=21)) uid:975 ino:4778 sk:19 cgroup:/system.slice/systemd-resolved.service <->                                                  
tcp   LISTEN 0      4096                   [::]:5355          [::]:*    users:(("systemd-resolve",pid=651,fd=14)) uid:975 ino:4771 sk:1a cgroup:/system.slice/systemd-resolved.service v6only:1 <->
seth wrote:

Do you run any kind of firewall? (firewalld, wfw, basic iptables or nftables, be wary of https://wiki.archlinux.org/title/Nftabl … e_firewall )

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
$ sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  anywhere             anywhere
$ sudo nft list ruleset
$ sudo nft list tables
$ sudo nft list tables inet

The 'nft' commands do not print anything.

seth wrote:

Also the configured DNS for enp3s0 is 192.168.1.1

dig @192.168.1.1 google.com

That is correct, it is my router which runs dnsmasq.

seth wrote:

As expected, 127.0.0.1:53 is closed - nothing surprising there.

The only odd thing was this MASQUERADE rule. I removed it and – surprise – name resolution works again. Thank you very much for you help, seth!

Offline

#6 2024-01-28 16:03:36

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 68,329

Re: [SOLVED] Connections to 127.0.0.1 appear to come from NIC's address

udp   UNCONN 0      0                127.0.0.54:53         0.0.0.0:*    users:(("systemd-resolve",pid=651,fd=22)) uid:975 ino:4779 sk:3 cgroup:/system.slice/systemd-resolved.service <->                                                   
udp   UNCONN 0      0             127.0.0.53%lo:53         0.0.0.0:*    users:(("systemd-resolve",pid=651,fd=20)) uid:975 ino:4777 sk:4 cgroup:/system.slice/systemd-resolved.service <->

The DNS would hopefully (have been) available on 

dig @127.0.0.54 google.com

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Offline

Pages: 1

Board footer

Powered by FluxBB