Re: iked troubles, SA not installed
On 2014-08-21, Vincent Gross wrote: > here is the routing table on the gateway once S[AP] are installed: > > Encap: > Source Port DestinationPort Proto > SA(Address/Proto/Type/Direction) > 192.168.55.220/32 0 192.168.56.1/320 0 > 37.160.166.168/esp/use/in > 192.168.56.1/320 192.168.55.220/32 0 0 > 37.160.166.168/esp/require/out > default0 default0 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 :(
Re: iked troubles, SA not installed
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 DestinationPort Proto SA(Address/Proto/Type/Direction) 192.168.55.220/32 0 192.168.56.1/320 0 37.160.166.168/esp/use/in 192.168.56.1/320 192.168.55.220/32 0 0 37.160.166.168/esp/require/out default0 default0 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
iked troubles, SA not installed
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). both are running a fairly recent -current (no more than 10 days old). Any clues on what might be going ? Cheers, -- Vincent / dermiste ## gateway /etc/iked.conf: ikev2 esp proto icmp \ from 192.168.56.1 to 192.168.55.220 peer 37.160.239.206 \ psk "redacted" ## laptop /etc/iked.conf: ikev2 active esp proto icmp \ from 192.168.55.220 to 192.168.56.1 peer 79.143.250.153 \ psk "redacted" ## initial sa state on both machines: $ sudo ipsecctl -sa FLOWS: No flows SAD: No entries ## On gateway: $ sudo tcpdump -ni pppoe0 udp port 500 or 4500 or tcp port 222 tcpdump: listening on pppoe0, link-type PPP_ETHER tcpdump: WARNING: compensating for unaligned libpcap packets 14:57:16.480895 37.160.239.206.20603 > 79.143.250.153.4500:udpencap: isakmp v2.0 exchange IKE_SA_INIT cookie: 143d03ddc5809c39-> msgid: len: 520 14:57:16.531113 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: isakmp v2.0 exchange IKE_SA_INIT cookie: 143d03ddc5809c39->383ed0522188ecdc msgid: len: 432 14:57:17.226835 37.160.239.206.20603 > 79.143.250.153.4500:udpencap: isakmp v2.0 exchange IKE_AUTH cookie: 143d03ddc5809c39->383ed0522188ecdc msgid: 0001 len: 272 14:57:17.228337 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: isakmp v2.0 exchange IKE_AUTH cookie: 143d03ddc5809c39->383ed0522188ecdc msgid: 0001 len: 224 14:57:17.229556 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 2 len 376 (DF) [tos 0x10] 14:57:17.229799 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 3 len 136 (DF) [tos 0x10] 14:57:18.059200 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 4 len 824 (DF) [tos 0x10] 14:57:18.059587 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 5 len 136 (DF) [tos 0x10] 14:57:18.266023 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 6 len 1192 (DF) [tos 0x10] 14:57:19.726565 37.160.239.206.20606 > 79.143.250.153.222: S 4201433516:4201433516(0) win 16384 (DF) 14:57:19.726641 79.143.250.153.222 > 37.160.239.206.20606: S 918752052:918752052(0) ack 4201433517 win 16384 (DF) 14:57:19.826467 37.160.239.206.20606 > 79.143.250.153.222: . ack 1 win 2048 (DF) 14:57:19.852144 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 7 len 104 (DF) 14:57:19.866853 37.160.239.206.20606 > 79.143.250.153.222: P 1:22(21) ack 1 win 8000 (DF) 14:57:20.066284 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 8 len 1048 (DF) 14:57:20.266288 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 9 len 1384 (DF) [tos 0x10] 14:57:20.868080 37.160.239.206.20606 > 79.143.250.153.222: P 1:22(21) ack 1 win 8000 (DF) 14:57:20.868190 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 10 len 88 (DF) 14:57:22.868423 37.160.239.206.20606 > 79.143.250.153.222: P 1:22(21) ack 1 win 8000 (DF) 14:57:22.868615 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 11 len 88 (DF) 14:57:24.266858 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 12 len 1384 [tos 0x10] 14:57:25.847062 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 13 len 1064 (DF) 14:57:26.869638 37.160.239.206.20606 > 79.143.250.153.222: P 1:22(21) ack 1 win 8000 (DF) 14:57:26.869732 79.143.250.153.4500 > 37.160.239.206.20603:udpencap: esp 79.143.250.153 > 37.160.239.206 spi 0xba588fdd seq 14 len 88
