iked keeps reconnecting every 8 minutes
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 packets by pf. Here is part of the log (anonymized) : Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: ikev2_init_ike_sa: initiating "TUNNELNAME" Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: send IKE_SA_INIT req 0 peer 192.0.2.199:500 local 192.0.2.2:500, 334 bytes Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: recv IKE_SA_INIT res 0 peer 192.0.2.199:500 local 192.0.2.2:500, 296 bytes, policy 'TUNNELNAME' Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: send IKE_AUTH req 1 peer 192.0.2.199:500 local 192.0.2.2:500, 252 bytes Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: recv IKE_AUTH res 1 peer 192.0.2.199:500 local 192.0.2.2:500, 204 bytes, policy 'TUNNELNAME' Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: ikev2_childsa_enable: loaded SPIs: 0x4cd06a6a, 0xa749d359 Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: ikev2_childsa_enable: loaded flows: ESP-10.0.1.0/24=10.0.100.0/24(0), ESP-10.0.1.0/24=10.0.150.0/24(0), ESP-192.0.2.2/32=192.0.2.199/32(0) Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: established peer 192.0.2.199:500[IPV4/192.0.2.199] local 192.0.2.2:500[IPV4/192.0.2.2] policy 'TUNNELNAME' as initiator Jun 8 12:15:24 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: retransmit 1 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 Jun 8 12:15:28 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: retransmit 2 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 Jun 8 12:15:36 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: retransmit 3 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 Jun 8 12:15:52 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: retransmit 4 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 Jun 8 12:16:24 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: retransmit 5 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 Jun 8 12:17:28 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: sa_free: retransmit limit reached Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: ikev2_init_ike_sa: initiating "TUNNELNAME" Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: send IKE_SA_INIT req 0 peer 192.0.2.199:500 local 192.0.2.2:500, 334 bytes Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: recv IKE_SA_INIT res 0 peer 192.0.2.199:500 local 192.0.2.2:500, 296 bytes, policy 'TUNNELNAME' Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: send IKE_AUTH req 1 peer 192.0.2.199:500 local 192.0.2.2:500, 252 bytes Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: recv IKE_AUTH res 1 peer 192.0.2.199:500 local 192.0.2.2:500, 204 bytes, policy 'TUNNELNAME' Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: ikev2_childsa_enable: loaded SPIs: 0x4cd06a6b, 0xf20c662c Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: ikev2_childsa_enable: loaded flows: ESP-10.0.1.0/24=10.0.100.0/24(0), ESP-10.0.1.0/24=10.0.150.0/24(0), ESP-192.0.2.2/32=192.0.2.199/32(0) Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: established peer 192.0.2.199:500[IPV4/192.0.2.199] local 192.0.2.2:500[IPV4/192.0.2.2] policy 'TUNNELNAME' as initiator 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 192.0.2.2:500 Jun 8 12:23:37 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: retransmit 3 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 Jun 8 12:23:53 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: retransmit 4 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 Jun 8 12:24:25 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: retransmit 5 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 Jun 8 12:25:29 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: sa_free: retransmit limit reached And here is the configuration of the tunnel : ikev2 "TUNNELNAME" active esp \ from 10.0.1.0/24 to 10.0.100.0/24 \ from 10.0.1.0/24 to 10.0.150.0/24 \ from 192.0.2.2/32 to 192.0.2.199/32 \ local 192.0.2.2 peer 192.0.2.199 \ ikesa auth hmac-sha1 enc aes-128 group grp5 \ childsa auth hmac-sha1 enc aes-128 group grp5 \ srcid 192.0.2.2 dstid 192.0.2.199 \ ikelifetime 28800 \ psk THISISTHEPSK Other tunnels have basically the same configuration, only omitting ikesa, childsa and ikelifetime parameters. I don't have control over the Watchgua
Re: iked keeps reconnecting every 8 minutes
> > > 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 192.0.2.2:500 > > > Jun 8 12:23:37 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: > > > retransmit 3 INFORMATIONAL req 2 > > peer 192.0.2.199:500 local 192.0.2.2:500 > > > Jun 8 12:23:53 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: > > > retransmit 4 INFORMATIONAL req 2 > > peer 192.0.2.199:500 local 192.0.2.2:500 > > > Jun 8 12:24:25 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: > > > retransmit 5 INFORMATIONAL req 2 > > peer 192.0.2.199:500 local 192.0.2.2:500 > > > Jun 8 12:25:29 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: > > > sa_free: retransmit limit > reached > > > > Those INFORMATIONAL messages are the dead peer detection. It looks like the > > Watchguard > > firwall ignores them, which causes the reconnect after a retransmit timeout > > (as intended). > > > > Can you see the outgoing INFORMATIONAL pings in tcpdump? > > Is there a tcpdump filter I can use to see this? If I filter only by the > other endpoint IP, I see > all the encrypted packets, without any way to know which ones are the > INFORMATIONAL packets... I found it, INFORMATIONAL packets are sent on the external interface : # tcpdump -nnttti bge0 host 192.0.2.199 and udp port 500 tcpdump: listening on bge0, link-type EN10MB Jun 09 08:56:38.482789 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange INFORMATIONAL cookie: 46a71107f0a9486e->bccb051ab894a056 msgid: 0002 len: 76 Jun 09 08:58:36.363323 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange IKE_SA_INIT cookie: 844a443d5f49aaa5-> msgid: len: 334 Jun 09 08:58:36.399046 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange IKE_SA_INIT cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: len: 296 Jun 09 08:58:36.409161 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange IKE_AUTH cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0001 len: 252 Jun 09 08:58:36.442159 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange INFORMATIONAL cookie: 9225af3bb74cf5a1->b18ab2b3e82cdcdd msgid: len: 76 Jun 09 08:58:36.442161 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange IKE_AUTH cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0001 len: 204 Jun 09 09:03:36.498344 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange INFORMATIONAL cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0002 len: 76 Jun 09 09:03:38.507692 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange INFORMATIONAL cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0002 len: 76 Jun 09 09:03:42.517680 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange INFORMATIONAL cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0002 len: 76 Jun 09 09:03:50.527778 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange INFORMATIONAL cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0002 len: 76 Jun 09 09:04:06.537979 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange INFORMATIONAL cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0002 len: 76 Jun 09 09:04:38.548773 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange INFORMATIONAL cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 0002 len: 76 Jun 09 09:06:36.448688 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange IKE_SA_INIT cookie: 883961cb08ca064c-> msgid: len: 334 Jun 09 09:06:36.487738 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange IKE_SA_INIT cookie: 883961cb08ca064c->4485c3c2a69d42d1 msgid: len: 296 Jun 09 09:06:36.497831 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange IKE_AUTH cookie: 883961cb08ca064c->4485c3c2a69d42d1 msgid: 0001 len: 252 Jun 09 09:06:36.533002 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange INFORMATIONAL cookie: bbdef3192a7832fc->8b3cbbe39d3ae970 msgid: len: 76 Jun 09 09:06:36.533004 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange IKE_AUTH cookie: 883961cb08ca064c->4485c3c2a69d42d1 msgid: 0001 len: 204 Is there anything that may have changed between 6.6 and 6.7 concerning those packets, that may cause the Watchguard to not accept them?
Re: iked keeps reconnecting every 8 minutes
> 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 definitely ESP packets continuously, as there are 3-8 RDP sessions in this tunnel during workhours. That's why it's a problem, people get their RDP session disconnected every 8 minutes.
Re: iked keeps reconnecting every 8 minutes
> > > 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 definitely ESP packets continuously, as there are 3-8 RDP sessions > > in this tunnel during workhours. That's why it's a problem, people get their > > RDP session disconnected every 8 minutes. > > > > If true that would certainly be a bug. > Could you try running iked with -dvv and look for ikev2_ike_sa_alive messages? > It should look like this: > > ikev2_ike_sa_alive: incoming CHILD SA spi 0x last used 0 second(s) ago spi=0x09ce404cdca4ee1d: ikev2_childsa_enable: loaded SPIs: 0x4cd06b6d, 0x0e7dbe7d spi=0x09ce404cdca4ee1d: ikev2_childsa_enable: loaded flows: ESP-192.168.1.0/24=192.168.100.0/24(0), ESP-192.168.1.0/24=192.168.150.0/24(0), ESP-192.0.2.2/32=192.0.2.199/32(0) spi=0x09ce404cdca4ee1d: sa_state: VALID -> ESTABLISHED from 192.0.2.199:500 to 192.0.2.2:500 policy 'POLICYNAME' spi=0x09ce404cdca4ee1d: established peer 192.0.2.199:500[IPV4/192.0.2.199] local 192.0.2.2:500[IPV4/192.0.2.2] policy 'POLICYNAME' as initiator ... ikev2_ike_sa_alive: incoming CHILD SA spi 0x0e7dbe7d last used 1 second(s) ago I don't see the ikev2_ike_sa_alive message for the other SPI (0x4cd06b6d), is it normal? And then it doesn't reply back : ikev2_ike_sa_alive: IKE SA 0xed2d646c000 ispi 0x09ce404cdca4ee1d rspi 0x714a5bb2f7ccc4d4 last received 300 second(s) ago ikev2_ike_sa_alive: sending alive check ikev2_msg_encrypt: decrypted length 4 ikev2_msg_encrypt: padded length 16 ikev2_msg_encrypt: length 5, padding 11, output length 44 ikev2_next_payload: length 48 nextpayload NONE ikev2_msg_integr: message length 76 ikev2_msg_integr: integrity checksum length 12 ikev2_pld_parse: header ispi 0x09ce404cdca4ee1d rspi 0x714a5bb2f7ccc4d4 nextpayload SK version 0x20 exchange INFORMATIONAL flags 0x08 msgid 2 length 76 response 0 ikev2_pld_payloads: payload SK nextpayload NONE critical 0x00 length 48 ikev2_msg_decrypt: IV length 16 ikev2_msg_decrypt: encrypted payload length 16 ikev2_msg_decrypt: integrity checksum length 12 ikev2_msg_decrypt: integrity check succeeded ikev2_msg_decrypt: decrypted payload length 16/16 padding 11 spi=0x09ce404cdca4ee1d: send INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500, 76 bytes ... spi=0x09ce404cdca4ee1d: retransmit 1 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 ... spi=0x09ce404cdca4ee1d: retransmit 2 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 spi=0x09ce404cdca4ee1d: retransmit 3 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 spi=0x09ce404cdca4ee1d: retransmit 4 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 ... ikev2_ike_sa_alive: IKE SA 0xed2d646c000 ispi 0x09ce404cdca4ee1d rspi 0x714a5bb2f7ccc4d4 last received 360 second(s) ago ... spi=0x09ce404cdca4ee1d: retransmit 5 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 ... ikev2_ike_sa_alive: IKE SA 0xed2d646c000 ispi 0x09ce404cdca4ee1d rspi 0x714a5bb2f7ccc4d4 last received 420 second(s) ago ... ikev2_msg_retransmit_timeout: retransmit limit reached for req 2 spi=0x09ce404cdca4ee1d: sa_free: retransmit limit reached config_free_proposals: free 0xed2a4156f80 config_free_proposals: free 0xed2a4156180 config_free_childsas: free 0xed2c6179700 config_free_childsas: free 0xed275c07400 config_free_childsas: free 0xed33fcbba00 config_free_childsas: free 0xed2c6177200 sa_free_flows: free 0xed247848800 sa_free_flows: free 0xed2b3308800 sa_free_flows: free 0xed2e78cfc00 sa_free_flows: free 0xed247849800 sa_free_flows: free 0xed2e78cf000 sa_free_flows: free 0xed247848c00 > "ipsecctl -sa -v" shows you SA packet counters, if you find one that has > 0 input packets that's probably the cause. All SAs have packet counters > 0, see those for this tunnel : esp tunnel from 192.0.2.2 to 192.0.2.199 spi 0x4cd06b6a auth hmac-sha1 enc aes sa: spi 0x4cd06b6a auth hmac-sha1 enc aes state mature replay 64 flags 0x4 lifetime_cur: alloc 0 bytes 501965 add 1591730080 first 1591730081 lifetime_hard: alloc 0 bytes 536870912 add 10800 first 0 lifetime_soft: alloc 0 bytes 497679335 add 10011 first 0 address_src: 192.0.2.2 address_dst: 192.0.2.199 identity_src: type prefix id 0: IPV4/192.0.2.2 identity_dst: type prefix id 0: IPV4/192.0.2.199 lifetime_lastuse: alloc 0 bytes 0 add 0 first 1591730260 counter: 1557 output packets 601368 output bytes 533105 output bytes, uncompressed esp tunnel from 192.0.2.199 to 192.0.2.2 spi 0xa2f3ce44 auth hmac-sha1 enc aes sa: spi 0xa2f3ce44 auth hmac-sha1 enc aes state mature replay 64 flags 0x4 lifetime_cur: alloc 0 bytes 30801
Re: iked keeps reconnecting every 8 minutes
> 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 from the sources.
> Below is a diff that should do the trick.
>
> Index: ikev2.c
> ===
> RCS file: /cvs/src/sbin/iked/ikev2.c,v
> retrieving revision 1.231
> diff -u -p -r1.231 ikev2.c
> --- ikev2.c 9 Jun 2020 21:53:26 - 1.231
> +++ ikev2.c 10 Jun 2020 11:02:39 -
> @@ -4391,7 +4391,7 @@ ikev2_ike_sa_alive(struct iked *env, voi
>* SA, or if we haven't received an IKE message. but only if we
>* are not already waiting for an answer.
>*/
> - if (((!foundin && foundout) || ikeidle) &&
> + if ((!foundin && foundout) &&
> (sa->sa_stateflags & (IKED_REQ_CHILDSA|IKED_REQ_INF)) == 0) {
> log_debug("%s: sending alive check", __func__);
> ikev2_send_ike_e(env, sa, NULL, IKEV2_PAYLOAD_NONE,
Thank you very much, the patch did the trick. No reconnection since yesterday.
As it is in production, this system is following syspatches only. If there
ever is a syspatch on iked for another problem, I assume I would have to
reapply this patch, right?
after upgrade to 6.9, iked does not pass traffic
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 the ping requests from the remote vpn address, and the ping replies, but on enc0 I only see the requests. I confirmed that pf is not blocking packets. My setup : Remote Windows machine : fixed IP address 192.168.1.109 OpenBSD router : bge0 192.168.8.2 vlan0 192.168.9.2 also arp -s 192.168.9.208 12:34:56:ab:cd:ef permanent pub iked.conf : set nomobike ikev2 "windows" passive esp \ from 192.168.8.2 to 192.168.1.109 \ from 192.168.9.0/24 to 192.168.9.208 \ local 192.168.8.2 peer 192.168.1.109 \ srcid 192.168.8.2 \ rsa \ config address 192.168.9.208 \ config netmask 255.255.255.0 \ config name-server 192.168.1.222 \ config netbios-server 192.168.1.222 netstat -rn -inet (removing unrelated interfaces) : NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls Time lo0 327680 00 0 0 0 lo0 32768 ::1/128 ::1 0 00 0 0 0 lo0 32768 fe80::%lo0/ fe80::1%lo0 0 00 0 0 0 lo0 32768 127/8 127.0.0.10 00 0 0 0 bge0150012:34:56:ab:cd:ef 167154089 0 36267061 0 00 bge01500 192.168.8/2 192.168.8.2 167154089 0 36267061 0 00 enc0* 0 140 00 0 0 0 vlan0 150012:34:56:ab:cd:ef 126698124 0 360 0 00 vlan0 1500 192.168.9/2 192.168.9.2 126698124 0 360 0 00 pflog0 331360 0 1642609 0 0 0 Log extract : May 27 08:10:20 mymachine iked[14895]: spi=0x41f8d1c369853156: recv IKE_SA_INIT req 0 peer 192.168.1.109:500 local 192.168.8.2:500, 528 bytes, policy 'windows' May 27 08:10:20 mymachine iked[14895]: spi=0x41f8d1c369853156: send IKE_SA_INIT res 0 peer 192.168.1.109:500 local 192.168.8.2:500, 278 bytes May 27 08:10:20 mymachine iked[14895]: spi=0x41f8d1c369853156: recv IKE_AUTH req 1 peer 192.168.1.109:500 local 192.168.8.2:500, 7440 bytes, policy 'windows' May 27 08:10:20 mymachine iked[14895]: spi=0x41f8d1c369853156: send IKE_AUTH res 1 peer 192.168.1.109:500 local 192.168.8.2:500, 1600 bytes May 27 08:10:20 mymachine iked[14895]: spi=0x41f8d1c369853156: ikev2_childsa_enable: loaded SPIs: 0x6487e520, 0x36d4127b (enc aes-256 auth hmac-sha1) May 27 08:10:20 mymachine iked[14895]: spi=0x41f8d1c369853156: established peer 192.168.1.109:500[ASN1_DN//C=CA/ST=Quebec/L=Somewhere/O=Org/OU=Department/CN=192.168.1.109/emailAddress=xyz@domain.local] local 192.168.8.2:500[IPV4/192.168.8.2] policy 'windows' as responder (enc aes-256 auth hmac-sha2-256 group modp1024 prf hmac-sha2-256) doas tcpdump -nni enc0 tcpdump: listening on enc0, link-type ENC 08:48:05.289341 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) 08:48:09.914843 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) 08:48:14.914988 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) 08:48:19.915348 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) ^C 4 packets received by filter 0 packets dropped by kernel tcpdump -nni vlan0 host 192.168.9.208 tcpdump: listening on vlan0, link-type EN10MB 09:12:21.467671 192.168.9.208 > 192.168.9.101: icmp: echo request 09:12:21.468371 arp who-has 192.168.9.208 tell 192.168.9.101 09:12:21.468386 arp reply 192.168.9.208 is-at ec:eb:b8:5d:94:a0 09:12:21.468937 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:21.468961 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:26.410587 192.168.9.208 > 192.168.9.101: icmp: echo request 09:12:26.411144 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:26.411168 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:31.414257 192.168.9.208 > 192.168.9.101: icmp: echo request 09:12:31.415117 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:31.415141 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:36.409094 192.168.9.208 > 192.168.9.101: icmp: echo request 09:12:36.409680 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:36.409705 192.168.9.101 > 192.168.9.208: icmp: echo reply ^C 3134 packets received by filter 0 packets dropped by kernel Thanks! Sebastien Leclerc
Re: after upgrade to 6.9, iked does not pass traffic
>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 back but >the VPN device is not taking those responses and pushing them back through >enc0. Thank you for your response Jason. Here is the relevant pf.conf configuration, keep state (if-bound) is there, so I don't think it's the cause of the problem : pass inet proto udp from 192.168.1.109 to bge0 port 500 pass inet proto esp from 192.168.1.109 to bge0 pass on bge0 proto ipencap keep state (if-bound) pass inet from 192.168.9.208 to vlan0:network
Re: after upgrade to 6.9, iked does not pass traffic
> 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 persists. > 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 connecting to, 192.168.9.101 is what the vpn client is trying to communicate with) # ipsecctl -sa FLOWS: No flows SAD: esp tunnel from 192.168.8.2 to 192.168.1.109 spi 0x0e7b0e8b auth hmac-sha1 enc aes-256 esp tunnel from 192.168.1.109 to 192.168.8.2 spi 0x6830eab4 auth hmac-sha1 enc aes-256
Re: after upgrade to 6.9, iked does not pass traffic
> > > 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 connecting to, > > 192.168.9.101 is what the vpn client is trying to communicate with) > > > > # ipsecctl -sa > > FLOWS: > > No flows > > > > SAD: > > esp tunnel from 192.168.8.2 to 192.168.1.109 spi 0x0e7b0e8b auth hmac-sha1 > > enc aes-256 > > esp tunnel from 192.168.1.109 to 192.168.8.2 spi 0x6830eab4 auth hmac-sha1 > > enc aes-256 > Ok, so this seems to be the cause. From your log snippet i can see that > there must have been SAs at some point because it shows an > "ikev2_childsa_enable" line. > Try running iked with -vv. Maybe the verbose log contains an error message > that helps us find out what's wrong. The SAs seem to be only the first "from" clause (from 192.168.8.2 to 192.168.1.109), which are the VPN endpoints, not the second one, which covers the network behind the OpenBSD machine, and the IP assigned to the Windows machine in this same subnet (arp-proxied). Here is the verbose log : # iked -Tdvv create_ike: using rsa for peer 192.168.1.109 ikev2 "windows" passive tunnel esp inet from 192.168.8.2 to 192.168.1.109 from 192.168.9.0/24 to 192.168.9.208 local 192.168.8.2 peer 192.168.1.109 ikesa enc aes-128-gcm enc aes-256-gcm prf hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn childsa enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid 192.168.8.2 lifetime 10800 bytes 536870912 rsa config address 192.168.9.208 config netmask 255.255.255.0 config name-server 192.168.1.222 config netbios-server 192.168.1.222 /etc/iked.conf: loaded 1 configuration rules ca_privkey_serialize: type RSA_KEY length 1191 ca_pubkey_serialize: type RSA_KEY length 270 ca_privkey_to_method: type RSA_KEY method RSA_SIG ca_getkey: received private key type RSA_KEY length 1191 config_getpolicy: received policy ca_getkey: received public key type RSA_KEY length 270 ca_dispatch_parent: config reset config_getpfkey: received pfkey fd 3 config_getcompile: compilation done config_getsocket: received socket fd 4 config_getsocket: received socket fd 5 config_getstatic: dpd_check_interval 60 config_getstatic: no enforcesingleikesa config_getstatic: no fragmentation config_getstatic: no mobike config_getstatic: nattport 4500 config_getstatic: no stickyaddress ca_reload: loaded ca file ca.crt ca_reload: loaded crl file ca.crl ca_reload: /C=CA/ST=State/L=City-Name/O=Ville de City-Name/OU=Department/CN=VPN CA/emailAddress=it@domain.local ca_reload: loaded 1 ca certificate ca_reload: loaded cert file 192.168.8.2.crt ca_validate_cert: /C=CA/ST=State/L=City-Name/O=Ville de City-Name/OU=Department/CN=192.168.8.2/emailAddress=it@domain.local ok ca_reload: local cert type X509_CERT config_getocsp: ocsp_url none tolerate 0 maxage -1 ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20 ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20 policy_lookup: setting policy 'windows' spi=0xd5f403b2c665646e: recv IKE_SA_INIT req 0 peer 192.168.1.109:500 local 192.168.8.2:500, 528 bytes, policy 'windows' ikev2_recv: ispi 0xd5f403b2c665646e rspi 0x ikev2_policy2id: srcid IPV4/192.168.8.2 length 8 ikev2_pld_parse: header ispi 0xd5f403b2c665646e rspi 0x nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 528 response 0 ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 256 ikev2_pld_sa: more 2 reserved 0 length 40 proposal #1 protoid IKE spisize 0 xforms 4 spi 0 ikev2_pld_xform: more 3 reserved 0 length 8 type ENCR id 3DES ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA1 ikev2_pld_xform: more 0 reserved 0 length 8 type DH id MODP_1024 ikev2_pld_sa: more 2 reserved 0 length 44 proposal #2 protoid IKE spisize 0 xforms 4 spi 0 ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4 ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96 ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA1 ikev2_pld_xform: more 0 reserved 0 length 8 type DH id MODP_1024 i
Re: after upgrade to 6.9, iked does not pass traffic
> 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 it didn't work. > The diff below should also fix your problem and allow you to keep your config > unchanged. The diff fixed the problem, thank you very much!
System freeze in 5.9 and 6.0
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: nop
ddb{0}>
Anyone got this before?
Thank you
Sébastien Leclerc
dmesg:
OpenBSD 6.0 (GENERIC.MP) #0: Fri Sep 2 13:18:00 CEST 2016
r...@stable-60-amd64.mtier.org:/binpatchng/work-binpatch60-amd64/src/sys/
arch/amd64/compile/GENERIC.MP
real mem = 4267814912 (4070MB)
avail mem = 4133994496 (3942MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe7180 (49 entries)
bios0: vendor American Megatrends Inc. version "1.0b" date 11/06/2013
bios0: Supermicro A1SAi
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP FPDT MCFG WDAT UEFI APIC BDAT HPET SSDT HEST BERT ERST
EINJ
acpi0: wakeup devices PEX1(S0) PEX2(S0) PEX3(S0) EHC1(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C2558 @ 2.40GHz, 2400.46 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,
NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU C2558 @ 2.40GHz, 2399.99 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,
NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Atom(TM) CPU C2558 @ 2.40GHz, 2399.99 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,
NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu2: 1MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Atom(TM) CPU C2558 @ 2.40GHz, 2399.99 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,
NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu3: 1MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEX1)
acpiprt2 at acpi0: bus 2 (BR04)
acpiprt3 at acpi0: bus 3 (PEX2)
acpiprt4 at acpi0: bus 4 (PEX3)
acpicpu0 at acpi0: C2(350@41 mwait.3@0x51), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(350@41 mwait.3@0x51), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(350@41 mwait.3@0x51), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C2(350@41 mwait.3@0x51), C1(1000@1 mwait.1), PSS
"PNP0003" at acpi0 not configured
"PNP0C33" at acpi0 not configured
cpu0: Enhanced SpeedStep 2400 MHz: speeds: 2400, 2300, 2200, 2100, 2000, 1900,
1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Atom C2000 Host" rev 0x02
ppb0 at pci0 dev 1 function 0 "Intel Atom C2000 PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "ASPEED Technology AST1150 PCI" rev 0x03
pci2 at ppb1 bus 2
vga1 at pci2 dev 0 function 0 "ASPEED Technology AST2000" rev 0x30
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb2 at pci0 dev 2 function 0 "Intel Atom C2000 PCIE" rev 0x02: msi
pci3 at ppb2 bus 3
xhci0 at pci3 dev 0 function 0 "Renesas uPD720201 xHCI" rev 0x03: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 "Renesas xHCI root hub" rev 3.00/1.00 addr 1
ppb3 at pci0 dev 3 function 0 "Intel Atom C2000 PCIE" rev 0x02: msi
pci4 at ppb3 bus 4
vendor "Intel", unknown product 0x1f18 (class processor subclass Co-processor,
rev 0x02) at pci0 dev 11 function 0 not configured
pchb1 at pci0 dev 14 function 0 "Intel Atom C2000 RAS" rev 0x02
"Intel Atom C2000 RCEC" rev 0x02 at pci0 dev 15 function 0 not configured
"Intel Atom C2000 SMBus" rev 0x02 at pci0 dev 19 function 0 not configured
e
carp failover problem
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: BACKUP -> MASTER
carp0: state transition: MASTER -> BACKUP
carp1: state transition: MASTER -> BACKUP
Why would there be no mention of carp2?
And no corresponding entries on the master?
States are consistent (all backup on backup, and all master on master), but
forwarded connections hang, until I force back the master with this :
sudo ifconfig -g carp carpdemote 128
sudo ifconfig -g carp -carpdemote 128
Between these two commands, on the backup firewall, I see traffic coming from
WAN and DMZ, but almost nothing from LAN, so it may be related to the LAN
switch. I cannot see what the problem is though...
Here is the setup :
On both firewalls :
- em0 is connected to WAN
- em1 is connected to LAN
- em2 is connected to DMZ
- em3 is interconnected with a crossover cable, used for pfsync and rdist
WAN and DMZ connections are on the same switch, but on different untagged VLANs
(Procurve 2524)
LAN is on a separate layer 3 switch (Procurve 5300xl)
Another strange behavior :
With tcpdump, on the backup, I can see this traffic :
- on em1 and em2, I see only carp advertisements to the configured unicast IP
address and physical MAC address
- on em3, I see only pfsync packets
- but on em0, I see carp advertisements, but also a lot of traffic from the
ISP router's MAC, to the virtual MAC (00:00:5e:00:01:01)
Which situation is normal? (em0 with lots of packets, or em1/em2 with only carp
advertisements)
The only difference I see :
- on em0, both firewalls and the ISP router are connected to the switch
- on em1, both firewalls are connected to the L3 switch, which is also the
router
- on em2, there is no router, the firewalls communicate directly with hosts
connected on the switch
Common configuration (public addresses anonymized, but the network sizes are
correct) :
/etc/mygate
192.0.2.1
/etc/sysctl.conf
net.inet.carp.preempt=1
net.inet.ip.forwarding=1
/etc/pf.conf (excerpt only)
ext_if = "em0"
ext_if_carp = "carp0"
int_if = "em1"
int_if_carp = "carp1"
dmz_if = "em2"
dmz_if_carp = "carp2"
sync_if = "em3"
set skip on lo
set skip on $sync_if
pass quick on { $int_if, $ext_if, $dmz_if } inet proto carp keep state (no-sync)
Firewall A (expected to be always master) :
OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar 5 09:37:46 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
/etc/hostname.em0
inet 192.168.3.9/30
/etc/hostname.em1
inet 192.168.3.1/29
!route add 192.168.0.0/16 192.168.3.5
!route add 172.16.0.0/12 192.168.3.5
/etc/hostname.em2
inet 192.168.3.13/30
/etc/hostname.em3
inet 192.168.3.17 255.255.255.252
/etc/hostname.carp0
advskew 0 carpdev em0 carppeer 192.168.3.10 pass secret1 state master vhid 1
inet 192.0.2.2/28
alias 192.0.2.3/32
alias 192.0.2.4/32
alias 192.0.2.5/32
/etc/hostname.carp1
advskew 0 carpdev em1 carppeer 192.168.3.4 pass secret2 state master vhid 2
inet 192.168.3.6/32
/etc/hostname.carp2
advskew 0 carpdev em2 carppeer 192.168.3.14 pass secret3 state master vhid 3
inet 192.0.2.17/28
alias 192.0.2.29/32
/etc/hostname.pfsync0
up
syncdev em3
syncpeer 192.168.3.18
Firewall B (expected to be always backup) :
OpenBSD 5.6 (GENERIC.MP) #5: Thu Dec 11 09:51:08 CET 2014
r...@stable-56-amd64.mtier.org:/binpatchng/work-binpatch56-amd64/src/sys/arch/amd64/compile/GENERIC.MP
/etc/hostname.em0
inet 192.168.3.10/30
/etc/hostname.em1
inet 192.168.3.4/29
!route add 192.168.0.0/16 192.168.3.5
!route add 172.16.0.0/12 192.168.3.5
/etc/hostname.em2
inet 192.168.3.14/30
/etc/hostname.em3
inet 192.168.3.18/30
/etc/hostname.carp0
advskew 200 carpdev em0 carppeer 192.168.3.9 pass secret1 state backup vhid 1
inet 192.0.2.2/28
alias 192.0.2.3/32
alias 192.0.2.4/32
alias 192.0.2.5/32
/etc/hostname.carp1
advskew 200 carpdev em1 carppeer 192.168.3.1 pass secret2 state backup vhid 2
inet 192.168.3.6/32
/etc/hostname.carp2
advskew 200 carpdev em2 carppeer 192.168.3.13 pass secret3 state backup vhid 3
inet 192.0.2.17/28
alias 192.0.2.29/32
/etc/hostname.pfsync0
up
syncdev em3
syncpeer 192.168.3.17
This message is already long, but if any other information would be helpful, I
would be glad to provide it.
Any help or suggestion is appreciated.
Thank you!
Sebastien
Re: carp failover problem
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 test. >Also "inet" should normally be at the start of a line in hostname.if. Fails miserably if I do it :( Only aliases get assigned to the interface, and a message indicates that the address cannot be assigned to the interface (I don't have the exact message, I rebooted after the failure, and it's not in the logs...) My config was like this : inet 192.0.2.2/28 advskew 0 carpdev em0 pass secret1 state master vhid 1 alias 192.0.2.3/32 I also tried with this, with the same result : inet 192.0.2.2/28 advskew 0 carpdev em0 pass secret1 state master vhid 1 alias 192.0.2.3/32 >Do things work if you use the default multicast, rather than carppeer? As you can see above, I removed the carppeer from the config. I had to add back the addresses manually to the carp interfaces, but then I got worst results : fw1 was master on all carp interfaces, but fw2 was backup on carp0 and carp2, and master on carp1 So I reverted to my previous configuration. I changed some pf rules yesterday (removed antispoof) and disabled sasyncd, and rebooted during the night. At least in the morning, everything was ok, but inspecting our monitoring system, here is what I found : 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 Thanks for your help >This mail was missing a few things. dmesg and ifconfig -A output would >be useful for starters (then we don't have to wonder how netstart parsed >your files). Fw1 : lo0: flags=8049 mtu 33144 priority: 0 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet 127.0.0.1 netmask 0xff00 em0: flags=8b43 mtu 1500 lladdr 00:25:90:f2:6e:9a priority: 0 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.3.9 netmask 0xfffc broadcast 192.168.3.11 inet6 fe80::225:90ff:fef2:6e9a%em0 prefixlen 64 scopeid 0x1 em1: flags=8b43 mtu 1500 lladdr 00:25:90:f2:6e:9b priority: 0 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.3.1 netmask 0xfff8 broadcast 192.168.3.7 inet6 fe80::225:90ff:fef2:6e9b%em1 prefixlen 64 scopeid 0x2 em2: flags=8b43 mtu 1500 lladdr 00:25:90:f2:6e:9c priority: 0 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.3.13 netmask 0xfffc broadcast 192.168.3.15 inet6 fe80::225:90ff:fef2:6e9c%em2 prefixlen 64 scopeid 0x3 em3: flags=8843 mtu 1500 lladdr 00:25:90:f2:6e:9d priority: 0 media: Ethernet autoselect (1000baseT full-duplex,master,rxpause,txpause) status: active inet 192.168.3.17 netmask 0xfffc broadcast 192.168.3.19 inet6 fe80::225:90ff:fef2:6e9d%em3 prefixlen 64 scopeid 0x4 enc0: flags=41 priority: 0 groups: enc status: active tun0: flags=8051 mtu 1500 priority: 0 groups: tun status: active inet 10.233.0.1 --> 10.233.0.2 netmask 0x pfsync0: flags=41 mtu 1500 priority: 0 pfsync: syncdev: em3 syncpeer: 192.168.3.18 maxupd: 128 defer: off groups: carp pfsync pflog0: flags=141 mtu 33144 priority: 0 groups: pflog carp0: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:01 priority: 0 carp: MASTER carpdev em0 vhid 1 advbase 1 advskew 0 carppeer 192.168.3.10 groups: carp egress status: master inet6 fe80::200:5eff:fe00:101%carp0 prefixlen 64 scopeid 0x7 inet 192.0.2.2 netmask 0xfff0 broadcast 192.0.2.15 inet 192.0.2.3 netmask 0x inet 192.0.2.4 netmask 0x inet 192.0.2.5 netmask 0x carp1: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:02 priority: 0 carp: MASTER carpdev em1 vhid 2 advbase 1 advskew 0 carppeer 192.168.3.4 groups: carp status: master inet6 fe80::200:5eff:fe00:102%carp1 prefixlen 64 scopeid 0x8 inet 192.168.3.6 netmask 0x carp2: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:03 priority: 0 carp: MASTER carpdev em2 vhid 3 advbase 1 advskew 0 carppeer 192.168.3.14 groups: carp status: master inet6 fe80::200:5eff:fe00:103%carp2 prefixlen 64 scopeid 0x9 inet 192.0.2.17 netmask 0xfff0 broadcast 192.0.2.31 inet 192.0.2.29 netmask 0x And Fw2 : lo0: flags=8049 mtu 32768 priority: 0 groups: lo inet6 ::1 prefixlen 128 inet6 fe80:
Re: carp failover problem
> 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 the downtime period. Our monitoring is done from the lan, so I suspect the 5300xl is causing the problem... Any thoughts? Thanks Sebastien
Re: carp failover problem
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 detect which port is connected to the gateway (the 5300xl is a routing switch for the lan) Will try it during the weekend... Sebastien
Re: carp failover problem
> > 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 to the 2524, and connected the firewalls there. Within seconds after disconnecting a port or rebooting either firewall, carp now handles the failover smoothly! Thanks! Sebastien
Re: sudo nohup tcpdump at startup
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 /root/tcpdump.sh Works for me! Sebastien
rc script problem with pgrep / pkill
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/rc.d/spamd-rc_reload=NO
/etc/rc.d/spamd-
--
/etc/rc.d/tarpitd-. /etc/rc.d/rc.subr
/etc/rc.d/tarpitd-
/etc/rc.d/tarpitd:pexp="tarpitd: \[priv\]"
/etc/rc.d/tarpitd-
/etc/rc.d/tarpitd-rc_reload=NO
The start parameter works correctly:
$ sudo /etc/rc.d/tarpitd -d start
doing rc_read_runfile
doing rc_check
tarpitd
doing rc_start
doing rc_write_runfile
(ok)
$ ps aux | grep "tarpitd:"
_tarpitd 22014 0.0 0.1 7176 3964 ?? Ss10:18AM0:00.46 tarpitd:
[priv] (tarpitd)
root 775 0.0 0.0 472 660 p1 I 10:18AM0:00.00 tarpitd:
(blocker) (tarpitd)
seblec6474 0.0 0.0 448 268 p1 R+/1 11:01AM0:00.00 grep tarpitd:
If I try a manual pgrep, with the same syntax as in rc.subr, it works as
expected:
$ pgrep -f "^tarpitd: \[priv\]"
22014
But a check or stop doesn't:
$ sudo /etc/rc.d/tarpitd -d check ; echo $?
doing rc_read_runfile
doing rc_check
1
$ sudo /etc/rc.d/tarpitd -d stop
doing rc_read_runfile
doing rc_check
I'm using 5.5-release
What am I doing wrong?
Thank you!
Sebastien Leclerc
