[ previous ] [ next ] [ threads ]
 
 From:  "Tomas Florian" <tflorian at telus dot net>
 To:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Lost ack when doing incoming NAT
 Date:  Thu, 26 Aug 2004 08:44:48 -0600
Hello,
 
I'm trying to do the following simple thing but it doesn't work:
 
Incoming NAT (I need to forward all external traffic destined to port 25 to
my internal machine):
139.142.206.22 (Test source) -> 142.173.221.18:25 (WAN IP - Monowall) ->
192.168.1.103:25 (Internal mail server - destination)
 
To understand what is going on, I setup tcpdump on both my source and
destination machines:
 
 
Source view (139.142.206.22 is just some machine on the outside where I type
telnet 142.173.221.18 25 to test for connection):
tcpdump -n port 25
 
08:21:43.591028 139.142.206.22.1358 > 142.173.221.18.25: S
2887640829:2887640829(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp
317477882 0> (DF) [tos 0x10] 
--- Looks good to me.  Sends SYN to my destination . right?
 
 
Destination view (192.168.1.103 on the internal network):
tcpdump -ni eth0 port 25
 
08:10:45.702613 IP 139.142.206.22.1358 > 192.168.1.103.smtp: S
2887640829:2887640829(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp
317477882 0> 
--- Looks good also.  Receives the SYN sent from the source.
08:10:45.702679 IP 192.168.1.103.smtp > 139.142.206.22.1358: S
2818271626:2818271626(0) ack 2887640830 win 5792 <mss 1460,nop,nop,timestamp
38455008 317477882,nop,wscale 0>  
-- Now its looking promising because it even ack's the SYN . BUT this packet
is never received by the source side 
08:10:48.699829 IP 139.142.206.22.1358 > 192.168.1.103.smtp: S
2887640829:2887640829(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp
317478182 0>  
--- This looks like it just keeps trying again and again until it times out 
08:10:48.699897 IP 192.168.1.103.smtp > 139.142.206.22.1358: S
2818271626:2818271626(0) ack 2887640830 win 5792 <mss 1460,nop,nop,timestamp
38458006 317477882,nop,wscale 0>
 
So in summary the problem seems to be the following.  Everything works fine
up to the point when destination sends ack back to the source.  The ack
never arrives.  It gets lost on the way back to the source.   Since there is
no tcpdump on the monowall (or is there?), I don't know where it gets lost.
But I definitely don't have any firewall anywhere between my source IP and
my Monowall (not that I know of anyway).  So my assumption is that monowall
looses it.
 
Any ideas?  Why monowall looses it?  I have a rule that says that all
traffic from my LAN should be allowed through. 
 
Thanks for any tips or leads,
 
Tomas