Hi! I tried to complie strongswan with "kernel-libipsec" plugin fro the same reason....
https://wiki.strongswan.org/projects/strongswan/wiki/Kernel-libipsec The *kernel-libipsec* plugin provides an IPsec backend that works entirely in userland, using TUN devices My experience is that there is some work to be done to use, but my C fu isnt strong enough to finish..... I made a simple patch, for the tun handling: --- src/libstrongswan/networking/tun_device.c.orig Fri Feb 23 10:10:34 2018 +++ src/libstrongswan/networking/tun_device.c Fri Feb 23 10:43:38 2018 @@ -62,6 +62,10 @@ #include <net/if_tun.h> #include <net/if_var.h> #include <netinet/in_var.h> +#elif __OpenBSD__ +#include <net/if_tun.h> +#include <net/if_var.h> +#include <netinet/in_var.h> #else #include <net/if_tun.h> #endif @@ -338,6 +342,12 @@ uint32_t proto = htonl(AF_INET); packet = chunk_cata("cc", chunk_from_thing(proto), packet); #endif +#ifdef __OpenBSD__ + /* OpenBSD tun expect the packets to be prepended by a 32-bit protocol number + * instead of parsing the packet again, we assume IPv4 for now */ + uint32_t proto = htonl(AF_INET); + packet = chunk_cata("cc", chunk_from_thing(proto), packet); +#endif s = write(this->tunfd, packet.ptr, packet.len); if (s < 0) { @@ -374,6 +384,10 @@ #ifdef __APPLE__ /* UTUN's prepend packets with a 32-bit protocol number */ data = chunk_skip(data, sizeof(uint32_t)); +#endif +#ifdef __OpenBSD__ + /* OpenBSD tun prepend packets with a 32-bit protocol number */ + data = chunk_skip(data, sizeof(uint32_t)); #endif *packet = chunk_clone(data); return TRUE; I compile Strongswan 5.6.2 with the following options: CC=clang ./configure --disable-kernel-netlink --enable-kernel-pfroute --enable-kernel-libipsec --disable-scripts --enable-eap-mschapv2 --enable-md4 --enable-eap-tls --enable-eap-ttls --enable-eap-peap --enable-eap-radius --enable-eap-identity --enable-aesni --enable-gcm make make install openbsdvm1# ipsec start Starting strongSwan 5.6.2 IPsec [starter]... no netkey IPsec stack detected no KLIPS IPsec stack detected no known IPsec stack detected, ignoring! I"m using EAP-MSCHAPv2 client config with virtual IP address request , and the IKE part is working out of the box: conn vpn.csszep.net left=192.168.56.11 leftsourceip=%config leftauth=eap eap_identity=carol right=vpn.csszep.net rightauth=pubkey #rightid=@vpn.csszep.net rightid="C=HU O=Strongswan CN=vpn.csszep.net" rightsubnet=192.0.2.0/24 auto=add openbsdvm1# ipsec up vpn.csszep.net initiating IKE_SA vpn.csszep.net[1] to 192.168.56.16 generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ] sending packet: from 192.168.56.11[500] to 192.168.56.16[500] (748 bytes) received packet: from 192.168.56.16[500] to 192.168.56.11[500] (38 bytes) parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ] peer didn't accept DH group CURVE_25519, it requested MODP_3072 initiating IKE_SA vpn.csszep.net[1] to 192.168.56.16 generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ] sending packet: from 192.168.56.11[500] to 192.168.56.16[500] (1100 bytes) received packet: from 192.168.56.16[500] to 192.168.56.11[500] (592 bytes) parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ] faking NAT situation to enforce UDP encapsulation sending cert request for "C=HU O=Strongswan CN=Strongswan CA" establishing CHILD_SA vpn.csszep.net{1} generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ IDr CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ] sending packet: from 192.168.56.11[4500] to 192.168.56.16[4500] (384 bytes) received packet: from 192.168.56.16[4500] to 192.168.56.11[4500] (1184 bytes) parsed IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ] received end entity cert "C=HU O=Strongswan CN=vpn.csszep.net" using certificate "C=HU O=Strongswan CN=vpn.csszep.net" using trusted ca certificate "C=HU O=Strongswan CN=Strongswan CA" checking certificate status of "C=HU O=Strongswan CN=vpn.csszep.net" certificate status is not available reached self-signed root ca with a path length of 0 authentication of 'C=HU O=Strongswan CN=vpn.csszep.net' with RSA_EMSA_PKCS1_SHA2_256 successful server requested EAP_IDENTITY (id 0x00), sending 'carol' generating IKE_AUTH request 2 [ EAP/RES/ID ] sending packet: from 192.168.56.11[4500] to 192.168.56.16[4500] (80 bytes) received packet: from 192.168.56.16[4500] to 192.168.56.11[4500] (112 bytes) parsed IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ] server requested EAP_MSCHAPV2 authentication (id 0x42) generating IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ] sending packet: from 192.168.56.11[4500] to 192.168.56.16[4500] (144 bytes) received packet: from 192.168.56.16[4500] to 192.168.56.11[4500] (144 bytes) parsed IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ] EAP-MS-CHAPv2 succeeded: 'Welcome2strongSwan' generating IKE_AUTH request 4 [ EAP/RES/MSCHAPV2 ] sending packet: from 192.168.56.11[4500] to 192.168.56.16[4500] (80 bytes) received packet: from 192.168.56.16[4500] to 192.168.56.11[4500] (80 bytes) parsed IKE_AUTH response 4 [ EAP/SUCC ] EAP method EAP_MSCHAPV2 succeeded, MSK established authentication of '192.168.56.11' (myself) with EAP generating IKE_AUTH request 5 [ AUTH ] sending packet: from 192.168.56.11[4500] to 192.168.56.16[4500] (112 bytes) received packet: from 192.168.56.16[4500] to 192.168.56.11[4500] (288 bytes) parsed IKE_AUTH response 5 [ AUTH CPRP(ADDR) SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_6_ADDR) ] authentication of 'C=HU O=Strongswan CN=vpn.csszep.net' with EAP successful IKE_SA vpn.csszep.net[1] established between 192.168.56.11[192.168.56.11]...192.168.56.16[C=HU O=Strongswan CN= vpn.csszep.net] scheduling reauthentication in 3306s maximum IKE_SA lifetime 3486s installing new virtual IP 100.64.0.1 created TUN device: tun1 CHILD_SA vpn.csszep.net{1} established with SPIs dfb653d8_i c4694ca1_o and TS 100.64.0.1/32 === 192.0.2.0/24 received AUTH_LIFETIME of 3305s, scheduling reauthentication in 3125s connection 'vpn.csszep.net' established successfully vpn.csszep.net{2}: 100.64.0.1/32 === 192.0.2.0/24 openbsdvm1# ipsec statusall Status of IKE charon daemon (strongSwan 5.6.2, OpenBSD 6.2, amd64): uptime: 2 minutes, since Feb 23 11:10:00 2018 worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 0/0/0/0, scheduled: 5 loaded plugins: charon aesni aes des rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp curve25519 xcbc cmac hmac gcm attr kernel-libipsec kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-mschapv2 eap-radius eap-tls eap-ttls eap-peap xauth-generic counters Listening IP addresses: 10.0.2.7 192.168.56.11 100.64.0.1 Connections: vpn.csszep.net: 192.168.56.11...vpn.csszep.net IKEv2 vpn.csszep.net: local: [192.168.56.11] uses EAP authentication with EAP identity 'carol' vpn.csszep.net: remote: [C=HU O=Strongswan CN=vpn.csszep.net] uses public key authentication vpn.csszep.net: child: dynamic === 192.0.2.0/24 TUNNEL Security Associations (1 up, 0 connecting): vpn.csszep.net[1]: ESTABLISHED 33 seconds ago, 192.168.56.11[192.168.56.11]...192.168.56.16[C=HU O=Strongswan CN= vpn.csszep.net] vpn.csszep.net[1]: IKEv2 SPIs: 40308e6851944359_i* 1b483d60e9c79442_r, EAP reauthentication in 51 minutes vpn.csszep.net[1]: IKE proposal: AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072 vpn.csszep.net{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: dfb653d8_i c4694ca1_o vpn.csszep.net{1}: AES_CBC_128/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 13 minutes vpn.csszep.net{1}: 100.64.0.1/32 === 192.0.2.0/24 Strongswan brings up the tun device with the proper IP address: openbsdvm1# ifconfig tun1 tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 index 13 priority 0 llprio 3 groups: tun status: active inet 100.64.0.1 --> 0.0.0.0 netmask 0xffffffff But Strongswan installs the 192.0.2.0/24 route to the worng interface. But its easy to correct.. openbsdvm1# route -n show | grep 192.0.2 192.0.2/24 192.168.56.16 US 0 0 - 8 em1 openbsdvm1# route del 192.0.2.0/24 del net 192.0.2.0/24 openbsdvm1# route add 192.0.2.0/24 100.64.0.1 add net 192.0.2.0/24: gateway 100.64.0.1 Now comes the wrong part... If i ping 192.0.2.1 packet leaves the box, and the answer is coming back, but Strongswan somehow not inject back the cleartext packet to the tun interface. openbsdvm1# tcpdump -vpni em1 not port 22 tcpdump: listening on em1, link-type EN10MB 11:19:37.366124 192.168.56.11.4500 > 192.168.56.16.4500: udpencap: esp 192.168.56.11 > 192.168.56.16 spi 0xc4694ca1 seq 4 len 136 (ttl 64, id 39109, len 164) 11:19:37.366384 192.168.56.16.4500 > 192.168.56.11.4500: [no udp cksum] udpencap: esp 192.168.56.16 > 192.168.56.11 spi 0xdfb653d8 seq 4 len 136 (ttl 64, id 8729, len 164) 11:19:38.371977 192.168.56.11.4500 > 192.168.56.16.4500: udpencap: esp 192.168.56.11 > 192.168.56.16 spi 0xc4694ca1 seq 5 len 136 (ttl 64, id 17022, len 164) 11:19:38.372571 192.168.56.16.4500 > 192.168.56.11.4500: [no udp cksum] udpencap: esp 192.168.56.16 > 192.168.56.11 spi 0xdfb653d8 seq 5 len 136 (ttl 64, id 8940, len 164) 11:19:39.360772 192.168.56.11.4500 > 192.168.56.16.4500: udpencap: esp 192.168.56.11 > 192.168.56.16 spi 0xc4694ca1 seq 6 len 136 (ttl 64, id 20110, len 164) 11:19:39.361398 192.168.56.16.4500 > 192.168.56.11.4500: [no udp cksum] udpencap: esp 192.168.56.16 > 192.168.56.11 spi 0xdfb653d8 seq 6 len 136 (ttl 64, id 8959, len 164) openbsdvm1# tcpdump -vpni tun1 tcpdump: listening on tun1, link-type LOOP 11:18:23.270727 100.64.0.1 > 192.0.2.1: icmp: echo request (id:d966 seq:0) [icmp cksum ok] (ttl 255, id 53428, len 84) 11:18:24.279648 100.64.0.1 > 192.0.2.1: icmp: echo request (id:d966 seq:1) [icmp cksum ok] (ttl 255, id 4228, len 84) 11:18:25.270434 100.64.0.1 > 192.0.2.1: icmp: echo request (id:d966 seq:2) [icmp cksum ok] (ttl 255, id 46403, len 84) openbsdvm1# /usr/local/libexec/ipsec/stroke loglevel any 4 openbsdvm1# tail -f /var/log/daemon | grep charon Feb 23 11:25:57 openbsdvm1 charon: 05[ESP] ESP packet: Feb 23 11:25:57 openbsdvm1 charon: 05[ESP] SPI c4694ca1 [seq 384] Feb 23 11:25:57 openbsdvm1 charon: 05[ESP] IV => 16 bytes @ 0x00000811d9ce4208 Feb 23 11:25:57 openbsdvm1 charon: 05[ESP] 0: D4 02 D1 2F CF BB A8 88 99 DD 4C 24 BE 64 6A 64 .../......L$.djd Feb 23 11:25:57 openbsdvm1 charon: 05[ESP] encrypted => 96 bytes @ 0x00000811d9ce4218 Feb 23 11:25:57 openbsdvm1 charon: 05[ESP] 0: 05 78 18 91 2A E1 12 88 33 B3 2B 6C 94 E8 90 01 .x..*...3.+l.... Feb 23 11:25:57 openbsdvm1 charon: 05[ESP] 16: EC 9B 0E 44 94 48 C2 D4 95 8C 0B 8D 0B 61 CA 4B ...D.H.......a.K Feb 23 11:25:57 openbsdvm1 charon: 05[ESP] 32: BE 0E 16 09 6C EB C5 CC B9 01 E3 45 85 C1 D0 13 ....l......E.... Feb 23 11:25:57 openbsdvm1 charon: 05[ESP] 48: 61 4C 5E AA F6 65 42 1B 0E 67 21 ED DB 96 03 87 aL^..eB..g!..... Feb 23 11:25:57 openbsdvm1 charon: 05[ESP] 64: 39 29 1A 0A 52 8E D8 EB 75 F8 D6 1C 83 00 29 0F 9)..R...u.....). Feb 23 11:25:57 openbsdvm1 charon: 05[ESP] 80: 93 06 49 05 34 F1 DF 08 2A 05 CB 39 48 70 3E D9 ..I.4...*..9Hp>. Feb 23 11:25:57 openbsdvm1 charon: 05[ESP] ICV => 16 bytes @ 0x00000811d9ce4278 Feb 23 11:25:57 openbsdvm1 charon: 05[ESP] 0: 75 77 36 C9 3F 2D 35 6F 57 50 A2 58 1F FC 53 5A uw6.?-5oWP.X..SZ Feb 23 11:25:57 openbsdvm1 charon: 02[NET] sending packet: from 192.168.56.11[4500] to 192.168.56.16[4500] Feb 23 11:25:58 openbsdvm1 charon: 05[ESP] ESP before encryption: Feb 23 11:25:58 openbsdvm1 charon: 05[ESP] payload = => 84 bytes @ 0x00000810fd997380 Feb 23 11:25:58 openbsdvm1 charon: 05[ESP] 0: 45 00 00 54 CF B9 00 00 FF 01 C5 AC 64 40 00 01 E..T........d@.. Feb 23 11:25:58 openbsdvm1 charon: 05[ESP] 16: C0 00 02 01 08 00 F1 6D 0A B2 01 7D 2A 4B 07 39 .......m...}*K.9 Feb 23 11:25:58 openbsdvm1 charon: 05[ESP] 32: E3 76 80 73 54 C7 CF D2 E5 F2 19 3A B3 28 07 F2 .v.sT......:.(.. Feb 23 11:25:58 openbsdvm1 charon: 05[ESP] 48: C0 DA 52 B5 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 ..R......... !"# Feb 23 11:25:58 openbsdvm1 charon: 05[ESP] 64: 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 $%&'()*+,-./0123 Feb 23 11:25:58 openbsdvm1 charon: 05[ESP] 80: 34 35 36 37 4567 Feb 23 11:25:58 openbsdvm1 charon: 05[ESP] padding = => 10 bytes @ 0x000008113230b16c Feb 23 11:25:58 openbsdvm1 charon: 05[ESP] 0: 01 02 03 04 05 06 07 08 09 0A .......... Feb 23 11:25:58 openbsdvm1 charon: 05[ESP] padding length = 10, next header = 4 I'm here now.... Thx csszep 2018-02-22 12:50 GMT+01:00 Stuart Henderson <s...@spacehopper.org>: > On 2018/02/22 09:51, Joel Carnat wrote: > > Hi, > > > > Le 22/02/2018 09:35, Stuart Henderson a écrit : > > > On 2018-02-22, Igor V. Gubenko <i...@gubenko.com> wrote: > > > > I am far from an expert; having issues myself at the moment, but > maybe > > > > if we get all of the iked experimenters together, we can figure it > out > > > > :) > > > > > > This definitely isn't going to work, iked only supports > > > username/password > > > authentication as a responder. not initiator. > > > > Is there any software that enables openbsd to be an ipsec initiator using > > user/pass ? > > Not for IKEv2. OpenBSD iked as client supports psk but not EAP for > user/password. afaik no other implementations have been ported. > > By far the simplest way which doesn't rely on psk, if the other side > supports it, is to use iked with public keys (without using x509 pki) > - just copy local.pub from one side to the appropriate subdirectory of > pubkeys/ on the other. > > It *may* be possible for IKEv1 with xauth using vpnc, but it's old > all-userland software, not using the standard OpenBSD IPsec stack, the > port (and probably upstream software) are not really maintained. > No modern crypto. > >
