Hi,
On Thu, Aug 02, 2007 at 09:23:59PM +0200, Sven Ulland wrote:
> I am running OpenBSD 4.0 on amd64, and I'm seeing that isakmpd builds
> up a large amount of redundant phase 1 tunnels for one of our peers.
> It will only report these when prompted with 'echo r > \
> isakmpd.fifo', it's not shown in 'ipsecctl -s all'. This is causing
> one of our peer VPN endpoints to run out of available tunnel resources
> and drop packets. I am running two OpenBSD 4.0 VPN boxes in a
> redundant setup with carp and sasyncd.
>
> isakmpd in OpenBSD 4.0 is by default started with the -S flag, that
> the manual says "will not delete SAs on shutdown by sending delete
> messages to all peers", suitable for carp/sasyncd setups. What it
> doesn't say, however, is that it also enables ui_daemon_passive.
> According to isakmpd(8) in CURRENT: "In passive mode no packets are
> sent to peers." Active/passive mode is not documented in 4.0 manpages,
> but the functionality is there.
In a sasyncd/carp setup isamkpd is started in a passive mode using -S. On
the machine that is carp master, sasyncd triggers isakmpd to start
negotiations. On the backup machine, isamkpd stays in passive mode an
does nothing.
However, this should be done by the controling sasyncd only. This
commands are not meant to be used by the user. Therefore I guess we
decided to not document this in the man pgae...
> I was having recurrent problems with tunnels not being established.
> Our isakmpd just sat there, not wanting to establish tunnels where our
> end is set to be active in isakmpd.conf. It mostly ignored incoming
> tunnel requests from peers (connection entries configured as passive
> in isakmpd.conf) as well.
Is this after a fresh reboot or after restart sasync/isakmpd by hand?
> Upon looking at the source, it was clear that 'echo M active > \
> isakmpd.fifo' disables ui_daemon_passive (i.e. makes it active). This
> is also mentioned in CURRENT's isakmpd(8). Enabling this caused all
> our tunnels to suddenly establish and there was much rejoicing.
>
> Now after a while, I saw that isakmpd might have become a little bit
> *too* active. I should only be having one phase 1 tunnel to each peer,
> but there has been set up around 470 (varies; I've seen 960 at worst)
> phase 1 tunnels to one peer in particular. I can't remember anything
> other than that it runs Cisco. I can dig up more info if it helps.
>
> The following is gathered from /var/log/daemon after doing an 'echo \
> r > isakmpd.fifo'. Excerpt:
>
> sa_report: 0x47b4d800 TMUK phase 1 doi 1 flags 0xb
> sa_report: icookie 1fe44ce55975a07f rcookie 876ef79120c13acc
> sa_report: msgid 00000000 refcnt 3
> sa_report: life secs 28800 kb 0
> sa_report: suite 1 proto 1
> sa_report: spi_sz[0] 0 spi[0] 0x0 spi_sz[1] 0 spi[1] 0x0
> sa_report: initiator id: 81f0402: 129.240.64.2, \
> responder id: d562735: 213.98.7.53, \
> src: 129.240.64.2 dst: 213.98.7.53
>
> There are 470 of these right now. They all have different 0x........
> identifiers and different {i,r}cookie. Other than that, they are
> identical.
>
> They are also listed in the {udp_encap,transport}_report. Example:
>
> transport_report: transport 0x45a30200 flags 0 refcnt 1
> udp_report: fd 9 src 129.240.64.2:500 dst 213.98.7.53:500
>
> Except for the 0x........ ID, they are identical. refcnt is always 1,
> and fd is 9 on all of them.
>
> Now, this leads to two questions:
> 1) Is there something strange or wrong with the active/passive setting
> on 4.0? I mean, since isakmpd is started default in passive mode and
> -S and 'echo M {active,passive} > isakmpd.fifo' is not documented in
> the man pages. -S is, but it doesn't mention active/passive mode
> directly.
M {active, passive} is meant to be issued by sasyncd only.
> 2) What could cause the massive phase 1 build-up I'm seeing? I'll be
> starting the debug process now, and I'll post back if I can find
> anything relevant.
could you please try to upgrade to 4.1-stable? If I remember correctly,
there were some issues with 4.0.
Thanks,
HJ.
