[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