iptables masquerade nat portforwarding problem
My setup:
Linux box1: ppp0 ath0 (AP - wireless) iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE echo 1 > /proc/sys/net/ipv4/ip_forward Linux box2: ath0 (sta to box 1 ath0) eth1 (dhcp server to switch) iptables -t nat -A POSTROUTING -o ath0 -j MASQUERADE echo 1 > /proc/sys/net/ipv4/ip_forward webserver listening on port 80 Now this works fine for using the internet (computer gets lease from box2 eth1) but the problem comes in when directing incoming port 80 traffic destined for the ppp0 interface on box1 to the ath0 of box2. I have tried variations on box1 of the rule: iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 80 -j DNAT --to <ath0-box2-ip>:80 The webserver does respond on this address from box1 to box2 through telnet but gets a connection refused when going to the ppp0 address from anywhere (port 80). |
tcpdump is your friend.
do you see (using tcpdump) the connection attempt on ppp0? if not, then it's not your setup, it's something upstream. if you do, then try tcpdump on ath0 on box 2. this will let you narrow down where the session is getting rejected. |
Quote:
1. internet -> ppp0 -> webserver (on box1 - just a temporary server) 2. box1 -> box2 -> webserver (box2) 3. switch computer -> eth1(box2) -> webserver (box2) 4. switch computer -> eth1(box2) -> ath0(box2) -> ath0(box1) -> webserver Those all work so it seems like the iptables rules need to be adjusted and a upstream issue doesn't exist. |
hm, ok. insert a LOG rule just before the DNAT rule, so that the chain looks like this:
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 80 -j LOG iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 80 -j DNAT --to <ath0-box2-ip>:80 this should log connection attempts in /var/log/messages or /var/log/syslog. it'll help you see if the rule is getting engaged. (I don't think you need the :80 at the end of your DNAT rule, but I don't think it hurts either. in any case, simpler is always better) |
I did a sniff on ath0 box1 and got this (x's are ppp0 ip):
10.66.66.55:53813 -> x.x.x.x:80 x.x.x.x:80 -> 10.66.66.55:53813 This request was from the switch through box2 to box1 and back to box2 (i think). switch -> (eth1 -> ath0) -> (ath0 -> ppp0 -> ath0) -> (ath0) So that is totally wrong... Also, I just figured out that a request from an external source (internet) works just fine now with the original rules (must have overlooked). So, theres a funky route happening with local requests to the public ip. |
|
All times are GMT -5. The time now is 09:21 PM. |