[Openswan Users] VPN to VPN routing problem
GregScott at InfraSupportEtc.com
Sat May 31 02:15:38 EDT 2008
Also make sure your conn definitions include all 3 subnets - 1.0, 2.0, and 3.0. From your 1.nn/3.nn gateway, take a look at ip route show and see what subnets route where. If you don't have any tunnel definition that references 3.nn, then the 3.nn stuff will follow a default path instead of going thru the tunnel the way you want.
Two tunnels ending on the same machine is not a big deal - I have a few of these at customer sites. But you gotta make sure your tunnels include all the appropriate subnets.
Another way to do it might be to have one tunnel with, say, rightsubnet 192.168.0.0/16 and leftsubnet 192.168.2.0/24. This seems a little bit weird but I have a network setup this way that works fine.
It may also be possible to setup your wireless router as a pure access point and get rid of wireless routing. I've had mixed success with this approach, but it eliminates a routing hop if you can get it to work. The idea is, you set up your wireless router as a pure AP and connect your Openswan system into one of its LAN ports instead of its WAN port. Give the wireless router a 2.nn IP Address in its LAN side and either disable the WAN side or give it a bogus IP Address. So then it acts as a pure bridge and your wireless clients get all their DHCP info from your 2.nn DHCP server. Everyone on this side of the tunnel is on the same LAN this way and you eliminate a need to a complex tunnel scheme. Some wireless routers are smart enough to handle this, others, well, YMMV.
From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On Behalf Of Peter McGill
Sent: Friday, May 30, 2008 2:22 PM
To: 'Roland Plüss'; users at openswan.org
Subject: Re: [Openswan Users] VPN to VPN routing problem
This is probably due to a misconfiguration on the 192.168.3.0/24 vpn gateway machine.
Typically it is caused by:
Masquerading the lan traffic to the internet and IPSec traffic is not exempted.
ie) If you have iptables -t nat -A POSTROUTING -o eth1 -s 192.168.3.0/24 -j MASQUERADE Insert these before:
iptables -t nat -I POSTROUTING -o eth1 -s 192.168.3.0/24 -d 192.168.1.0/24 -j ACCEPT iptables -t nat -I POSTROUTING -o eth1 -s 192.168.3.0/24 -d 192.168.2.0/24 -j ACCEPT
If that is not the case, you can send an ipsec barf, then I can review it for other possible causes.
ipsec barf > ipsec_barf.txt
It will contain a lot of useful information for debugging your ipsec connections.
Your private/secret keys however are not listed for security.
Attach the whole file and email me directly, rather than sending the big file to the list.
IT Systems Analyst
Gra Ham Energy Limited
> -----Original Message-----
> From: users-bounces at openswan.org
> [mailto:users-bounces at openswan.org] On Behalf Of Roland Plüss
> Sent: May 30, 2008 2:53 PM
> To: users at openswan.org
> Subject: [Openswan Users] VPN to VPN routing problem
> I've got here a bit a particular setup and somehow can't get
> everything to work as it should. First a little drawing of what we
> [ 192.168.2.0/24 ] <-> [ gateway at 192.168.2.1 ] <- - VPN - internet
> -> [ gateway at 192.168.1.10 ] (*1,*2)
> *1 <-> [ 192.168.1.0/24 ]
> *2 <- - VPN - wifi - -> [192.168.3.0/24 ]
> - I can ping from 192.168.1.0/24 to 192.168.2.0/24 and 192.168.3.0/24
> - I can ping from 192.168.2.0/24 to 192.168.1.0/24
> - I can ping from 192.168.3.0/24 to 192.168.1.0/24
> - I can * * NOT * * ping from 192.168.3.0/24 to 192.168.2.0/24
> Hence everything works except pinging from the (3) network to the (2)
> network which are two individual VPN with end points on the same
> machine. I tested with tcpdump and what happens is that the pings from
> (3) are send out to the internet instead of through the VPN to (2).
> (1) to (2) this works without a problem so I assume it's a problem
> with two VPN's ending on the same machine.
> Any ideas why such a config could fail?
Users at openswan.org
Building and Integrating Virtual Private Networks with Openswan:
More information about the Users