Some IP frames not nated with IPFW + NATD

  • Thread starter Deleted member 45312
  • Start date
D

Deleted member 45312

Guest


Dear FreeBSD users,

This my first post and my English is a bit bad, so please be indulgent.

I am running FreeBSD 10.1 amd64 on my personal Internet gateway and all is working flawlessly. This gateway is in front of my home private network made of about 10 devices (PCs, smartphones, etc ...). I have only one public IP address and I use the IP private range 192.168.0.0/24 for my private network.
But I saw in the log file /var/log/security of IPFW running on my gateway that sometime external machines on the Internet are trying to connect to machines behind my gateway on my private address range.
Then I tried to investigate how they are knowing which private network addresses I am using, by running tcpdump on the interface facing the Internet :
Code:
# tcpdump -i rl0 -XX -w tcpdump.out -vvv host 192.168.0.10
After some time, I got some frames which are not nated and I looked at that with wireshark. All those frames are warned [TCP ZeroWindow] by wireshark.
I don't know why those frames are going out from my private network.
 
OP
D

Deleted member 45312

Guest


Thank you jrm,
I didn't know that mailing list but I think I will wait a bit on this forum before (I don't want to go into source code now).
 

getopt

Aspiring Daemon

Reaction score: 445
Messages: 731

Do you mind sharing some of your dumped samples with us?
Without that it would be hard to say anything meaningful.
 
OP
D

Deleted member 45312

Guest


Here is an extract of my gateway /var/log/security:
Code:
Mar 24 11:34:06 chene kernel: ipfw: 400 Deny UDP 192.3.34.58:53951 88.176.XXX.XXX:1900 in via rl0
Mar 24 11:40:22 chene kernel: ipfw: 400 Deny ICMP:3.3 82.165.214.82 192.168.0.10 in via rl0
Mar 24 11:42:55 chene kernel: ipfw: 400 Deny TCP 222.186.21.208:6000 88.176.XXX.XXX:5901 in via rl0
Mar 24 11:43:58 chene kernel: ipfw: 400 Deny TCP 222.186.21.208:6000 88.176.XXX.XXX:3344 in via rl0
Mar 24 11:45:06 chene kernel: ipfw: 400 Deny TCP 198.154.243.13:15106 88.176.XXX.XXX:7071 in via rl0
Mar 24 11:45:52 chene kernel: ipfw: 400 Deny UDP 124.195.156.9:53 88.176.XXX.XXX:7368 in via rl0
Mar 24 11:48:51 chene kernel: ipfw: 400 Deny TCP 222.186.30.215:6000 88.176.XXX.XXX:2222 in via rl0
Mar 24 11:52:47 chene kernel: ipfw: 400 Deny TCP 195.222.58.189:9990 88.176.XXX.XXX:135 in via rl0
Mar 24 11:52:55 chene last message repeated 2 times
Mar 24 11:54:55 chene kernel: ipfw: 400 Deny UDP 61.240.144.65:60000 88.176.XXX.XXX:514 in via rl0
Mar 24 11:56:48 chene kernel: ipfw: 400 Deny TCP 88.250.178.33:39939 88.176.XXX.XXX:23 in via rl0
Mar 24 11:59:09 chene kernel: ipfw: 400 Deny UDP 212.27.40.240:53 192.168.0.10:33175 in via rl0
Mar 24 11:59:09 chene kernel: ipfw: 400 Deny UDP 212.27.40.241:53 192.168.0.10:17512 in via rl0
Mar 24 11:59:10 chene kernel: ipfw: 400 Deny UDP 212.27.40.241:53 192.168.0.10:53994 in via rl0
Mar 24 11:59:11 chene kernel: ipfw: 400 Deny UDP 212.27.40.240:53 192.168.0.10:48164 in via rl0
Mar 24 11:59:11 chene kernel: ipfw: 400 Deny UDP 212.27.40.240:53 192.168.0.10:4085 in via rl0
Mar 24 11:59:16 chene kernel: ipfw: 400 Deny UDP 212.27.40.241:53 192.168.0.10:36375 in via rl0
Mar 24 11:59:16 chene kernel: ipfw: 400 Deny UDP 212.27.40.241:53 192.168.0.10:5738 in via rl0
Mar 24 11:59:21 chene kernel: ipfw: 400 Deny UDP 212.27.40.241:53 192.168.0.10:64163 in via rl0
Mar 24 11:59:22 chene kernel: ipfw: 400 Deny UDP 212.27.40.240:53 192.168.0.10:57288 in via rl0
Mar 24 11:59:22 chene kernel: ipfw: 400 Deny UDP 212.27.40.241:53 192.168.0.10:34252 in via rl0
Mar 24 12:00:23 chene kernel: ipfw: 400 Deny UDP 212.27.40.240:53 88.176.XXX.XXX:58439 in via rl0
88.176.XXX.XXX is my public IP and 212.27.40.{240,241} are my ISP DNS.
As you can see, they are trying to connect to my private IP 192.168.0.10.
192.168.0.10 is my workstation on my local network behind my gateway.

