[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-misc
Subject:    Re: OpenBSD 6.2: how to tear down partial ipsec tunnels without restarting ipsec/isakmpd?
From:       Andre Ruppert <aru () in-telegence ! net>
Date:       2018-05-30 10:24:25
Message-ID: 143f93d3-0359-e35b-b669-a481c466cea5 () in-telegence ! net
[Download RAW message or body]


Hello Philipp,
hello @misc

I thought the problems were gone, but often deleting an unmamed phase 1 
SA didn't work with the "cookie method" at least with 6.3/amd64.

My way:

1.)
# sh -c "echo S > /var/run/isakmpd.fifo"
# less /var/run/isakmpd.result

--> identify the dead phase 1 SA

SA name: <unnamed> (Phase 1/Responder)
src: <here> dst: <there>
Lifetime: 28800 seconds
Flags 0x00000000
icookie 7e0aab1278867246 rcookie f26398203e60007f

2.)
try to delete the unnamed SA with your method:

# sh -c "echo 'd 7e0aab1278867246f26398203e60007f -' \
         > /var/run/isakmpd.fifo"

results mostly in:
ui_delete: command "d 7e0aab1278867246f26398203e60007f -" found no SA

3.)
collateral problem:
I'm not able to accept a new connection by the remote peer (with a new 
cookie) because isakmpd logs:

transport_send_messages: giving up on exchange peer-<there>, no response 
from peer <there>.

With tcpdump I can see that isakmpd refuses to answer peer <there> 
requests 'till lifetime end or the crippled phase 1 is totally dropped...

Resarting isakmpd is not advised 'cause of a lot of other active vpn 
sessions.

The question: isakmpd bug or may brain incapabillities?

Best regards
Andre


Am 15.05.18 um 05:15 schrieb Philipp Buehler:
> Hello Andre,
> 
> Am 14.05.2018 13:38 schrieb Andre Ruppert:
>> I got the tips from this 2013 undeadly.org article:
>> Managing Individual IPsec Tunnels On A Multi-Tunnel Gateway
>> https://undeadly.org/cgi?action=article&sid=20131125041429
> 
> Apparently I wrote that article, and I feel your pain :-)
> 
>> 2.) less /var/run/isakmpd.result
>> ...
>> SA name: <unnamed> (Phase 1/Responder)
>> src: <my_gateway_ip> dst: <peering_gateway_ip>
>> Flags 0x00000000
>> icookie 9f5bf7497f0ebe10 rcookie 8a6c7b1b1f5923ec
>> ...
>>
>>
>> Feeding the fifo with
>> sh -c "echo 't <SA-name-of-connection>' > /var/run/isakmpd.fifo"
>> only deletes phase 2.
>>
>> But I didn't have an SA name at this time... ??
> 
> The problem here is you only have an 'unnamed' SA, indeed; but
> you have cookies..
> What you can do - found that a bit later after the undeadly article:
> echo 'd 9f5bf7497f0ebe108a6c7b1b1f5923ec -' > isakmpd.fifo
> which is "d $icookie$rcookie -" (no space between the cookie values).
> 
> If I am changing a peer configuration, I also block 500/udp for the
> time being to avoid these 'Responder' SAs altogether. Think along
> pf.conf:pass in proto udp from <vpn_peers> to $myself port 500
> pfctl -T delete -t vpn_peers $thatpeer
> pfctl -k $thatpeer
> ipsecctl -d -f $thatpeer.conf
> vi $thatpeer.conf
> ipsecctl -f $thatpeer.conf
> pfctl -T add -t vpn_peers $thatpeer
> 
> HTH,


["smime.p7s" (application/pkcs7-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]