Score:0

AWS Site-to-Site VPN with Strongswan - can't ping from strongswan to AWS

ng flag

I'm trying to set up an AWS Site-to-Site VPN to Digital Ocean with strongswan.

  • I can ping from AWS to my DO instance's private IP.
  • I cannot ping from DO to AWS's private IP.

I have all inbound traffic allowed for my AWS instance, and when I run tcpdump I see that my AWS instance is receiving the ping from DO and is attempting to reply:

22:03:24.901827 IP 169.254.218.10 > ip-172-31-28-61.ec2.internal: ICMP echo request, id 10, seq 563, length 64
22:03:24.901860 IP ip-172-31-28-61.ec2.internal > 169.254.218.10: ICMP echo reply, id 10, seq 563, length 64
22:03:25.925918 IP 169.254.218.10 > ip-172-31-28-61.ec2.internal: ICMP echo request, id 10, seq 564, length 64
22:03:25.925953 IP ip-172-31-28-61.ec2.internal > 169.254.218.10: ICMP echo reply, id 10, seq 564, length 64

Additional information that may be useful:

# On VPN Instance

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 7e:4a:52:24:d1:b4 brd ff:ff:ff:ff:ff:ff
    inet x.x.x.x/20 brd x.x.x.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.10.0.6/16 brd 10.10.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::7c4a:52ff:fe24:d1b4/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 5e:a1:57:5e:2e:8d brd ff:ff:ff:ff:ff:ff
    inet 10.136.197.163/16 brd 10.136.255.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::5ca1:57ff:fe5e:2e8d/64 scope link
       valid_lft forever preferred_lft forever
4: ip_vti0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
5: Tunnel1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1419 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip x.x.x.x peer 52.87.54.117
    inet 169.254.218.10 peer 169.254.218.9/30 scope global Tunnel1
       valid_lft forever preferred_lft forever
    inet6 fe80::200:5efe:89b8:139e/64 scope link
       valid_lft forever preferred_lft forever

$ ip route
default via x.x.x.x dev eth0 proto static
10.10.0.0/16 dev eth0 proto kernel scope link src 10.10.0.6
10.136.0.0/16 dev eth1 proto kernel scope link src 10.136.197.163
x.x.x.0/20 dev eth0 proto kernel scope link src x.x.x.x
169.254.218.8/30 dev Tunnel1 proto kernel scope link src 169.254.218.10
172.31.0.0/16 dev Tunnel1 scope link

$ sudo iptables -t nat --list
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

$ iptables -t mangle --list
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
MARK       esp  --  ec2-y-y-y-y.compute-1.amazonaws.com  ubuntu-s-1vcpu-1gb-nyc1-01  MARK set 0x64

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
TCPMSS     tcp  --  anywhere             anywhere             tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

How should I go about debugging this issue?

Tim avatar
gp flag
Tim
Asymmetric networking issues check NACLs and maybe AWS route tables first.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.