[Openswan Users] site to site ipsec VPN. local endpoint replies with a host unreachable.
Michael Closson
openswan-users at closson.ca
Sun Nov 24 18:49:54 UTC 2013
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/
More information about the Users
mailing list