On Tuesday 04 February 2003 08:20 pm, llee@battalion.nexxis.net wrote: > Hi, > > I wish to create a FreeSWAN VPN connection between two NAT boxes using > iptables. I have FreeSWAN configured correctly, but when I attempt to > ping one internal machine from the other network, the packets get > mangled by what I assume to be NAT. Source Host sends out 4 icmp > packets at 504 bytes, and the Target Host receives 4 packets at 240 > bytes. > > The way I have the iptables scripts set up is on each box like this: > > iptables -t nat -A POSTROUTING -o eth0 -s $IP_RANGE_A -d $IP_RANGE_B > -j ACCEPT > iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source $INET_IP > > the only difference being the swapping of the IP_RANGES depending upon > which box it's on. I am still getting the same results. I am trying > to get all VPN-ed packets to bypass the NAT statement, but it appears > that my statement is not working. Is there another way to get those > VPN packets through without getting mangled? First, I've never worked with passing VPN through iptables. Second, I have doubts whether the SNAT is the cause of the problem, seeing that you lose roughly 50% of the packet. Nevertheless, since it appears there have been no other replies to your query, I offer the following: First, use "iptables -t nat -Z" to zero the counts, try your connection, then use "iptables -t nat -L -v -n" and check if the number of packets matching each rule are what you expect them to be. Try the following rules to bypass SNAT for those connections: iptables -t nat -A POSTROUTING -o eth0 -s $IP_RANGE_A -d ! $IP_RANGE_B -j SNAT --to $INET_IP iptables -t nat -A POSTROUTING -o eth0 -s ! $IP_RANGE_A -d ! $IP_RANGE_B -j SNAT --to $INET_IP iptables -t nat -A POSTROUTING -o eth0 -s ! $IP_RANGE_A -d $IP_RANGE_B -j SNAT --to $INET_IP Of course if $IP_RANGE_A represents the full addressspace that could come through this rule as a sourceIP going out eth0, OR if the only connections to IP_RANGE_B would be VPN regardless of source, only the first rule is needed (and the "-s" part is redundant then). If the only traffic out of IP_RANGE_A AND the only traffic going to IP_RANGE_B would be VPN you only need the second one. All three taken together will SNAT everything except traffic that is from IP_RANGE_A AND to IP_RANGE_B. (However, I would have expected your two rule above to accomplish this...) Multiple matches in a single rule are always a logical AND, so you have to pay attention with multiple NOTs involved as well. If this isn't a solution I'd suggest the following three approaches: Examine the actual contents of the packets, both pre-firewall at sender and post-firewall at receiver, and see if you can discern what is happening to the missing ~50%, and see if IP's are intact and as expected. Disable SNAT and test it. (since apparently this connection is possible without SNATting, just remove the SNAT entirely for testing purposes) If the opportunity exists, try the same configuration but with the two NAT boxes simply plugged into a mutual hub, to ensure that nothing else between them is the source of the problem. (If they are at quite disparate locations, just replicate the setup of the remote box on a local one for the testing, perhaps ghost the local box to a similarly-configured box and replicate the iptables setup) j > I appreciate any help in advance. > > Thanks, > Lonlone
