On 2014-08-21, Vincent Gross <dermi...@kilob.yt> wrote: > here is the routing table on the gateway once S[AP] are installed: > > Encap: > Source Port Destination Port Proto > SA(Address/Proto/Type/Direction) > 192.168.55.220/32 0 192.168.56.1/32 0 0 > 37.160.166.168/esp/use/in > 192.168.56.1/32 0 192.168.55.220/32 0 0 > 37.160.166.168/esp/require/out > default 0 default 0 0 none/esp/deny/out > > Yet, tcpdump on gateway's enc0 shows this: > > tcpdump: listening on enc0, link-type ENC > tcpdump: WARNING: compensating for unaligned libpcap packets > 11:29:00.455369 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > > 37.160.166.168.16215: P 1027357934:1027357978(44) ack 3953089614 win 2112 (DF) > [tos 0x10] (encap) > 11:29:00.456355 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > > 37.160.166.168.16215: P 44:88(44) ack 1 win 2112 (DF) [tos 0x10] (encap)
I've reported problems like this before, where traffic is handled by IPsec that shouldn't be - and mostly (or possibly always) connected with IPsec flows that restrict traffic by protocol. > When I got this dump, I already had an SSH connection between laptop and > gateway, and I tried to connect to gateway's 222/tcp using telnet. > > In my previous message, I put a tcpdump trace showing what happens when > I try to establish a TCP connection: I had the TCP handshake completed > over raw IP, the laptop sent its first data packet, but I had no > response whatsoever, just a bunch of ESP packets. > > So This is what I conclude form all that stuff: > 1) IPSec parameters are negociated between ikeds > 2) gateway installs SPs and SAs > 3) TCP handshake goes on raw IP, no problem > 4) gateway routes all established TCP flows through IPSec, including those > already established and not matched by the installed SPs ... > > I ran a test over UDP using inetd echo on gateway, and nc -u on the > laptop. After the gateway installed the SAs and SPs, I had no problem > having the data I sent form the laptop to the gateway echoed back, so > whatever is going on during the routing phase, it leaves UDP traffic > alone. I have seen it with UDP as well, at least DNS and NTP traffic. > I will update both systems tonight with the latest snapshot, and seen if > the problem persists. It has persisted for at least several years :(
