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