0

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
Nikita Kipriyanov
  • 8,033
  • 1
  • 21
  • 39
Tirki
  • 1
  • 2
    Surely this is because of NAT and is perfectly normal (insofar as NAT is normal). – Michael Hampton Sep 29 '21 at 00:13
  • DNAT happens pre-routing, and before the filter table is processed. Look at your nat table. – Zoredache Sep 29 '21 at 00:29
  • More likely I think that the NAT was done at an external router. – Michael Hampton Sep 29 '21 at 05:47
  • 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 Sep 30 '21 at 12:19
  • I spoke too soon. This IP tables tutorial shows the flow.https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES – Tirki Sep 30 '21 at 12:30
  • 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. – Tirki Sep 30 '21 at 22:44

1 Answers1

0

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.

Tomek
  • 2,950
  • 1
  • 15
  • 9
  • Thanks. Looks like I need to go down the IP tables rabbit hole before I understand this. – Tirki Sep 29 '21 at 10:44