I've tried this on a few different systems now, one upgraded from 5.9 to 6.0 with the install CD, one a brand-new 6.0 install. The former is running as a hosted VM at Vultr, the latter a VMware Fusion machine.
I'm not sure if this is a problem just in a virtual machine context, but I don't have any physical hardware available to check it on at the moment. As such, I'm not confident I have a bug, and would appreciate comments from the community on whether they experience the same problem. The iked config test in /etc/rc.d/iked hangs fairly reliably. I've ktraced it and it looks like this when hanging, stopping at the wait4: 91211 iked CALL write(2,0x7b37a13ec73,0x11) 91211 iked GIO fd 2 wrote 17 bytes "configuration OK " 91211 iked RET write 17/0x11 91211 iked CALL kbind(0x7f7ffffce4f8,24,0x2e9d25833eef97c0) 91211 iked RET kbind 0 91211 iked CALL kill(-91211,SIGTERM) 91211 iked RET kill -1 errno 3 No such process 91211 iked CALL kill(-84806,SIGTERM) 91211 iked RET kill -1 errno 3 No such process 91211 iked CALL kill(-90967,SIGTERM) 91211 iked RET kill -1 errno 3 No such process 91211 iked CALL kill(-50484,SIGTERM) 91211 iked RET kill -1 errno 3 No such process 91211 iked CALL kbind(0x7f7ffffce4f8,24,0x2e9d25833eef97c0) 91211 iked RET kbind 0 91211 iked CALL wait4(WAIT_ANY,0,0<>,0) The kill pids are all valid pids (one is the process itself), and earlier in the ktrace output they were fork results: 91211 iked CALL fork() 91211 iked RET fork 90967/0x16357 91211 iked CALL fork() 91211 iked RET fork 84806/0x14b46 91211 iked CALL fork() 91211 iked RET fork 50484/0xc534 On the Vultr VM, if I run with -d (e.g. rcctl -df start iked), it starts fine. It seems like this is because iked -n is allowed to output "configuration OK" to the console. This doesn't work on the VMware Fusion machine. I can run iked -n just fine without any problem, though on the Vultr machine sometimes it prints exits for the privsep processes, and not predictably: # iked -n configuration OK ca exiting, pid 8933 # iked -n configuration OK ca exiting, pid 46440 # iked -n configuration OK ca exiting, pid 99924 # iked -n configuration OK ca exiting, pid 57315 ikev2 exiting, pid 38805 On the VMware machine, it always just prints "configuration OK". Commenting out the config test in /etc/rc.d/iked appears to be a viable workaround. To reproduce this on the brand-new VMware machine, I created a basic "road warrior" config similar to the one I run on the Vultr machine: # ikectl ca CA create ikectl.conf: user username passive ikev2 'configuration' passive esp \ from 0.0.0.0/0 to 10.0.0.0/24 local any peer any \ src vpn.local \ eap "mschap-v2" \ config address 10.0.0.1 \ config name-server 8.8.8.8