[Openswan Users] Openswan does not appear to create the correct routes on both sides

Wed Sep 18 12:25:00 UTC 2013

Your server and aconns do not match at all. I would rename the server
connto something like roadwarrior and move some of the settings into
conn %default - the ones which would apply to every conn such as left,
leftnexthop (probably not needed) possibly pfs and auto and add
leftsourceip (the server's LAN IP). Create a new conn which you could
call aconn if you wanted. The server's aconn should pretty much match
the remote's aconn with left and right reversed. (Generally wou don't
need to reverse left and right at each end but the use of conn %default
means you must). I would also suggest enabling PFS for aconn. 

On 2013-09-18 09:49, Paul Young wrote: 

> Hi Everyone, 
> 
> I am in the deep end with Openswan and possibly the following will show that. Apologies! 
> 
> So far I have been relying heavily on this - http://www.jacco2.dds.nl/networking/openswan-l2tp.html [4] 
> 
> A little bit of background first. We have a just opened a new office and not all the infrastructure is in place as yet. 
> 
> So the idea is to use a site to site VPN back to the current office so that all resources can be reached. 
> 
> There is a server acting as the openswan VPNgateway etc in both offices - current office and new office. 
> 
> The current office has a number of site to site configs already in place to third parties. I have configured a server side which looks like this: 
> 
> _conn server_ 
> _ authby=secret_ 
> _ pfs=no_ 
> _ auto=add_ 
> _ keyingtries=3_ 
> _ type=transport_ 
> _ forceencaps=yes_ 
> _ right=%any_ 
> _ #rightsubnet=vhost:%priv,%no_ 
> _ rightprotoport=17/%any_ 
> _ # Using the magic port of "0" means "any one single port". This is_ 
> _ # a work around required for Apple OSX clients that use a randomly_ 
> _ # high port, but propose "0" instead of their port. Could also be 17/%any_ 
> _ left=<my outside fixed IP address>_ 
> _ leftnexthop=<my outside fixed IP address next hop>_ 
> _ leftprotoport=17/1701_ 
> _ # Apple iOS doesn't send delete notify so we need dead peer detection_ 
> _ # to detect vanishing clients_ 
> _ dpddelay=10_ 
> _ dpdtimeout=90_ 
> _ dpdaction=clear_ 
> 
> behind that is some ppp and xl2tp settings that work well for some of our remote types. but I am looking at pure Ipsec at this point. 
> 
> In the new office I have set up a conn like this: 
> 
> _conn aconn_ 
> _ authby=secret_ 
> _ left=192.168.3.3_ 
> _ #left=%any_ 
> _ leftid=@vpn_ 
> _ leftnexthop=%defaultroute_ 
> _ leftsourceip=192.168.3.3_ 
> _ leftsubnet=192.168.3.0/24 [5]_ 
> _ right=__<my outside fixed IP address>_ 
> _ rightsubnets={10.134.162.59/32 [6] 10.134.210.64/28 [7] 192.168.1.0/24 [8]}_ 
> _ type=tunnel_ 
> _ auto=start_ 
> _ pfs=no_ 
> _ salifetime=28800s_ 
> _ ikelifetime=86400s_ 
> 
> It sits behind a router so left is the local interface. And the subnets are back in the current office. 
> 
> It comes up ok: 
> 
> _# service ipsec status_ 
> _IPsec running - pluto pid: 11869_ 
> _pluto pid 11869_ 
> _3 tunnels up_ 
> _some eroutes exist_ 
> 
> I see the routes come up ok on the new office side: 
> 
> _# ip xfrm policy_ 
> _src 192.168.3.0/24 [5] dst 10.134.162.59/32 [6]_ 
> _ dir out priority 2336 ptype main_ 
> _ tmpl src 192.168.3.3 dst 203.215.150.142_ 
> _ proto esp reqid 16385 mode tunnel_ 
> _src 10.134.162.59/32 [6] dst 192.168.3.0/24 [5]_ 
> _ dir fwd priority 2336 ptype main_ 
> _ tmpl src 203.215.150.142 dst 192.168.3.3_ 
> _ proto esp reqid 16385 mode tunnel_ 
> _src 10.134.162.59/32 [6] dst 192.168.3.0/24 [5]_ 
> _ dir in priority 2336 ptype main_ 
> _ tmpl src 203.215.150.142 dst 192.168.3.3_ 
> _ proto esp reqid 16385 mode tunnel_ 
> _src 192.168.3.0/24 [5] dst 10.134.210.64/28 [7]_ 
> _ dir out priority 2340 ptype main_ 
> _ tmpl src 192.168.3.3 dst 203.215.150.142_ 
> _ proto esp reqid 16389 mode tunnel_ 
> _src 10.134.210.64/28 [7] dst 192.168.3.0/24 [5]_ 
> _ dir fwd priority 2340 ptype main_ 
> _ tmpl src 203.215.150.142 dst 192.168.3.3_ 
> _ proto esp reqid 16389 mode tunnel_ 
> _src 10.134.210.64/28 [7] dst 192.168.3.0/24 [5]_ 
> _ dir in priority 2340 ptype main_ 
> _ tmpl src 203.215.150.142 dst 192.168.3.3_ 
> _ proto esp reqid 16389 mode tunnel_ 
> _src 192.168.3.0/24 [5] dst 192.168.1.0/24 [8]_ 
> _ dir out priority 2344 ptype main_ 
> _ tmpl src 192.168.3.3 dst 203.215.150.142_ 
> _ proto esp reqid 16393 mode tunnel_ 
> _src 192.168.1.0/24 [8] dst 192.168.3.0/24 [5]_ 
> _ dir fwd priority 2344 ptype main_ 
> _ tmpl src 203.215.150.142 dst 192.168.3.3_ 
> _ proto esp reqid 16393 mode tunnel_ 
> _src 192.168.1.0/24 [8] dst 192.168.3.0/24 [5]_ 
> _ dir in priority 2344 ptype main_ 
> _ tmpl src 203.215.150.142 dst 192.168.3.3_ 
> _ proto esp reqid 16393 mode tunnel_ 
> 
> Can't ping anything back in the current office from the new office even though I can see encapsulated traffic going across at the time of my ping - nothing comes back. 
> 
> I also don't see anything being created in the xfrm policy for the current office and if I add a rightsubnet(s) line to the current office config then the road runners types can't connect. 
> 
> Is what I am trying to do even possible? 
> 
> Thanks, 
> Paul 
> 
> _______________________________________________
> Users at lists.openswan.org
> https://lists.openswan.org/mailman/listinfo/users [1]
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy [2]
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 [3]

Links:
------
[1] https://lists.openswan.org/mailman/listinfo/users
[2] https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
[3]
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
[4] http://www.jacco2.dds.nl/networking/openswan-l2tp.html
[5] http://192.168.3.0/24
[6] http://10.134.162.59/32
[7] http://10.134.210.64/28
[8] http://192.168.1.0/24
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20130918/35b63153/attachment.html>