[Firewall] transparent dnat timeouts

John Eikenberry jae at zhar.net
Sat Mar 7 16:35:15 CET 2009


John Eikenberry wrote:

> John Eikenberry wrote:
> 
> > The setting has an effect for when I disable the transparent_dnat trying to
> > go to web server immediately errors out. Whereas if I enable it the
> > connection suffers a timeout instead. So it seems like maybe the client
> > data is forwarded on to the server, but the server reply doesn't make it?
> > There is nothing in the log when this happens.
> 
> I've been trying various things to see if I could gain any insights into
> what was going on. First I watched the output of netstat on the web server
> while trying, no signs of a connection. So I tried tcpdump. I'm not overly
> familiar with this tool, but it seems to have shown that some packets are
> making it to the server from the firewall. While the browser is spinning, I
> get a series of 2 alternating packets from tcpdump.
> 
> $ tcpdump -nvv dst port 80
> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> 
> 22:39:48.687950 IP (tos 0x8, ttl  63, id 43450, offset 0, flags [DF],
> proto: TCP (6), length: 60) 192.168.1.7.43725 > 192.168.1.4.80: S, cksum
> 0x2894 (correct), 2809054172:2809054172(0) win 5840 <mss
> 1460,sackOK,timestamp 74541670 0,nop,wscale 7>
> 
> 22:39:48.688544 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto:
> TCP (6), length: 40) 192.168.1.7.43725 > 192.168.1.4.80: R, cksum 0x161b
> (correct), 2809054173:2809054173(0) win 0
> 
> 192.168.1.7 is the client (broser) while 192.168.1.4 is of course the web
> server.
 
Modified my dump to get the reply packet (below). I also ran tcpdump on the
client and saw that that first packet received by the server matches
exactly the packet sent by the client (which seems appropriate).


$ tcpdump -nvv host 192.168.1.7 and not port 22 and tcp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

10:17:04.767437 IP (tos 0x8, ttl  63, id 12687, offset 0, flags [DF],
proto: TCP (6), length: 60) 192.168.1.7.46676 > 192.168.1.4.80: S, cksum
0x5996 (correct), 1712926847:1712926847(0) win 5840 <mss
1460,sackOK,timestamp 85000688 0,nop,wscale 7>

10:17:04.767546 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto:
TCP (6), length: 60) 192.168.1.4.80 > 192.168.1.7.46676: S, cksum 0x203c
(correct), 1735189693:1735189693(0) ack 1712926848 win 5792 <mss
1460,sackOK,timestamp 85059646 85000688,nop,wscale 6>

10:17:04.767589 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto:
TCP (6), length: 40) 192.168.1.7.46676 > 192.168.1.4.80: R, cksum 0xdf46
(correct), 1712926848:1712926848(0) win 0


Hope people don't mind my monologue. Just trying to figure it out and
provide any data that might be helpful.

-- 

John Eikenberry
[jae at zhar.net - http://zhar.net]
[PGP public key @ http://zhar.net/jae_at_zhar_net.gpg]
______________________________________________________________
"Perfection is attained, not when no more can be added, but when no more 
 can be removed." -- Antoine de Saint-Exupery
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://rocky.eld.leidenuniv.nl/pipermail/firewall/attachments/20090307/2b9dc293/attachment.pgp>


More information about the Firewall mailing list