You are not currently logged in. If you do not have a user account then please consider creating one and logging in before you post your comment. This will allow you to track replies to your comment, and take part in the site much more freely.

To add your comment, fill in all the boxes below and then preview it to make sure you're happy with the way that it looks.

This is the comment you were replying to, attached to the weblog svn hangs caused by crappy router/NAT topology

#2 Re: svn hangs caused by crappy router/NAT topology Posted by dkg (216.254.xx.xx) on Fri 9 Nov 2007 at 15:22 Really? with a simple NAT configuration, this is probably true, but most consumer-grade routers (and most iptables management scripts) allow for this by re-mapping the client's LAN IP (the source IP address) to the router's internal IP address. So it would be a quartet of iptables rules to achieve this effect of forwarding external HTTP connections (on port 80, that is) to $HTTP_TARGET, like so: iptables -A INPUT -m state --state NEW -p tcp -d "$HTTP_TARGET" --dport 80 -j ACCEPT iptables -A FORWARD -m state --state NEW -p tcp -d "$HTTP_TARGET" --dport 80 -j ACCEPT iptables -t nat -A PREROUTING -d "$ROUTER_WAN_IP" -p tcp --dport 80 -j DNAT --to "$HTTP_TARGET" iptables -t nat -A POSTROUTING -d "$HTTP_TARGET" -s "$LAN_NETWORK" -p tcp --dport 80 -j SNAT --to "$ROUTER_LAN_IP" the first two lines say it's ok to pass traffic to the internal device. The third line says "any connection coming in from the outside to my exterior port 80 should be mangled so that the destination IP points to the internal device". And the fourth line says "any connection coming from the internal network that wants to go to the internal web server should get mangled so that the source IP address is the router's own internal IP address". Why would any LAN device pass packets to the router to get to an internal device? Shouldn't they just pass it along the LAN? They would, normally. But they'd pass traffic intended for the external IP address to the router, which would rewrite the destination in its PREROUTING step. Then, before the packet leaves the router, the last rule would trigger. This last rule is necessary because otherwise the $HTTP_TARGET would respond directly to the local machine, which would ignore the response because it is looking for a response from $ROUTER_WAN_IP. So the packet has to make an additional hop back to the router for de-mangling (or re-mangling, depending on your perspective). This scenario is wasteful of LAN bandwidth, of course: Each internal packet now travels the LAN 4 times instead of once: client to router router to targeted server server to router router to client But this overhead is often considered worthwhile for ease of management, because the internal machines can think they're talking to the same IP address as everyone else. But when you run into a router that can't keep up with all this mangling at LAN speeds, like the device drgraefy describes above, then things fall apart.

Inappropriate comments will be removed.

Username:

Password:

[ Advanced Login ]

Register Account