up vote 2 down vote favorite
share [g+] share [fb]

I'm trying to NAT HTTP traffic, I'm new to this and facing some issues. What i'm trying to do is NAT client HTTP requests to a webserver.

CLIENT -> NAT BOX -> WEBSERVER

When the client open the IP of the NAT BOX, the request should be pass to the web server.

But I'm getting "HTTP request sent, awaiting response..." and then wait serveral minutes before the request is done.

Looking at the tcpdump output, it looks like the first Syn packet on (10:48:54) is being NAT but not the second, third, fourth... ACK or PSH packets, and wait until (10:52:04) it starts NAT again on the ACK packet.

The iptables command I'm using is:

iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 \
 -j DNAT --to-destination WEBSERVER

I'm wondering what could have caused this behavior?

Thanks alot.

10:48:54.907861 IP (tos 0x0, ttl  49, id 16395, offset 0, flags [DF],
 proto: TCP (6), length: 48) CLIENT.61736 > NATBOX.http: S,
 cksum 0x6019 (correct), 1589600740:1589600740(0) win 5840 <mss 1460,nop,wscale 8>

10:48:54.907874 IP (tos 0x0, ttl  48, id 16395, offset 0, flags [DF],
 proto: TCP (6), length: 48) CLIENT.61736 > WEBSERVER.http: S,
 cksum 0xb5d7 (correct), 1589600740:1589600740(0) win 5840 <mss 1460,nop,wscale 8>

