Score:0

Server

Ubuntu UFW log shows public addresses sending traffic to my RFC1918 private address

Tirki

1/29/23, 12:05 AM

This is really a routing question but here is the back ground:

I am running Ubuntu 20.04.3 LTS with UFW. My internal network is 10.126.1.0/24. No inbound translations at the Internet edge. If I inspect my UFW logs I see messages similar to this:

Aug 20 17:41:01 XPS-8100 kernel: [ 1964.382883] [UFW BLOCK] IN=enp5s0 OUT= MAC=84:2b:2b:9d:ae:44:02:81:51:8b:22:18:08:00 SRC=142.250.111.109 DST=10.126.1.41 LEN=85 TOS=0x00 PREC=0x00 TTL=36 ID=11413 PROTO=TCP SPT=993 DPT=40634 WINDOW=266 RES=0x00 ACK PSH URGP=0

If I am reading this right, IP tables/UFW is blocking inbound traffic from 142.250.111.109 to 10.126.1.41. My confusion stems from IP traffic from a public IP address delivered to a private IP address then being (happily) denied.

Unless I badly misunderstand the routing rules for the public Internet, no self respecting ISP will carry traffic for private addresses much less find one of the thousands of instances of private IP addresses then deliver the traffic.

Either UFW is confused or I am confused or the Internet is doing something I didn't expect. Anyone have any thoughts?

UFW status returns this list of ports open on the Ubuntu machine:

(base) glenn@XPS-8100:~/Desktop$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
137/udp                    ALLOW       10.126.1.0/24             
138/udp                    ALLOW       10.126.1.0/24             
139/tcp                    ALLOW       10.126.1.0/24             
445/tcp                    ALLOW       10.126.1.0/24             
514/tcp                    ALLOW       10.126.1.0/24             
514/udp                    ALLOW       10.126.1.0/24             
22/tcp                     ALLOW       10.126.1.0/24             
5001/tcp                   ALLOW       10.126.1.0/24             
5001/udp                   ALLOW       10.126.1.0/24             
137/tcp                    ALLOW       10.126.1.0/24             
139/udp                    ALLOW       10.126.1.0/24             
80/tcp                     ALLOW       10.126.1.0/24             
8080/tcp                   ALLOW       10.126.1.0/24             
5201                       ALLOW       10.126.1.0/24

141

0 + 0

firewall

logging

ip-routing

Michael Hampton

1/29/23, 12:13 AM

Surely this is because of NAT and is perfectly normal (insofar as NAT is normal).

Zoredache

1/29/23, 12:29 AM

DNAT happens pre-routing, and before the filter table is processed. Look at your nat table.

Michael Hampton

1/29/23, 5:47 AM

More likely I think that the NAT was done at an external router.

Tirki

1/30/23, 12:19 PM

There seems to be a bit of confusion here. Has anyone seen a chart that demonstrates the NAT process for IP Tables? That might clearly isolate where this NAT is taking place.

Tirki

1/30/23, 12:30 PM

I spoke too soon. This IP tables tutorial shows the flow.https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES

Tirki

1/30/23, 10:44 PM

I think I agree with Michael Hampton. I assumed that these packets were unsolicited but the ports are either well known (system ports) or user ports. I think I solicited these packets and IP tables blocked part of the conversation. The NAT would happen at the Internet edge so there is no violation of Internet routing rules.

Score:0

Server

Tomek

1/29/23, 6:38 AM

What you are showing in a log is a return / reply packet to an OUTGOING connection to IMAPS server, probably GMAIL.

The SNAT/MASQUARADE which is done in POSTROUTING has its own DNAT counterpart taking place in PREROUTING which restores the original addresses in reply packets for the outgoing connection.

As the packet seems to be blocked this may mean that your firewall is too restrictive and is not letting the ESTABLISHED packets back in. Or it is too lax and the connection should have been blocked during establishment phase in the first place.

0 + 0

Tirki

1/29/23, 10:44 AM

Thanks. Looks like I need to go down the IP tables rabbit hole before I understand this.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Ubuntu UFW log shows public addresses sending traffic to my RFC1918 private address

TH: บันทึก Ubuntu UFW แสดงที่อยู่สาธารณะที่ส่งการรับส่งข้อมูลไปยังที่อยู่ส่วนตัว RFC1918 ของฉัน

RO: Jurnalul Ubuntu UFW arată adresele publice care trimit trafic către adresa mea privată RFC1918

RU: Журнал Ubuntu UFW показывает общедоступные адреса, отправляющие трафик на мой частный адрес RFC1918.

VI: Nhật ký Ubuntu UFW hiển thị các địa chỉ công cộng gửi lưu lượng đến địa chỉ riêng RFC1918 của tôi

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.