[Openswan Users] Openswan does not appear to create the correct routes on both sides
Paul Young
paul at arkig.com
Thu Sep 19 01:45:08 UTC 2013
Hi Nick,
Thanks for the response. I have confused the situation as you have
suggested.
So now my configs looks like this:
In the current office Openswan (one interface connects directly to the
outside world)-
conn current
authby=secret
left=<my fixed internet IP>
leftid=@current
leftnexthop=<my fixed internet IP next hop>
leftsubnet=192.168.1.0/24
leftsourceip=192.168.1.2
right=<non fixed IP of the new office router>
rightsubnets= { 192.168.3.0/24 }
type=tunnel
auto=start
pfs=no
ikelifetime=86400s
salifetime=28800s
note that the new office does not have a fixed IP address (it will in the
future, but people are moving in before the carrier has that ready)
The current config of the new office-
conn new
authby=secret
left=192.168.3.3
leftid=@new
leftnexthop=%defaultroute
leftsourceip=192.168.3.3
leftsubnet=192.168.3.0/24
right=<my fixed internet IP of current office>
rightsubnets={10.134.162.59/32 10.134.210.64/28 192.168.1.0/24}
type=tunnel
auto=start
pfs=no
salifetime=28800s
ikelifetime=86400s
So far I can bring up the new office tunnel but can't ping anything on the
other side.
000 initiating all conns with alias='new'
104 "new/0x3" #25: STATE_MAIN_I1: initiate
003 "new/0x3" #25: received Vendor ID payload [Openswan (this version)
2.6.32 ]
003 "new/0x3" #25: received Vendor ID payload [Dead Peer Detection]
003 "new/0x3" #25: received Vendor ID payload [RFC 3947] method set to=109
106 "new/0x3" #25: STATE_MAIN_I2: sent MI2, expecting MR2
003 "new/0x3" #25: NAT-Traversal: Result using RFC 3947 (NAT-Traversal):
both are NATed
108 "new/0x3" #25: STATE_MAIN_I3: sent MI3, expecting MR3
003 "new/0x3" #25: received Vendor ID payload [CAN-IKEv2]
004 "new/0x3" #25: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp2048}
117 "new/0x1" #26: STATE_QUICK_I1: initiate
117 "new/0x2" #27: STATE_QUICK_I1: initiate
117 "new/0x3" #28: STATE_QUICK_I1: initiate
004 "new/0x1" #26: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
mode {ESP=>0x28d68261 <0x554dc93f xfrm=AES_128-HMAC_SHA1 NATOA=none
NATD=<my fixed internet IP of current office>:4500 DPD=none}
004 "new/0x2" #27: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
mode {ESP=>0x0021555f <0xa7d4a5fb xfrm=AES_128-HMAC_SHA1 NATOA=none
NATD=<my fixed internet IP of current office>:4500 DPD=none}
004 "new/0x3" #28: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
mode {ESP=>0xb1e4e80f <0xa82a3d85 xfrm=AES_128-HMAC_SHA1 NATOA=none
NATD=<my fixed internet IP of current office>:4500 DPD=none}
I can't bring up the tunnel from the current office to the new office
though - I suspect IPtables might be involved there but am not sure as I
would of thought these rules would be fine which are in place for road
runner types:
-A INPUT -p udp --dport 500 -j ACCEPT
-A INPUT -p udp --dport 4500 -j ACCEPT
and on the new office side I have
-A INPUT -p udp --dport 500 -s <my fixed internet IP of current office> -j
ACCEPT
-A INPUT -p udp --dport 4500 -s <my fixed internet IP of current office> -j
ACCEPT
Thanks for trying to help me here.
Paul
On 18 September 2013 22:25, Nick Howitt <n1ck.h0w1tt at gmail.com> wrote:
> **
>
> 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
>
> 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 VPN\gateway 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*
> * right=**<my outside fixed IP address>*
> * rightsubnets={10.134.162.59/32 10.134.210.64/28 192.168.1.0/24}*
> * 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 dst 10.134.162.59/32*
> * 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 dst 192.168.3.0/24*
> * 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 dst 192.168.3.0/24*
> * 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 dst 10.134.210.64/28*
> * 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 dst 192.168.3.0/24*
> * 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 dst 192.168.3.0/24*
> * 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 dst 192.168.1.0/24*
> * 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 dst 192.168.3.0/24*
> * 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 dst 192.168.3.0/24*
> * 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.orghttps://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan:http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>
>
> _______________________________________________
> Users at lists.openswan.org
> https://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20130919/c50ad178/attachment-0001.html>
More information about the Users
mailing list