[Swan] Advice on troubleshooting AWS VPC site-to-site VPN connection.

Paul Wouters paul at nohats.ca
Tue Oct 19 01:46:33 UTC 2021


On Mon, 18 Oct 2021, Scott Classen wrote:

> ping from left to EC2(10.0.2.252)
>
> tcpdump shows that a ping packet leaves left as UDP-encapsulated ESP packet:
>
> 11:03:17.230139 IP xxx.xxx.xxx.19.ipsec-nat-t > 52.9.186.125.ipsec-nat-t: UDP-encap: ESP(spi=0xc17c2033,seq=0x15), length 132
>
> Then arrives and leaves the EC2 instance as regular ICMP packets
>
> 18:03:17.233191 IP xxx.xxx.xxx.19 > 10.0.2.252: ICMP echo request, id 5630, seq 1, length 64
> 18:03:17.233222 IP 10.0.2.252 > xxx.xxx.xxx.19: ICMP echo reply, id 5630, seq 1, length 64
>
> and arrives back at left as a regular icmp packet.
>
> 11:03:17.234656 IP 54.151.19.230 > xxx.xxx.xxx.19: ICMP echo reply, id 5630, seq 1, length 64
>
> and ipsec trafficstatus shows only outgoing ESP traffic. There are no inBytes. This is what is concerning me the most.
>
> # ipsec trafficstatus
> 006 #19: "conn-to-aws-1/1x1", type=ESP, add_time=1634578592, inBytes=0, outBytes=0, id='52.9.186.125'
> 006 #21: "conn-to-aws-1/1x3", type=ESP, add_time=1634578675, inBytes=0, outBytes=0, id='52.9.186.125'
> 006 #20: "conn-to-aws-1/2x1", type=ESP, add_time=1634578643, inBytes=0, outBytes=0, id='52.9.186.125'
> 006 #15: "conn-to-aws-1/2x3", type=ESP, add_time=1634578312, inBytes=0, outBytes=1344, id='52.9.186.125'
> 006 #16: "conn-to-aws-2/1x1", type=ESP, add_time=1634578373, inBytes=0, outBytes=0, id='54.151.120.103'
> 006 #22: "conn-to-aws-2/1x2", type=ESP, add_time=1634578698, inBytes=0, outBytes=0, id='54.151.120.103'
> 006 #17: "conn-to-aws-2/2x1", type=ESP, add_time=1634578410, inBytes=0, outBytes=0, id='54.151.120.103'
> 006 #18: "conn-to-aws-2/2x2", type=ESP, add_time=1634578525, inBytes=0, outBytes=0, id=’5hen a 4.151.120.103’

It is highly likely that the packet is getting NAT'ed after the
decryption, so that the returning packet no longer matches the
IPsec policy, won't get encrypted and comes back plaintext as
appearing from another IP? This would explain the only outbytes
combined with:

> and no XFRM errors in the kernel tables:
>
> cat /proc/net/xfrm_stat
> XfrmInError             	0
> XfrmInBufferError       	0
> XfrmInHdrError          	0
> XfrmInNoStates          	0
> XfrmInStateProtoError   	0
> XfrmInStateModeError    	0
> XfrmInStateSeqError     	0
> XfrmInStateExpired      	0
> XfrmInStateMismatch     	0
> XfrmInStateInvalid      	0
> XfrmInTmplMismatch      	0
> XfrmInNoPols            	0
> XfrmInPolBlock          	0
> XfrmInPolError          	0
> XfrmOutError            	0
> XfrmOutBundleGenError   	0
> XfrmOutBundleCheckError 	0
> XfrmOutNoStates         	0
> XfrmOutStateProtoError  	0
> XfrmOutStateModeError   	0
> XfrmOutStateSeqError    	0
> XfrmOutStateExpired     	0
> XfrmOutPolBlock         	0
> XfrmOutPolDead          	0
> XfrmOutPolError         	0
> XfrmFwdHdrError         	0
> XfrmOutStateInvalid     	0
> XfrmAcquireError        	0

No IPsec errors, so there were no packets that arrived plaintext when
they should have been encrypted or encrypted and not matching policy.

For each host that performs NAT or MASQ, ensure that for each remote
subnet, you add a iptables -t nat -I POSTROUTING -j RETURN -d
remote/mask to prevent accidentally NATing packets.

Paul


More information about the Swan mailing list