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

Reply via email to