And while I was editing my reply here is what I got on my gateway with tcpdump on the interface facing the Internet:
Code:
root@chene:~ # tcpdump -i rl0 host 192.168.0.10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on rl0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:34:17.281898 IP merisier.25719 > d.forums.freebsd.org.https: Flags [.], ack 2699083107, win 0, length 0
18:35:32.400368 IP merisier.23228 > d.forums.freebsd.org.https: Flags [.], ack 3443454587, win 0, length 0
18:37:08.020366 IP merisier.19858 > d.forums.freebsd.org.https: Flags [.], ack 211906993, win 0, length 0
 

getopt

Aspiring Daemon

Reaction score: 445
Messages: 731

88.176.XXX.XXX is my public IP and 212.27.40.{240,241} are my ISP DNS.
As you can see, they are trying to connect to my private IP 192.168.0.10.
192.168.0.10 is my workstation on my local network behind my gateway.
what I got on my gateway with tcpdump on the interface facing the Internet:
Code:
root@chene:~ # tcpdump -i rl0 host 192.168.0.10
Is interface rl0 host 192.168.0.10 facing the Internet? How many NICs does your gateway have?
 
OP
D

Deleted member 45312

Guest


No, 192.168.0.10 is my workstation and is not directly connected to the Internet. It default route to my Internet gateway.
My Internet gateway have two NICs: rl0 and re0. rl0 is facing the Internet and re0 is connected to my private network (192.168.0.0/24).
 
OP
D

Deleted member 45312

Guest


My firewall does not block DNS query, but is blocking all inbound traffic from non-routable reserved address spaces like 192.168.0.10/24 via rl0.
As you can see my ISP DNS is seeing my private network address and is sending IP frame to it.
I think this is due to those so called 'TCP ZeroWindow' which are not nated. All other outbound traffic is nated correctly and all my computers behind my firewalled gateway are accessing the Internet without any problems.
natd(8) is working flawlessly, except for those IP frames.
 
OP
D

Deleted member 45312

Guest


tcpdump is showing me that outgoing TCP ZeroWindow frames are not nated.
And how do you think those machines on the Internet are knowing my private IP address ?
 
OP
D

Deleted member 45312

Guest


Yes, the TCP ZeroWindow is disturbing, but those frames are going out not nated because with the filter host 192.168.0.10 on tcpdump, I should see nothing going through rl0.
 
OP
D

Deleted member 45312

Guest


My gateway is mostly idle as you can see below:
Code:
last pid:  4165;  load averages:  0.31,  0.31,  0.26  up 0+13:03:47  21:26:52
70 processes:  1 running, 69 sleeping
CPU:  0.0% user,  0.0% nice,  0.2% system,  0.2% interrupt, 99.6% idle
Mem: 21M Active, 109M Inact, 206M Wired, 155M Buf, 3268M Free
Swap: 4096M Total, 4096M Free
I don't know why those TCP ZeroWindow are going out.
 
OP
D

Deleted member 45312

Guest


For information, I have translated my ipfw(8) ruleset to pf.conf(5), and replaced ipfw(8) by PF firewall.
Since, I haven't seen any non nated TCP ZeroWindow going out using tcpdump(1) on rl0 !

But my problem is currently left unresolved, it seems that something was wrong with ipfw(8) + natd(8).

I am posting here my ipfw.rules and natd.conf for those who are interested.
 

Attachments

Top