Matthew Closson wrote: > In setting up about 30 ISPEC tunnels on an OpenBSD box in the past 6 > months I had this issue come up with about 4 of the remote peers. > Typically it is one of two problems. > > 1. They have a made a policy level decision somewhere and say they will > only route traffic to public IP's or they want to assign you a public IP > from their IP space. Typically this is because they don't want to deal > with the issue of multiple remote networks sharing the same private IP > space. > > 2. Your IP space conflicts with another existing IP space they are > routing to across another tunnel so they need you to NAT and make it > look like you are coming from somewhere else. > > So here is what you can do: > > 1. Place another box in front of your box doing IPSEC and NAT the > traffic before it gets there based on its destination. I got my setup > working fine this way. Cheap boxes are easy to come by for simply doing > NAT.
I don't see how this would work. We can't NAT traffic after it's encapsulated -- so the NAT must be happening before IPsec encryption -- in other words, the extra NAT device goes between the internal network and the IPsec device. What if I have multiple VPNs in the same scenario? The only way I can see this working is if I run a bunch of overlapping subnets between the NAT and IPsec devices... that just sounds insane. I realise I'm probably missing or misunderstanding something here, but I could use the insight. Thanks, -Stephen-
