On Wed, Aug 20, 2014 at 03:23:29PM +0200, Vincent Gross wrote: > Hi folks, > > I am trying to set up an IPSec VPN between my OpenBSD-current laptop and > my OpenBSD-current gateway at home. The gateway is connected with plain > old ADSL + PPPoE, and the laptop uses my smartphone tethering functions. > > laptop has a vether(4) with 192.168.55.220/24 configured and up, and > gateway has a vether(4) with 192.168.56.1/24 configured and up. Yeah I > could do without, but I've mainly seen examples where the tunnel > outgoing interface was different from the routed range interface, and > wanted to make sure it was not due to some weird address overlap. > > What goes on is, when I start both iked, negociation completes, but: > 1) only the gateway installs the SA and SP, laptop does not > 2) I am not able to go beyond the TCP three-way-handshake when > connecting from laptop to gateway. > > I tcpdump'd the traffic on outgoing interfaces: every packet that is > sent by one side is received by the other. I can observe traffic on > gateway's enc0, but nothing on laptop's enc0 (which makes sense as SA > and SP are not installed). >
I dug a bit more, here is what I found: 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) 11:29:00.456969 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: P 88:132(44) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:00.457439 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: P 132:176(44) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:00.499455 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: P 176:1228(1052) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:00.499731 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: P 1228:2280(1052) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:00.499922 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: P 2280:3332(1052) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:00.500189 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: P 3332:3648(316) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:01.516927 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: . 0:1300(1300) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:03.517208 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: . 0:1300(1300) ack 1 win 2112 (DF) [tos 0x10] (encap) 11:29:05.788337 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.222 > 37.160.166.168.16413: P 1881608350:1881608371(21) ack 183195314 win 2112 (DF) (encap) 11:29:07.517778 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: . 0:1300(1300) ack 1 win 2112 [tos 0x10] (encap) 11:29:11.788250 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.222 > 37.160.166.168.16413: P 0:21(21) ack 1 win 2112 (DF) (encap) 11:29:14.714265 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.222 > 37.160.166.168.16413: . ack 2 win 2112 (DF) (encap) 11:29:14.714609 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.222 > 37.160.166.168.16413: F 21:21(0) ack 2 win 2112 (DF) (encap) 11:29:15.518775 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.22 > 37.160.166.168.16215: . 0:1300(1300) ack 1 win 2112 [tos 0x10] (encap) 11:29:16.137495 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.222 > 37.160.166.168.16413: F 21:21(0) ack 2 win 2112 (DF) (encap) 11:29:23.789811 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.222 > 37.160.166.168.16413: FP 0:21(21) ack 2 win 2112 (DF) (encap) 11:29:25.130637 (authentic,confidential): SPI 0xa5ba5ce9: 79.143.250.153.222 > 37.160.166.168.16413: F 21:21(0) ack 2 win 2112 (DF) (encap) 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 will update both systems tonight with the latest snapshot, and seen if the problem persists. -- Vincent / dermiste [demime 1.01d removed an attachment of type application/pgp-signature]
