Bug 221091 - security/ike: iked fails to run after FreeBSD 11.1 upgrade (socket set udp-encap non-ike option failed)
Summary: security/ike: iked fails to run after FreeBSD 11.1 upgrade (socket set udp-en...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2017-07-29 18:57 UTC by Darryn Nicol
Modified: 2018-12-06 16:47 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (mgrooms)
koobs: merge-quarterly?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Darryn Nicol 2017-07-29 18:57:26 UTC
I'm trying to build the security/ike port on FreeBSD 11.1. I'm building it with NATT and QTGUI enabled and not getting any errors during compilation. I can run qikea but not iked. Trying to run iked gives me the following error:

!! : socket set udp-encap non-ike option failed
daemon network configuration failed
 ( line 8, col 16 )

I know a lot changed in the ipsec implementation in 11.1. Has this broken the port?
Comment 1 Andrey V. Elsukov freebsd_committer 2017-07-29 20:58:17 UTC
I think you need to configure "socket natt" option. UDP_ENCAP_ESPINUDP_NON_IKE encapsulation type was removed. And I'm not sure why the daemon is trying to set this option in non NAT-T case. Also, you can patch ike/source/iked/ike.socket.cpp file and remove the entire block:

132         else
133         {
134                 optval = UDP_ENCAP_ESPINUDP_NON_IKE;
135                 if( setsockopt( sock_info->sock, SOL_UDP, UDP_ENCAP, &optval, sizeof( optval ) ) < 0)
136                 {
137                         log.txt( LLOG_ERROR, "!! : socket set udp-encap non-ike option failed\n" );
138                         return LIBIKE_SOCKET;
139                 }
140         }

I think this should be enough to make it working again.
Comment 2 Darryn Nicol 2017-08-01 00:12:33 UTC
(In reply to Andrey V. Elsukov from comment #1)
Thanks Andrey, after removing that code block and recompiling I'm able to start the daemon. I'm also able to establish a tunnel, but it doesn't seem to be transmitting any data. I will do some further testing.
Comment 3 Darryn Nicol 2017-08-03 10:56:21 UTC
When I establish a tunnel I'm picking up an IP address on the remote LAN via DHCP. I can confirm this by checking the assigned IP on my tap0 device. But any attempt to use a network resource over the tunnel times out. I've noticed that trying to display a route with 'route get <ip>', even to a local lan address, takes about 44 seconds while connected to the tunnel, but less than a second when the tunnel is not established.
Comment 4 Andrey V. Elsukov freebsd_committer 2017-08-03 11:02:41 UTC
(In reply to Darryn Nicol from comment #3)
> When I establish a tunnel I'm picking up an IP address on the remote LAN via
> DHCP. I can confirm this by checking the assigned IP on my tap0 device. But
> any attempt to use a network resource over the tunnel times out. I've
> noticed that trying to display a route with 'route get <ip>', even to a
> local lan address, takes about 44 seconds while connected to the tunnel, but
> less than a second when the tunnel is not established.

Use '-n' flag to avoid name resolution.
There are several things that can help with further debugging:
1. Look at the output of `netstat -rn`
2. Look at the output of `setkey -D` and `setkey -DP`
3. Use tcpdump on if_enc(4) interface to see what is going trough IPsec.
4. Check your firewall rules.
Comment 5 Darryn Nicol 2017-08-17 20:21:40 UTC
(In reply to Andrey V. Elsukov from comment #4)

if_enc doesn't appear to ever be configured. When connected to the VPN and trying tcpdump -i enc0 I get the following error:

tcpdump: enc0: No such device exists
(BIOCSETIF failed: Device not configured)

The only interface that seems to be related to the VPN is tap0, which is the interface that gets an IP on the remote network. I assume it is iked or qikea that is handling this as it isn't something I've set up manually.

(I've replaced the true IPs below with generic ones. 192.168.0.x represents my local LAN. 10.0.0.x represents the remote network I'm connecting to. x.x.x.x is the external IP of the network I'm connecting to. I'm on a laptop and wlan0 is the only interface connected to my LAN.)

% netstat -rn

Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            10.0.0.28        UGS        tap0
10.0.0.0/24      link#4             U          tap0
10.0.0.28        link#4             UHS         lo0
x.x.x.x/32   192.168.0.254      UGS       wlan0
127.0.0.1          link#2             UH          lo0
192.168.0.0/24     link#3             U         wlan0
192.168.0.162      link#3             UHS         lo0

% setkey -D

x.x.x.x[4500] 192.168.0.162[4500]
	esp-udp mode=tunnel spi=224509524(0x0d61be54) reqid=5(0x00000005)
	E: rijndael-cbc  fff59406 69560088 a683d1d4 9612386a 7c4c6b1c 7bda9658 6d18f009 f451c586
	A: hmac-sha1  5ad72b10 e5e2b0d6 9d80b90a cf49022b 38e432fd
	seq=0x00000000 replay=4 flags=0x00000000 state=mature 
	created: Aug 17 20:46:27 2017	current: Aug 17 21:12:13 2017
	diff: 1546(s)	hard: 28800(s)	soft: 23040(s)
	last:                     	hard: 0(s)	soft: 0(s)
	current: 0(bytes)	hard: 131072000(bytes)	soft: 104857600(bytes)
	allocated: 0	hard: 0	soft: 0
	sadb_seq=4 pid=1727 refcnt=1
x.x.x.x[4500] 192.168.0.162[4500]
	esp-udp mode=tunnel spi=244631220(0x0e94c6b4) reqid=3(0x00000003)
	E: rijndael-cbc  0e89c15a 6a7fc7aa d2e22e9a 64c021df d41c93a4 220d1d70 f9016cbf 627aca7c
	A: hmac-sha1  7e102220 f6254dd4 650c5633 8843a782 a0cb421d
	seq=0x00000000 replay=4 flags=0x00000000 state=mature 
	created: Aug 17 20:42:54 2017	current: Aug 17 21:12:13 2017
	diff: 1759(s)	hard: 28800(s)	soft: 23040(s)
	last:                     	hard: 0(s)	soft: 0(s)
	current: 0(bytes)	hard: 131072000(bytes)	soft: 104857600(bytes)
	allocated: 0	hard: 0	soft: 0
	sadb_seq=3 pid=1727 refcnt=1
x.x.x.x[4500] 192.168.0.162[4500]
	esp-udp mode=tunnel spi=118747594(0x0713f1ca) reqid=3(0x00000003)
	E: rijndael-cbc  7d2949ed 6cb9afdb 0c3c493d 41850191 aa117782 eacf2be9 28877d34 1d8c7b4b
	A: hmac-sha1  fc0ac30b fbd59aa0 a40da09e c9af2252 41f90467
	seq=0x00000000 replay=4 flags=0x00000000 state=mature 
	created: Aug 17 20:41:59 2017	current: Aug 17 21:12:13 2017
	diff: 1814(s)	hard: 28800(s)	soft: 23040(s)
	last:                     	hard: 0(s)	soft: 0(s)
	current: 0(bytes)	hard: 131072000(bytes)	soft: 104857600(bytes)
	allocated: 0	hard: 0	soft: 0
	sadb_seq=2 pid=1727 refcnt=1
x.x.x.x[4500] 192.168.0.162[4500]
	esp-udp mode=tunnel spi=16425421(0x00faa1cd) reqid=3(0x00000003)
	E: rijndael-cbc  66243414 6e559e44 a6545e2f 303e2bd4 74dc67f8 f40f9f97 6346493e b986d50a
	A: hmac-sha1  6ee0d23f 8a1f7aae 33254fdb ee74a1b9 1c929dbd
	seq=0x00000000 replay=4 flags=0x00000000 state=mature 
	created: Aug 17 20:39:44 2017	current: Aug 17 21:12:13 2017
	diff: 1949(s)	hard: 28800(s)	soft: 23040(s)
	last:                     	hard: 0(s)	soft: 0(s)
	current: 0(bytes)	hard: 131072000(bytes)	soft: 104857600(bytes)
	allocated: 0	hard: 0	soft: 0
	sadb_seq=1 pid=1727 refcnt=1
x.x.x.x[4500] 192.168.0.162[4500]
	esp-udp mode=tunnel spi=187208468(0x0b289314) reqid=1(0x00000001)
	E: rijndael-cbc  b083703e 29f137c1 0b4163f2 88e12d15 9a1f6412 11022d61 b2894d21 884509a2
	A: hmac-sha1  bfb27e00 ce35a45b fb5fce7c 84999447 7ec168a0
	seq=0x00000000 replay=4 flags=0x00000000 state=mature 
	created: Aug 17 20:38:46 2017	current: Aug 17 21:12:13 2017
	diff: 2007(s)	hard: 28800(s)	soft: 23040(s)
	last:                     	hard: 0(s)	soft: 0(s)
	current: 0(bytes)	hard: 131072000(bytes)	soft: 104857600(bytes)
	allocated: 0	hard: 0	soft: 0
	sadb_seq=0 pid=1727 refcnt=1

% setkey -DP

x.x.x.x[any] 192.168.0.162[any] any
	in none
	spid=25 seq=3 pid=1734 scope=global 
	refcnt=1
0.0.0.0/0[any] 10.0.0.28[any] any
	in ipsec
	esp/tunnel/x.x.x.x-192.168.0.162/unique:3
	spid=27 seq=2 pid=1734 scope=global 
	refcnt=1
192.168.0.162[any] x.x.x.x[any] any
	out none
	spid=26 seq=1 pid=1734 scope=global 
	refcnt=1
10.0.0.28[any] 0.0.0.0/0[any] any
	out ipsec
	esp/tunnel/192.168.0.162-x.x.x.x/unique:4
	spid=28 seq=0 pid=1734 scope=global 
	refcnt=1
Comment 6 Darryn Nicol 2017-08-17 20:27:22 UTC
I should also mention that I've turned off the firewall while testing, and verified that the VPN works with the Windows version of the Shrewsoft VPN client using a Windows 7 VM on this laptop.
Comment 7 w.schwarzenfeld freebsd_triage 2018-03-05 17:58:31 UTC
Status?
Comment 8 Darryn Nicol 2018-12-06 16:47:06 UTC
While the port does compile I've been unable to get it to function with NAT-T enabled on any version of FreeBSD 11.x. I've resorted to using it in a Bhyve VM running 10.4.

I don't have the resources to test a VPN without NAT-T so I don't know if the basic functionality is working, but for my use case this appears to be broken.