Hi!
So the OpenBSD kernel catch udp encapsulated ESP packets by default:
netstat -s
esp:
4288 input ESP packets
0 output ESP packets
0 packets from unsupported protocol families
0 packets shorter than header shows
0 packets dropped due to policy
4281 packets for which no TDB was found
I disabled it, and Strongswan works!
openbsdvm1# sysctl net.inet.esp.enable=0
net.inet.esp.enable: 1 -> 0
openbsdvm1# sysctl net.inet.esp.udpencap=0
net.inet.esp.udpencap: 1 -> 0
Thx
Csszep
2018-02-23 10:29 GMT+01:00 csszep <css...@gmail.com>:
> 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.
>>
>>
>
