[Openswan Users] site to site ipsec VPN. local endpoint replies with a host unreachable.
users-bounces at lists.openswan.org
users-bounces at lists.openswan.org
Sun Nov 24 14:17:47 UTC 2013
Rescued from the spam bucket. Please remember to subscribe to the mailing list before posting to it.
From: Michael Closson <mclosson at lambda.closson.ca>
Subject: Re: [Openswan Users] site to site ipsec VPN. local endpoint replies with a host unreachable.
Date: November 24, 2013 at 2:17:39 PM EST
To: users at lists.openswan.org
Oh. I found the problem.
After disabling IP masquerading on the local side, site to site VPN works now.
*nat
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
#-A POSTROUTING -o eth0 -j MASQUERADE
Success!!
Michael Closson
On Sun, Nov 24, 2013 at 01:49:54PM -0500, Michael Closson wrote:
> Hi Paul.
>
> Thank-you for your reply!
>
> After (on a whim) trying host to site VPN rather than site to site VPN, I can
> confirm that ESP isn't being filtered. See below for the details.
>
> The problem remains that the local VPN endpoint is generating a ICMP host
> unreachable.
>
> Is there anyway I can enable some kernel level debugging? I'll check and see
> what google can suggest.
>
> Some additional information. (3 things)
>
> 1)
>
> I tried your suggestion. Same symptoms. Seems that the enc part works
> because tcpdump showed the expected output.
>
> 13:25:13.761769 IP 173.192.251.47.4500 > 24.212.xxx.xxx.4500: NONESP-encap: isakmp: phase 2/others ? inf[E]
> 13:25:13.761978 IP 24.212.201.xxx.xxx > 173.192.251.47.4500: NONESP-encap: isakmp: phase 2/others ? inf[E]
> 13:25:17.765236 IP 24.212.201.xxx.xxx > 173.192.251.47.4500: isakmp-nat-keep-alive
> 13:25:17.765258 IP 24.212.201.xxx.xxx > 173.192.251.47.4500: isakmp-nat-keep-alive
> 13:25:18.801498 IP 173.192.251.47.4500 > 24.212.xxx.xxx.4500: NONESP-encap: isakmp: phase 2/others ? inf[E]
> 13:25:18.801732 IP 24.212.xxx.xxx.4500 > 173.192.251.47.4500: NONESP-encap: isakmp: phase 2/others ? inf[E]
> 13:25:23.850583 IP 173.192.251.47.4500 > 24.212.xxx.xxx.4500: NONESP-encap: isakmp: phase 2/others ? inf[E]
>
> But the local VPN endpoint still sends out ICMP host unreachable.
>
> 2)
>
> On a whim, I tried host to site VPN. On the softlayer side I configured
> 24.212.xxx.xxx/32 as the local side. I used the following config on the
> local side.
>
> [root at lambda ipsec.d]# cat softlayer.conf
> conn softlayer
> type=tunnel
> authby=secret
> auto=start
> left=%defaultroute
> #leftsubnet=172.16.0.0/16
> #leftsourceip=172.16.1.201
> right=173.192.251.47
> rightsubnet=10.100.128.128/26
> pfs=yes
> forceencaps=yes
>
> Now I can ping hosts inside softlayer.
>
> [root at lambda ipsec.d]# ping 10.100.128.131
> PING 10.100.128.131 (10.100.128.131) 56(84) bytes of data.
> 64 bytes from 10.100.128.131: icmp_seq=1 ttl=61 time=49.1 ms
> 64 bytes from 10.100.128.131: icmp_seq=2 ttl=61 time=39.8 ms
> 64 bytes from 10.100.128.131: icmp_seq=3 ttl=61 time=44.8 ms
> ^C
> --- 10.100.128.131 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2405ms
> rtt min/avg/max/mdev = 39.829/44.615/49.155/3.815 ms
>
>
> Here is the relevant tcpdump.
>
> 13:29:05.636046 IP 24.212.xxx.xxx.4500 > 173.192.251.47.4500: NONESP-encap: isakmp: phase 2/others ? inf[E]
> 13:29:09.820978 IP 24.212.xxx.xxx.4500 > 173.192.251.47.4500: UDP-encap: ESP(spi=0xd3637cf1,seq=0x6e), length 132
> 13:29:09.870074 IP 173.192.251.47.4500 > 24.212.xxx.xxx.4500: UDP-encap: ESP(spi=0x8b12936d,seq=0x26), length 132
> 13:29:09.870074 IP 10.100.128.131 > 24.212.xxx.xxx: ICMP echo reply, id 18988, seq 1, length 64
> 13:29:10.822214 IP 24.212.xxx.xxx.4500 > 173.192.251.47.4500: UDP-encap: ESP(spi=0xd3637cf1,seq=0x6f), length 132
> 13:29:10.862001 IP 173.192.251.47.4500 > 24.212.xxx.xxx.4500: UDP-encap: ESP(spi=0x8b12936d,seq=0x27), length 132
> 13:29:10.862001 IP 10.100.128.131 > 24.212.xxx.xxx: ICMP echo reply, id 18988, seq 2, length 64
> 13:29:11.824134 IP 24.212.xxx.xxx.4500 > 173.192.251.47.4500: UDP-encap: ESP(spi=0xd3637cf1,seq=0x70), length 132
> 13:29:11.868952 IP 173.192.251.47.4500 > 24.212.xxx.xxx.4500: UDP-encap: ESP(spi=0x8b12936d,seq=0x28), length 132
> 13:29:11.868952 IP 10.100.128.131 > 24.212.xxx.xxx: ICMP echo reply, id 18988, seq 3, length 64
>
>
> woohoo! progress.
>
> Looks like softlayer is doing some NATting on their end.
>
> [root at lambda ipsec.d]# ssh root at 10.100.128.131
> root at 10.100.128.131's password:
> Last login: Wed Nov 20 12:11:01 2013 from 10.0.80.184
> [root at xxx-private ~]# who
> root pts/0 2013-11-24 12:31 (10.1.22.46) <== HERE
> [root at xxx-private ~]# tty
> /dev/pts/0
>
> Seems that softlayer re-wrote the source IP from 24.212.xxx.xxx to 10.1.22.46.
>
> This is a problem because connections initiated from inside softlayer to
> the local-side host (24.212.xxx.xxx) don't go through the tunnel, but go
> unencrypted over the internet.
>
> 3)
>
> I also tried host to site but without forcing encapsulation and was able to
> ping and ssh to hosts on the softlayer side.
>
> 13:40:24.860619 IP 24.212.xxx.xxx > 173.192.251.47: ESP(spi=0xd3637da8,seq=0x2c), length 100
> 13:40:26.190404 IP 24.212.xxx.xxx > 173.192.251.47: ESP(spi=0xd3637da8,seq=0x2d), length 132
> 13:40:26.229591 IP 173.192.251.47 > 24.212.xxx.xxx: ESP(spi=0x92886450,seq=0x21), length 132
> 13:40:26.229591 IP 10.100.128.131 > 24.212.xxx.xxx: ICMP echo reply, id 35117, seq 1, length 64
> 13:40:27.191744 IP 24.212.xxx.xxx > 173.192.251.47: ESP(spi=0xd3637da8,seq=0x2e), length 132
> 13:40:27.233203 IP 173.192.251.47 > 24.212.xxx.xxx: ESP(spi=0x92886450,seq=0x22), length 132
> 13:40:27.233203 IP 10.100.128.131 > 24.212.xxx.xxx: ICMP echo reply, id 35117, seq 2, length 64
> 13:40:28.193343 IP 24.212.xxx.xxx > 173.192.251.47: ESP(spi=0xd3637da8,seq=0x2f), length 132
> 13:40:28.233588 IP 173.192.251.47 > 24.212.xxx.xxx: ESP(spi=0x92886450,seq=0x23), length 132
> 13:40:28.233588 IP 10.100.128.131 > 24.212.xxx.xxx: ICMP echo reply, id 35117, seq 3, length 64
>
>
> So ESP is definitely not being filtered.
>
>
>
> On Sun, Nov 24, 2013 at 12:45:52PM -0500, Paul Wouters wrote:
>> On Sat, 23 Nov 2013, Michael Closson wrote:
>>
>>> Site to site VPN, ping from local site, local VPN endpoint generates ICMP
>>> host unreachable.
>>>
>>> I'm using CentOS 6.4
>>> Openswan IPsec U2.6.32/K2.6.32-358.23.2.el6.x86_64...
>>>
>>> The remote side is the IaaS company SoftLayer.
>>>
>>> Here is the network map
>>>
>>> 172.16.0.0/16
>>> |
>>> 172.16.1.201==24.212.xxx.xxx --- 173.192.251.47
>>> |
>>> |
>>> ???
>>> |
>>> |
>>> 10.100.128.128/26
>>>
>>> If I run 'ping 10.100.128.130' on 172.16.1.18, then 172.16.1.201 replies
>>> with ICMP host unreachable.
>>
>>> Here is my ipsec config file. (lambda is 172.16.1.201)
>>>
>>> [root at lambda ipsec.d]# cat softlayer.conf
>>> conn softlayer
>>> type=tunnel
>>> authby=secret
>>> auto=start
>>> left=%defaultroute
>>> leftsubnet=172.16.0.0/16
>>> leftsourceip=172.16.1.201
>>> right=173.192.251.47
>>> rightsubnet=10.100.128.128/26
>>> pfs=yes
>>
>> That looks good.
>>
>>> [root at lambda ipsec.d]# ip xfrm state
>>> src 173.192.251.47 dst 24.212.xxx.xxx
>>> proto esp spi 0xd04fb5e2 reqid 16385 mode tunnel
>>> replay-window 32 flag 20
>>> auth hmac(sha1) 0xc8e849ee498bbe3453dfa2a9a84e837926fe9675
>>> enc cbc(aes) 0xa98dee1f3574083b2d19ed95699f92e4
>>> src 24.212.xxx.xxx dst 173.192.251.47
>>> proto esp spi 0xd3636bcf reqid 16385 mode tunnel
>>> replay-window 32 flag 20
>>> auth hmac(sha1) 0xf28bd49f9608e03e0130784a829054e1038a3fe4
>>> enc cbc(aes) 0xc73abb30f3078aa3a382ec2daad50ea5
>>>
>>> [root at lambda ipsec.d]# ip xfrm policy | head -12
>>> src 172.16.0.0/16 dst 10.100.128.128/26
>>> dir out priority 2598 ptype main
>>> tmpl src 24.212.xxx.xxx dst 173.192.251.47
>>> proto esp reqid 16385 mode tunnel
>>> src 10.100.128.128/26 dst 172.16.0.0/16
>>> dir fwd priority 2598 ptype main
>>> tmpl src 173.192.251.47 dst 24.212.xxx.xxx
>>> proto esp reqid 16385 mode tunnel
>>> src 10.100.128.128/26 dst 172.16.0.0/16
>>> dir in priority 2598 ptype main
>>> tmpl src 173.192.251.47 dst 24.212.xxx.xxx
>>> proto esp reqid 16385 mode tunnel
>>
>> Same here, look good. Perhaps there is an ESP filter somewhere? Try adding
>> forceencaps=yes to force ESPinUDP?
>>
>> Paul
>> --
>> Libreswan Developer - https://libreswan.org/
>> Red Hat Security - http://people.redhat.com/pwouters/
>> Personal Blog - https://nohats.ca/
> _______________________________________________
> 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/20131124/774d8da6/attachment-0001.html>
More information about the Users
mailing list