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
