Hi Flavius, > I changed the log level enc to 3 and attached the strongswanlog. I also > attached a tcpdump from isakmpd which gives detailed information > about the proposals. (Isakmpd makes packet captures for debugging purposes).
Thanks. The encap mode attribute (type 4) in the first and only Quick Mode proposal looks like this: > Nov 9 22:31:45 ubuntu-vpn-gw charon: 11[ENC] parsing TRANSFORM_ATTRIBUTE_V1 > payload, 68 bytes left > Nov 9 22:31:45 ubuntu-vpn-gw charon: 11[ENC] parsing payload from => 68 > bytes @ 0x7f41c4000c0c > Nov 9 22:31:45 ubuntu-vpn-gw charon: 11[ENC] 0: 80 04 00 01 80 05 00 05 > 80 06 01 00 05 00 00 14 ................ > Nov 9 22:31:45 ubuntu-vpn-gw charon: 11[ENC] 16: 4E 5F EA 41 8A 0F 00 F1 > FF 39 9F C4 17 7E 44 F6 N_.A.....9...~D. > Nov 9 22:31:45 ubuntu-vpn-gw charon: 11[ENC] 32: 05 00 00 10 04 00 00 00 > C0 A8 DE 00 FF FF FF 00 ................ > Nov 9 22:31:45 ubuntu-vpn-gw charon: 11[ENC] 48: 00 00 00 10 04 00 00 00 > C0 A8 01 00 FF FF FF 00 ................ > Nov 9 22:31:45 ubuntu-vpn-gw charon: 11[ENC] 64: 00 00 00 00 > .... > Nov 9 22:31:45 ubuntu-vpn-gw charon: 11[ENC] parsing rule 0 > ATTRIBUTE_FORMAT > Nov 9 22:31:45 ubuntu-vpn-gw charon: 11[ENC] => 1 > Nov 9 22:31:45 ubuntu-vpn-gw charon: 11[ENC] parsing rule 1 ATTRIBUTE_TYPE > Nov 9 22:31:45 ubuntu-vpn-gw charon: 11[ENC] => 4 > Nov 9 22:31:45 ubuntu-vpn-gw charon: 11[ENC] parsing rule 2 > ATTRIBUTE_LENGTH_OR_VALUE > Nov 9 22:31:45 ubuntu-vpn-gw charon: 11[ENC] => 1 > Nov 9 22:31:45 ubuntu-vpn-gw charon: 11[ENC] parsing rule 3 ATTRIBUTE_VALUE > Nov 9 22:31:45 ubuntu-vpn-gw charon: 11[ENC] parsing TRANSFORM_ATTRIBUTE_V1 > payload finished That is, it's set to tunnel mode (1) and not tunnel mode with UDP encapsulation (3). This can also be seen in the tcpdump capture: > payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY > payload: PROPOSAL len: 40 proposal: 1 proto: IPSEC_ESP spisz: 4 > xforms: 1 SPI: 0xe79b6410 > payload: TRANSFORM len: 28 > transform: 1 ID: AES > attribute LIFE_TYPE = SECONDS > attribute LIFE_DURATION = 1200 > attribute ENCAPSULATION_MODE = TUNNEL > attribute AUTHENTICATION_ALGORITHM = HMAC_SHA2_256 > attribute KEY_LENGTH = 256 Since there is only one proposal in the SA payload this doesn't seem correct for an implementation claiming to support RFC 3947 > Nov 9 22:31:45 ubuntu-vpn-gw charon: 03[IKE] received NAT-T (RFC 3947) > vendor ID and wanting to use UDP encapsulation (which it apparently does use later). Refer to section 5.1 of RFC 3947 for details on the encap mode negotiation [1]). Anyway, this seems to be a known problem since 2011, see e.g. [2] for a patch and a link to the original report. > When I configure the tunnel in IKEv2 mode Openbsd sends no NAT-Keepalives to > the ubuntuserver and the session times out on the nat-gateway. Don't know why. > Proably also a proposal negotiation. No, in IKEv2 the encap mode is not negotiated. NAT-T is an integral part of the protocol. If both peers support it and a NAT is detected UDP encapsulation will be used and the hosts behind a NAT SHOULD send keepalives (see [3]). Maybe you can use DPD for this purpose (with a lot more overhead, though). Also see [4]. Regards, Tobias [1] https://tools.ietf.org/html/rfc3947#section-5.1 [2] http://openbsd-archive.7691.n7.nabble.com/isakmpd-nat-t-patch-td242348.html [3] https://tools.ietf.org/html/rfc7296#section-2.23 [4] http://openbsd-archive.7691.n7.nabble.com/OpenIKED-Keepalive-Broken-td301428.html
