2

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 several 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?

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
Improve this question
7
  • 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, 2011 at 3:48
  • 'iptables -vnL FORWARD' is empty, nat table only has the one NAT rule in PREROUTING chain.
    – user70932
    Feb 16, 2011 at 4:21
  • iptables -vnL -t nat , should shows how many packet hit the rule .
    – vnix27
    Feb 16, 2011 at 5:11
  • Did you enable ip forwarding on NAT_BOX ?
    – vnix27
    Feb 16, 2011 at 5:14
  • 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, 2011 at 5:27

2 Answers 2

Reset to default
0

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?

Improve this answer
3
  • 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, 2011 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, 2011 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, 2011 at 5:09
0

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.

Improve this answer
1
  • 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, 2011 at 16:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .