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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
