After an upgrade to 6.7 on amd64 this weekend, iked keeps reconnecting every 8
minutes, but only for one tunnel, to a Watchguard firewall. The tunnel has been
functioning properly for 5 years. Other tunnels to OpenBSD devices do not
reconnect every 8 minutes. I confirmed there a no dropped packe
> > > Jun 8 12:23:24 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce:
> > > retransmit 1 INFORMATIONAL req 2
> > peer 192.0.2.199:500 local 192.0.2.2:500
> > > Jun 8 12:23:28 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce:
> > > retransmit 2 INFORMATIONAL req 2
> > peer 192.0.2.199:500 local
> Before 6.7 iked didn't start DPD in this particular case.
> It kicks in if the tunnel is up and there haven't been any incoming ESP
> packets
> in the last 5 minutes.
> A possible workaround would be to ping through the tunnel to have at least one
> incoming packet every 5 minutes.
There is def
> > > Before 6.7 iked didn't start DPD in this particular case.
> > > It kicks in if the tunnel is up and there haven't been any incoming ESP
> > > packets
> > > in the last 5 minutes.
> > > A possible workaround would be to ping through the tunnel to have at
> > > least one
> > > incoming packet
> I seems I got it wrong before. Even when there was ESP traffic, iked is going
> to start DPD when there hasn't been any incoming IKE message in the last
> 5 minutes.
>
> My advice would be to just disable DPD in iked for this specific case.
> To do this you will have to patch it and build it fr
Hello,
I have a vpn from a Windows machine to a network behind an OpenBSD router. It
was working fine until I upgraded the router to 6.9 (amd64).
The VPN is still coming up fine, but the traffic is blocked somehow. Using
tcpdump on the interface protected by the router (vlan0 in my case), I see
>It looks like 'keep state (if-bound)' iked.conf(5) is not present or being
>respected on the return traffic to the VPN device/firewall from your internal
>network. ICMP traffic is coming into the VPN device >encrypted, being
>decrypted and passed to the destination. The destination responds b
> I'm not sure about that bge0 rule. iked.conf(5) mentions ipencap only
> in the context of enc interfaces.
> You could try adding 'set skip on enc0' to find out if pf is the problem.
That rule has been the same for some years now, without problem. I tried
adding set skip on enc0, but the problem
> > > If that doesn't help you could share the output of 'ipsecctl -sa' to find
> > > out if the IPsec SAs or flows are the problem.
> >
> > That may be the problem, there is nothing between 192.168.1.109 and
> > 192.168.9.101 :
> > (192.168.8.2 is the firewall interface that 192.168.1.109 is con
> The SAs are ok but the flows are not loaded correctly. Looks like it is an
> actual bug in 6.9. It is triggered by the 'config address' line in your
> configuration, so working around that one line would be one solution.
I tried to assign a static IP address in the Windows VPN connection, but
I had a freeze on a machine with 5.9 amd64 yesterday, and upgraded the system
to 6.0 after that.
I still had the system freeze today, but I am unsure if it is something with
the hardware?
The message on the console during the freeze :
NMI ... going to debugger
Stopped atacpicpu_idle+0x22d:
Hi,
I have two firewalls in a carp failover setup, but the failover does not work
as expected...
The problem happens when I reboot the backup firewall (while in backup state).
Just after the reboot, I have these entries in dmesg :
carp0: state transition: BACKUP -> MASTER
carp1: state transition
Jan 30, 2015; 8:10am Stuart Henderson wrote :
>>/etc/hostname.carp0
>>advskew 0 carpdev em0 carppeer 192.168.3.10 pass secret1 state master
>>vhid 1 inet 192.0.2.2/28
>Maybe unrelated, but it's not usual to set "state master" like this.
I know, it was not in the config at first, I added it to te
> Rebooted fw2 at 3h02, fw1 kept master state, but had downtime until 3h12
> Rebooted fw1 at 3h15, got downtime until 4h10, fw1 got master state at 3h16,
> fw2 got backup state at the same time
>
Inspecting further my logs, I see that smtp services were functioning between
wan and dmz during th
if you can do a quick test on a different switch, that would at least
rule that out as your issue. if not, try disabling STP and retest
That was my guess, using a trunk to link the vlan to an edge switch not
affected by stp, and connecting the firewalls there.
This way, the 5300xl won't have to
> > Will try it during the weekend...
>
After reconnecting the firewalls differently, I got it fixed.
Logically, the connections are the same, but apparently the 5300xl had a hard
time with its arp table...
Instead of connecting both firewalls directly on the routing switch, I made a
trunk back
On 2015-02-03 04:16:04, Ted Unangst wrote:
> This is the kind of thing I usually put in a small script, and add to root's
> crontab. I don't think you need the nohup and sudo, that's probably just
> complicating things. e.g.
>
> #!/bin/sh
> tcpdump -n | logger 2> error.log &
>
> then
> @reboot /ro
Hi,
I have a problem with a rc script, when I try to check or stop the service.
It is very similar to the spamd rc script (with no rc_pre() and rc_start()):
$ grep -C2 pexp /etc/rc.d/{spamd,tarpitd}
/etc/rc.d/spamd-. /etc/rc.d/rc.subr
/etc/rc.d/spamd-
/etc/rc.d/spamd:pexp="spamd: \[priv\]"
/etc/
18 matches
Mail list logo
