You are correct in that the fact that the head end must know which of the 10 nets to send its traffic. It is easier to NAT at the conflicting end. It is possible to NAT at the head end but it is a little more complicated. I can explain how but a better use of the time may be to find out why your current set up is not working. Were you able to put the logging rules in place to see where in the netfilter processing you are breaking? - John On Fri, 2004-11-05 at 01:42, Chris Lyon wrote: > > -----Original Message----- > > From: netfilter-bounces@xxxxxxxxxxxxxxxxxxx [mailto:netfilter- > > bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jason Opperisano > > Sent: Wednesday, November 03, 2004 7:49 AM > > To: netfilter@xxxxxxxxxxxxxxxxxxx > > Subject: Re: NAT issues on a VPN tunnel > > > > On Tue, Nov 02, 2004 at 11:03:53PM -0800, Chris Lyon wrote: > > > > On Tue, 2004-11-02 at 19:35, Christopher Lyon wrote: > > > > > I believe that would cause a problem on the VPN tunnel as the > > endpoints > > > > > won't match. This would need to be done on the far end (site b). > > > > > > > > believe what you want--it works for me. > > > > > > So how do you build the tunnel? > > > > the tunnel is built between the public external IP's of the two > > gateways. > > > > in a scenario where site A and site B both use 10.0.0.0/24 as their > > internal network, and we need to build a VPN between them: > > > But that is not my case. I have three sites with the two remote sites being > in conflict. > > Site A 192.168.254.0/24 > Site B 10.10.0.0/16 > Site C 10.10.0.0/16 > > So, I would need to do the translation on the remote side, site B and site > C. > > Correct? I can't see doing this at the head end. > > > > > ------- > > Site A > > ------- > > ipsec.conf: > > leftsubnet=172.31.1.0/24 > > rightsubnet=172.31.2.0/24 > > > > # map our 10.0.0.0/24 to 172.31.1.0/24 when going over the VPN > > iptables -t nat -A POSTROUTING -o ipsec0 \ > > -s 10.0.0.0/24 -j NETMAP --to 172.31.1.0/24 > > > > # unmap packets from the other side to 172.31.1.0/24 to our 10.0.0.0/24 > > iptables -t nat -A PREROUTING -i ipsec0 \ > > -d 172.31.1.0/24 -j NETMAP --to 10.0.0.0/24 > > > > ------- > > Site B > > ------- > > ipsec.conf: > > leftsubnet=172.31.2.0/24 > > rightsubnet=172.31.1.0/24 > > > > # map our 10.0.0.0/24 to 172.31.2.0/24 when going over the VPN > > iptables -t nat -A POSTROUTING -o ipsec0 \ > > -s 10.0.0.0/24 -j NETMAP --to 172.31.2.0/24 > > > > # unmap packets from the other side to 172.31.2.0/24 to our 10.0.0.0/24 > > iptables -t nat -A PREROUTING -i ipsec0 \ > > -d 172.31.2.0/24 -j NETMAP --to 10.0.0.0/24 > > > > when someone in site A needs to connect to 10.0.0.100 in site B, they > > connect to 172.31.2.100. > > > > when someone in site B needs to connect to 10.0.0.100 in site A, they > > connect to 172.31.1.100. > > > > keep in mind that that packets are sent over the tunnel based on their > > destination address, not their source address. also keep in mind that > > the packets are still in the clear on ipsec* interfaces and encrypted on > > the physical interfaces. > > > > dunno if this helps any, but it works for me. this is how it makes > > sense to me in my head--that each side should perform it's own > > chicanery. i'm not saying it can't be made to work some other way. > > > > -j > > > > -- > > "'Nuke the whales?' You don't really believe that, do you? > > I dunno. Gotta nuke something." > > --The Simpsons > > -- John A. Sullivan III Chief Technology Officer Nexus Management +1 207-985-7880 john.sullivan@xxxxxxxxxxxxx