10:48:55.102696 IP (tos 0x0, ttl  49, id 16397, offset 0, flags [DF],
 proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: .,
 cksum 0x2727 (correct), ack 2950613896 win 23

10:48:55.102963 IP (tos 0x0, ttl  49, id 16399, offset 0, flags [DF],
 proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120)
 ack 1 win 23

10:48:58.103078 IP (tos 0x0, ttl  49, id 16401, offset 0, flags [DF],
 proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120)
 ack 1 win 23

10:48:58.366344 IP (tos 0x0, ttl  49, id 16403, offset 0, flags [DF],
 proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: .,
 cksum 0x26af (correct), ack 1 win 23

10:49:04.103204 IP (tos 0x0, ttl  49, id 16405, offset 0, flags [DF],
 proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120)
 ack 1 win 23

10:49:04.363943 IP (tos 0x0, ttl  49, id 16407, offset 0, flags [DF],
 proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: .,
 cksum 0x26af (correct), ack 1 win 23

10:49:16.101583 IP (tos 0x0, ttl  49, id 16409, offset 0, flags [DF],
 proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120)
 ack 1 win 23

10:49:16.363475 IP (tos 0x0, ttl  49, id 16411, offset 0, flags [DF],
 proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: .,
 cksum 0x26af (correct), ack 1 win 23

10:49:40.100796 IP (tos 0x0, ttl  49, id 16413, offset 0, flags [DF],
 proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120)
 ack 1 win 23

10:49:40.563898 IP (tos 0x0, ttl  49, id 16415, offset 0, flags [DF],
 proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: .,
 cksum 0x26af (correct), ack 1 win 23

10:50:28.099396 IP (tos 0x0, ttl  49, id 16417, offset 0, flags [DF],
 proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120)
 ack 1 win 23

10:50:28.761678 IP (tos 0x0, ttl  49, id 16419, offset 0, flags [DF],
 proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: .,
 cksum 0x26af (correct), ack 1 win 23

10:52:04.093668 IP (tos 0x0, ttl  49, id 16421, offset 0, flags [DF],
 proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120)
 ack 1 win 23

10:52:04.093678 IP (tos 0x0, ttl  48, id 16421, offset 0, flags [DF],
 proto: TCP (6), length: 160) CLIENT.61736 > WEBSERVER.http: 
 P 1589600741:1589600861(120) ack 2950613896 win 23

10:52:04.291021 IP (tos 0x0, ttl  49, id 16423, offset 0, flags [DF],
 proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: .,
 cksum 0x25d3 (correct), ack 217 win 27

10:52:04.291028 IP (tos 0x0, ttl  48, id 16423, offset 0, flags [DF],
 proto: TCP (6), length: 40) CLIENT.61736 > WEBSERVER.http: .,
 cksum 0x7b91 (correct), ack 217 win 27

10:52:04.300708 IP (tos 0x0, ttl  49, id 16425, offset 0, flags [DF],
 proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: .,
 cksum 0x253c (correct), ack 368 win 27

10:52:04.300714 IP (tos 0x0, ttl  48, id 16425, offset 0, flags [DF],
 proto: TCP (6), length: 40) CLIENT.61736 > WEBSERVER.http: .,
 cksum 0x7afa (correct), ack 368 win 27

10:52:04.301417 IP (tos 0x0, ttl  49, id 16427, offset 0, flags [DF],
 proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: F,
 cksum 0x253b (correct), 120:120(0) ack 368 win 27

10:52:04.301438 IP (tos 0x0, ttl  48, id 16427, offset 0, flags [DF],
 proto: TCP (6), length: 40) CLIENT.61736 > WEBSERVER.http: F,
 cksum 0x7af9 (correct), 120:120(0) ack 368 win 27

10:52:04.498875 IP (tos 0x0, ttl  49, id 16429, offset 0, flags [DF],
 proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: .,
 cksum 0x253a (correct), ack 369 win 27

10:52:04.498881 IP (tos 0x0, ttl  48, id 16429, offset 0, flags [DF],
 proto: TCP (6), length: 40) CLIENT.61736 > WEBSERVER.http: .,
 cksum 0x7af8 (correct), ack 369 win 27
link|improve this question
Could you add the output for: 'iptables -vnL FORWARD' and 'iptables -vnL -t nat' ? If you are using 'src host' on tcpdump, that is the problem for which you dont see traffic coming back, just use 'host' – Torian Feb 16 '11 at 3:48
'iptables -vnL FORWARD' is empty, nat table only has the one NAT rule in PREROUTING chain. – user70932 Feb 16 '11 at 4:21
iptables -vnL -t nat , should shows how many packet hit the rule . – vnix27 Feb 16 '11 at 5:11
Chain PREROUTING (policy ACCEPT 38 packets, 11645 bytes) pkts bytes target prot opt in out source destination 2 232 DNAT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:WEBSERVER:80 – user70932 Feb 16 '11 at 5:27
So 38 packet matching your rule. Is it increasing fastly while accessing through http – vnix27 Feb 16 '11 at 7:04
show 1 more comment
feedback

3 Answers

up vote 0 down vote

Does WEBSERVER knows that CLIENT ia reachable through NAT BOX? D'u'wanna SNAT CLIENT to look like NAT BOX for WEBSERVER, don't ya?

link|improve this answer
I'm doing triangle routing, the WEBSERVER SNAT return packets directly to CLIENT, which seems working fine, just not sure why it needs to wait serveral minutes in the middle. – user70932 Feb 16 '11 at 4:14
I'm not sure you know what you're doing. As it's usual it's better describe what you wan't to achieve, not how you're trying. Why does dump show Client -> Natbox? Isn't it supposed to be transparent? If not, the simplest thing is proxy (even xinetd) @ Natbox. – poige Feb 16 '11 at 5:06
Basically what I want to do is CLIENT->NATBOX->WEBSERVER->CLIENT. so NATBOX route HTTP packets to WEBSERVER use DNAT, WEBSERVER return respose to CLIENT use SNAT bypassing the NATBOX. It looks like it's working as expected, the client will eventually get the webpage requested. but the things is I'm not sure why it takes so long to finally process the request, so I tcpdump the NATBOX and see some of the packets doesn't seem to be DNAT/routing to the WEBSERVER. Something I'm missing? – user70932 Feb 16 '11 at 5:09
feedback
up vote 0 down vote

Did u enabled ip forwarding on NAT_BOX ?

link|improve this answer
yep. it's enabled. – user70932 Feb 16 '11 at 5:16
then there should be some mistakes on SNAT part , whats your SNAt entry on NAT BOX – vnix27 Feb 16 '11 at 7:15
jengelh.medozas.de/images/dnat-mistake.png, may help your – vnix27 Feb 16 '11 at 7:18
the SNAT will not go through the NAT BOX. Return packets from the WEBSERVER will go to the CLIENT directly with source IP rewritten to NAT BOX IP. I think it's call triangle/asymmetric routing. If there is a mistake then the HTTP request shouldn't be completed at all, but right now it's able to complete the http request after serveral minutes wait, which is the thing i don't understand, what is it doing in that serveral minutes. – user70932 Feb 16 '11 at 7:47
feedback
up vote 0 down vote

It seems like the kind of routing you are trying to setup is called Direct Routing. It is usualy used to load-balance traffic between servers (it allows to avoid the router bottleneck from the server to the client as the path is direct in this direction).

You can find a detailed explaination of Direct Routing configuration and theory on LVS site.

link|improve this answer
thanks for the info, it seems Direct Routing is a little bit different as the boxes needs to be in a physical segment. The one I'm trying to setup doesn't need to be in a physical segment. – user70932 Feb 16 '11 at 16:07
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.