[strongSwan] AWS VTI basic connectivity

[Tom Harbert]

Hi,

I have what seems like a really basic problem with an IPSec tunnel using
VTI's to AWS where I can not ping the remote side of the directly connected
tunnel interface.

The host is running Ubuntu 14.04, the strongswan version is 5.1.2, and the
kernel is 3.19.0-25-generic.

# ip route | grep 169.254.253.4
169.254.253.4/30 dev vti2  proto kernel  scope link  src 169.254.253.6

# ip tunnel show vti2
vti2: ip/ip  remote x.x.x.x  local y.y.y.y  ttl inherit  nopmtudisc key 32

# cat /etc/ipsec.conf | grep 32
        mark=32

# ip addr show vti2
5: vti2 at NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1436 qdisc noqueue state
UNKNOWN group default
    link/ipip y.y.y.y peer x.x.x.x
    inet 169.254.253.6/30 scope global vti2
       valid_lft forever preferred_lft forever

# ping 169.254.253.5
PING 169.254.253.5 (169.254.253.5) 56(84) bytes of data.
...


The IPSec tunnel is established and the counters increment:

# ipsec statusall USW1LP-tunnel-1 | grep bytes
USW1LP-tunnel-1{2}:  AES_CBC_128/HMAC_SHA1_96, 17808 bytes_i (212 pkts, 0s
ago), 17808 bytes_o (212 pkts, 0s ago), rekeying in 42 minutes

# ipsec statusall USW1LP-tunnel-1 | grep bytes
USW1LP-tunnel-1{2}:  AES_CBC_128/HMAC_SHA1_96, 18144 bytes_i (216 pkts, 0s
ago), 18144 bytes_o (216 pkts, 0s ago), rekeying in 42 minutes

tcpdump shows the request leaving and the reply returning:

# tcpdump -i vti2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vti2, link-type RAW (Raw IP), capture size 65535 bytes
01:17:36.424350 IP 169.254.253.6 > 169.254.253.5: ICMP echo request, id
16379, seq 345, length 64
01:17:36.506958 IP 169.254.253.5 > 169.254.253.6: ICMP echo reply, id
16379, seq 345, length 64
01:17:37.424365 IP 169.254.253.6 > 169.254.253.5: ICMP echo request, id
16379, seq 346, length 64
01:17:37.506964 IP 169.254.253.5 > 169.254.253.6: ICMP echo reply, id
16379, seq 346, length 64

There are no iptables rules.

This is working on another install with the same configuration however with
a 3.16.0-30-generic kernel.  I havent included the ipsec.conf configuration
as it seems to be more of a basic linux networking issue.  Am I doing
something obviously wrong or missing something?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150824/c9ace90c/attachment.html>