[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