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

Paul Young paul at arkig.com
Sat Sep 21 05:52:59 UTC 2013


Thanks for the reply Nick,

Well I can bring them up despite their types being different - perhaps
theory is removed from practice in this case.

I have set up the iptables rules already at this point. And depending on of
I try a host to site connection or a site to site connection I change them.

So far I have been able to get host to site working. But not site to site
for reasons already stated - 4G dongle appears to behave differently than
what a standard fixed IP carrier connection would.

I'll try your previous suggestion as well as continue with the host to site
idea.

Thanks,
Paul


On 21 September 2013 06:32, Nick Howitt <n1ck.h0w1tt at gmail.com> wrote:

>  You can't use the oldoffice conn for connection to the new office. For a
> start they have different transport types.
>
> You do need internal firewall rules. I have one set like this:
>
> iptables -t nat -I POSTROUTING -m policy --dir out --pol ipsec -j ACCEPT
>
> Nick
>
>
> On 20/09/2013 09:39, Paul Young wrote:
>
> Hi Nick,
>
>  Yes the new office appears to create the correct xfrm policies\routing
> info.
>
>  Part of the complexity here would be that the new office has no
> permanent IP or infrastructure. So the path looks like this from new to old
>
>  server running Openswan in new office------------->Asus router\switch
> N55U running DHCP etc------------>4G dongle acting as modem for the
> Asus--------------->INTERNET-------------->outside NIC of server running
> Openswan in old office.
>
>  From what I can tell there is some machinations going on within the 4G
> dongle so that nmap against the internet routable address the dongle comes
> up with always returns "all 1000 scanned ports on <address blah> are
> filtered" - which could be making things difficult.
>
>  So today I played some more (I will try your suggestions on the weekend
> though) with these configs-
>
>  new office side:
>
>  conn newoffice
>         authby=secret
>         left=192.168.3.3
>         leftid=@newoffice
>         leftnexthop=%defaultroute <- the ASUS router
>         leftsourceip=192.168.3.3
>         leftsubnet=192.168.3.0/24
>         right=<outside address of old office>
>         rightsubnet=192.168.1.0/24
>         type=tunnel
>         auto=start
>         pfs=no
>         salifetime=28800s
>         ikelifetime=86400s
>
>  new office side:
>
>  conn oldoffice
>         authby=secret
>         pfs=no
>         auto=add
>         keyingtries=3
>         type=transport
>         forceencaps=yes
>         right=%any
>         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
>         #leftprotoport=17/1701
>         left=<outside address of old office>
>         leftnexthop=<outside address of old office next hop>
>         leftsubnet=192.168.1.0/24
>          rightsubnet=192.168.3.0/24
>         # Apple iOS doesn't send delete notify so we need dead peer
> detection
>         # to detect vanishing clients
>          dpddelay=10
>         dpdtimeout=90
>         dpdaction=clear
>
>  In this case once I created a static route on my workstation like so:
>
>  Network Destination        Netmask          Gateway       Interface
>  Metric
>       192.168.1.0    255.255.255.0      192.168.3.3    192.168.3.101     11
>
>  I was able to ping anything on the 192.168.1.0/24 subnet in the old
> office.
>
>  BUT - if I add more subnets to see the networks that are currently
> configured as site to site connections in the old office I am unable to see
> those in terms of ping and connectivity.
>
>  Paul
>
>
> On 19 September 2013 17:25, Nick Howitt <n1ck.h0w1tt at gmail.com> wrote:
>
>>  In conn current your leftsubnet should be a leftsubnets to match the
>> rightsubnets. While right is not fixed, you may want to try %any but you
>> will have to use the same psk as your roadwarriors. You will also want DPD
>> with dpdaction=clear for when the remote IP changes. I also prefer pfs=yes
>> (or remove it). I don't think any of these issues are causing your problem,
>> however, as you are getting your tunnels.
>>
>> Can you ping between the two Openswan devices?
>>
>> In your new office, does your gateway device have routes redirecting
>> traffic 192.168.1.0/24, 10.134.210.64/28 and 10.134.162.59 via
>> 1192.168.3.3?
>>
>> I'd need to check firewalling when I'm at home. Is "new" running a
>> firewall. Presumably it is just a standalone PC on the "new" LAN.
>>
>>
>>
>> Nick
>>
>> On 2013-09-19 02:45, Paul Young wrote:
>>
>> 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/20130921/3265fc6c/attachment-0001.html>


More information about the Users mailing list