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?
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.
(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.
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.
(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.
(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
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.
Status?
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.
Hope it's OK for me to close this. I no longer need the software and it seems no one else is affected.