Re: openiked + rc.conf.local

[Matt Behrens]

On Sep 26, 2016, at 2:26 PM, Infoomatic  wrote:

>> Do you get any more output if you do "rcctl -f -d start iked"?

> the output is:
> doing _rc_parse_conf
> doing _rc_quirks
> iked_flags empty, using default ><
> doing _rc_parse_conf /var/run/rc.d/iked
> doing _rc_quirks
> doing rc_check
> iked
> doing rc_pre
> configuration OK
>
> and then the terminal is blocked again

This looks similar to a problem I filed a bug on; see
https://marc.info/?l=openbsd-bugs=147463700507932=2


My workaround for now is to edit /etc/rc.d/iked and uncomment the `return 0`.
The line with `${daemon} -n ${daemon_flags}` has iked do a config test, which
appears to not exit cleanly.

Re: openiked + rc.conf.local

[Infoomatic]

> Do you get any more output if you do "rcctl -f -d start iked"?
the output is:
doing _rc_parse_conf
doing _rc_quirks
iked_flags empty, using default ><
doing _rc_parse_conf /var/run/rc.d/iked
doing _rc_quirks
doing rc_check
iked
doing rc_pre
configuration OK

and then the terminal is blocked again

> What happens if you press ^T to get status (assuming common
> shell setup)? Or if you don't get anything useful there, what
> is shown in the WAIT column in top for iked? ("top -g iked" if
> you have lots running and need to cut it down)
^T does not do anything (standard installation without further config),
top lists 4 processes, one running as root (parent) with "wait" and the other 
three processes (control, ca, ikev2) with "kqread" in the wait-column.

> It might be useful to include your config file (obviously masking
> anything sensitive, but try to avoid hiding anything that might be
> important..).
the exact configuration (does not matter if active or passive):
ikev2 "test" active esp \
from 10.85.0.0/24 to 10.86.0.0/24 \
local 10.85.0.2 peer 10.86.0.2 \
psk thisisjustatestpassword

sysctl is not touched except:
net.inet.ip.forwarding=1

Thanks in advance!

Re: openiked + rc.conf.local

[Stuart Henderson]

On 2016-09-26, Infoomatic  wrote:
>> On Mon, Sep 26, 2016 at 02:17:35PM +0200, Infoomatic wrote:
>> > also, the already running endpoint did not receive any packets.
>> 
>> Nobody on this list can run ifconfig, route, and tcpdump on *your* box
>> to figure out where you're losing packets...
>
> this is not a connectivity issue.
> To clarify: when I start the daemon manually as mentioned in my first mail, 
> everything is fine.
>
> However, when I try to start it automatically via rc.conf.local it just 
> interrupts the boot sequence and further daemons like ssh are not started, I 
> cannot even login on terminal locally. 
> The same happens when I try to do a "rcctl -f start iked" (I need -f since I 
> cannot use it with rc.conf.local because this leaves me with an unusable 
> system)- it hangs and "ctrl+c"/ SIGNAL 15 does not give me my terminal back, 
> I have to kill -9 the iked to use the terminal again where I tried to start 
> iked via rcctl. 
> When using iked_flags="-v", and doing "rcctl start iked" the same happens, 
> but opposite to my expection I did not get _any_ logs to /var/log/daemon.
>
> There really seems something wrong here ... this should not happen in any way.
>
>

Do you get any more output if you do "rcctl -f -d start iked"?

What happens if you press ^T to get status (assuming common
shell setup)? Or if you don't get anything useful there, what
is shown in the WAIT column in top for iked? ("top -g iked" if
you have lots running and need to cut it down)

It might be useful to include your config file (obviously masking
anything sensitive, but try to avoid hiding anything that might be
important..).

Re: openiked + rc.conf.local

[Infoomatic]

> On Mon, Sep 26, 2016 at 02:17:35PM +0200, Infoomatic wrote:
> > also, the already running endpoint did not receive any packets.
> 
> Nobody on this list can run ifconfig, route, and tcpdump on *your* box
> to figure out where you're losing packets...

this is not a connectivity issue.
To clarify: when I start the daemon manually as mentioned in my first mail, 
everything is fine.

However, when I try to start it automatically via rc.conf.local it just 
interrupts the boot sequence and further daemons like ssh are not started, I 
cannot even login on terminal locally. 
The same happens when I try to do a "rcctl -f start iked" (I need -f since I 
cannot use it with rc.conf.local because this leaves me with an unusable 
system)- it hangs and "ctrl+c"/ SIGNAL 15 does not give me my terminal back, I 
have to kill -9 the iked to use the terminal again where I tried to start iked 
via rcctl. 
When using iked_flags="-v", and doing "rcctl start iked" the same happens, but 
opposite to my expection I did not get _any_ logs to /var/log/daemon.

There really seems something wrong here ... this should not happen in any way.

Re: openiked + rc.conf.local

[Stefan Sperling]

On Mon, Sep 26, 2016 at 02:17:35PM +0200, Infoomatic wrote:
> also, the already running endpoint did not receive any packets.

Nobody on this list can run ifconfig, route, and tcpdump on *your* box
to figure out where you're losing packets...

Re: openiked + rc.conf.local

[Infoomatic]

> On Mon, Sep 26, 2016 at 01:56:20PM +0200, Infoomatic wrote:
> > ipsec=YES in rc.conf.local does not change anything, and appending
> > "ikelifetime 60" to iked.conf neither.
> 
> ipsec=YES and /etc/ipsec.conf are for use with isakmpd.
> 
> iked does not use ipsec.conf. 

that's what I thought, but wasn't quite sure so I just tried the
ipsec=YES in rc.conf.local

> It seems you came to this list before gathering actual evidence of
> what's going on. So I'd suggest you run tcpdump on your interfaces
> to figure out what's going on with the IKE session when it's in that
> non-working state, based on packets being passed around.
> You could also enable verbose mode at the other end and check the
> logs there to obtain more information.

I also tried with "-v" flags which did not write anything to
/var/log/daemon, also, the already running endpoint did not receive any
packets.

Re: openiked + rc.conf.local

[Stefan Sperling]

On Mon, Sep 26, 2016 at 01:56:20PM +0200, Infoomatic wrote:
> ipsec=YES in rc.conf.local does not change anything, and appending
> "ikelifetime 60" to iked.conf neither.

ipsec=YES and /etc/ipsec.conf are for use with isakmpd.

iked does not use ipsec.conf. 

> I am quite sure this is just a minor detail I have overseen, however,
> I would really appreciate your help! Thanks!

I don't see anything obviously wrong based on what you describe.
Perhaps someone else will.

It seems you came to this list before gathering actual evidence of
what's going on. So I'd suggest you run tcpdump on your interfaces
to figure out what's going on with the IKE session when it's in that
non-working state, based on packets being passed around.
You could also enable verbose mode at the other end and check the
logs there to obtain more information.