This is a discussion on DNAT packets not getting to FORWARD chain within the Linux Networking forums, part of the Linux Forums category; Hi, I've got: WinXP PC ------ SmoothWall 1 (with OpenSwan) ----- internet ---- Smoothwall 2 (with OpenSwan ) --- Win2k PC 192.168.3....
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Hi,
I've got: WinXP PC ------ SmoothWall 1 (with OpenSwan) ----- internet ---- Smoothwall 2 (with OpenSwan ) --- Win2k PC 192.168.3.214 192.168.3.230 ipsec tunnel 192.168.1.230 192.168.1.40 (Hopefully that looks ok when you widen your window.) Anyway, its a simple setup (the smoothwalls, fyi are a red hat flavour kernel 2.4.26, iptables v1.2.8) The problem seems to be on the 192.168.3.x side so that's what I'm describing henceforth. ifconfig on Smoothwall 1 shows eth0 (192.168.3.230), ppp0 and ipsec0. route shows a route for 192.168.1.x destinations through ipsec0. I can ping from my WinXP machine to 192.168.1.40 fine. (the ipsec tunell works fine) Ok, here's the tricky part: On the WinXP machine is a program that sends a packet out to UDP:255.255.255.255:2050 and then listens on port 2050 for replies. Well, the server for this particular program is on the win2k machine (192.168.1.40). I've put this rule in my nat table: iptables -A PREROUTING -t nat -i eth0 -p UDP --destination-port 2050 -j DNAT 192.168.1.40:2050 I run the client program a few times and it times out saying it couldn't find the server. if I then iptables -L -t nat -v, Chain PREROUTING (policy ACCEPT 1515 packets, 82760 bytes) pkts bytes target prot opt in out source destination 15 1275 DNAT udp -- eth0 any anywhere anywhere udp dpt:2050 to:192.168.1.40 those 15 packets are definately the 255.255.255.255 from the client program - I've checked this. But the forward chain (iptables -L -v) is empty - no packets have entered it - nevermind being dropped. The chain policy count is zero, as are the counts for all rules in the FORWARD chain. SO - although those packets supposedly been readdressed to 192.168.1.40 ( an address I can ping succesfully ) - they never found their way to the forward chain. Which would make me think the route was not setup correctly - but then howcome the ping works??? HELP -gavin |