Discussion:
Slew of Firewall-1/OpenBSD VPN Troubles
Chris Cameron
2004-08-05 13:12:09 UTC
Permalink
Still fighting to get a reliable VPN tunnel working. Thanks to
Hans-Joerg Hoexer for his help before, but that seems to just be the tip
of the iceburg.

The problem I'm having is, my VPN tunnel works, but it drops a
significant number of packets, and spews numerous errors on the OpenBSD
side (Firewall-1 isn't complaining at all).


When starting up isakmpd, I get the following error:

Aug 4 03:48:41 gate1 isakmpd[2737]: exchange_setup_p1: expected
exchange type ID_PROT got AGGRESSIVE
Aug 4 03:49:11 gate1 last message repeated 2 times


On the firewall-1 side of things, Aggressive is disabled, in trying all
combinations of Aggressive and ID_PROT (for both Firewall-1 and OBSD),
It always gives the error above.


The above error is later followed by a -lot- of:

Aug 4 13:46:29 gate1 isakmpd[28518]: message_parse_payloads: reserved
field non-zero: 20
Aug 4 13:46:29 gate1 isakmpd[28518]: dropped message from
216.82.85.146 port 500 due to notification type PAYLOAD_MALFORMED
Aug 4 13:46:29 gate1 isakmpd[28518]: message_parse_payloads: reserved
field non-zero: 20
Aug 4 13:46:29 gate1 isakmpd[28518]: dropped message from
216.82.85.146 port 500 due to notification type PAYLOAD_MALFORMED
Aug 4 13:46:49 gate1 isakmpd[28518]: message_parse_payloads: invalid
next payload type 114 in payload of type 8
Aug 4 13:46:49 gate1 isakmpd[28518]: dropped message from
216.82.85.146 port 500 due to notification type INVALID_PAYLOAD_TYPE
Aug 4 13:46:49 gate1 isakmpd[28518]: message_parse_payloads: invalid
next payload type 114 in payload of type 8
Aug 4 13:46:49 gate1 isakmpd[28518]: dropped message from
216.82.85.146 port 500 due to notification type INVALID_PAYLOAD_TYPE
Aug 4 07:46:42 gate1 /bsd: hme4: status=400<MAXPKT>



Notice the out-of-whack time between what isakmpd is reporting and what
the kernel is reporting. I have ntpd running, and the kernel does have
the correct time. Even after restarting isakmpd, it still reports the
time wrong.



I've searched, looked at debugging and isakmpd.pcap output, but have no
idea what its problem is. I've tried a patched and unpatched isakmpd
with no change in behaviour (just making sure). I've also turned on
increased logging with Firewall-1 with little usable output. From the
looks of it, when the two negotiated it does it several times for
whatever reason.



Any help on this would be appreciated. As before, below is my current
configuration.

Thanks,

Chris



isakmpd.conf:
[General]
Default-phase-1-lifetime= 10080,60:604800
Default-phase-2-lifetime= 3600,60:604800

[Phase 1]
216.82.85.146= gate2-peer

[Phase 2]
Connections= Office-VPN

[gate2-peer]
Phase= 1
Transport= udp
Address= 216.82.85.146
Configuration= Default-main-mode
Authentication= xxxxx

[Office-VPN]
Phase= 2
ISAKMP-peer= gate2-peer
Configuration= Default-quick-mode
Local-ID= Gate1-Internal-network
Remote-ID= Gate2-Internal-network

[Gate1-Internal-network]
ID-type= IPV4_ADDR_SUBNET
Network= 192.168.121.0
Netmask= 255.255.255.0

[Gate2-Internal-network]
ID-type= IPV4_ADDR_SUBNET
Network= 192.168.120.0
Netmask= 255.255.255.0

[Default-main-mode]
DOI= IPSEC
EXCHANGE_TYPE= ID_PROT
Transforms= 3DES-SHA

[Default-quick-mode]
DOI= IPSEC
EXCHANGE_TYPE= QUICK_MODE
Suites= QM-ESP-3DES-SHA-SUITE



isakmpd.policy:
Keynote-version: 2
Authorizer: "POLICY"
Conditions: app_domain == "IPsec policy" &&
esp_present == "yes" &&
esp_enc_alg != "null" -> "true";



isakmpd.pcap:

# tcpdump -vr isakmpd.pcap
tcpdump: WARNING: compensating for unaligned libpcap packets
18:51:24.451683 0.0.0.0.isakmp > 216.82.85.146.isakmp: [bad udp cksum
a77f!] isakmp v1.0 exchange ID_PROT
cookie: e85ce0fda26a521f->0000000000000000 msgid: 00000000 len:
80
payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0
xforms: 1
payload: TRANSFORM len: 32
transform: 0 ID: ISAKMP
attribute ENCRYPTION_ALGORITHM = 3DES_CBC
attribute HASH_ALGORITHM = SHA
attribute AUTHENTICATION_METHOD = PRE_SHARED
attribute NONE =
attribute NONE =
attribute NONE = [ttl 0] (id 1)
18:51:24.457956 216.82.85.146.isakmp > 209.82.103.246.isakmp: [bad udp
cksum a77f!] isakmp v1.0 exchange ID_PROT
cookie: e85ce0fda26a521f->0fd4aee964db42ae msgid: 00000000 len:
80
payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0
xforms: 1
payload: TRANSFORM len: 32
transform: 1 ID: ISAKMP
attribute ENCRYPTION_ALGORITHM = 3DES_CBC
attribute HASH_ALGORITHM = SHA
attribute AUTHENTICATION_METHOD = PRE_SHARED
attribute NONE =
attribute NONE =
attribute NONE = [ttl 0] (id 1)
18:51:24.662689 209.82.103.246.isakmp > 216.82.85.146.isakmp: [bad udp
cksum baf!] isakmp v1.0 exchange ID_PROT
cookie: e85ce0fda26a521f->0fd4aee964db42ae msgid: 00000000 len:
180
payload: KEY_EXCH len: 132
payload: NONCE len: 0 [|isakmp] [ttl 0] (id 1)
18:51:24.670937 216.82.85.146.isakmp > 209.82.103.246.isakmp: [bad udp
cksum 1e67!] isakmp v1.0 exchange ID_PROT
cookie: e85ce0fda26a521f->0fd4aee964db42ae msgid: 00000000 len:
184
payload: KEY_EXCH len: 132
payload: NONCE len: 0 [|isakmp] [ttl 0] (id 1)
18:51:24.917675 209.82.103.246.isakmp > 216.82.85.146.isakmp: [bad udp
cksum 853f!] isakmp v1.0 exchange ID_PROT
cookie: e85ce0fda26a521f->0fd4aee964db42ae msgid: 00000000 len:
92
payload: ID len: 12 type: IPV4_ADDR = 209.82.103.246
payload: HASH len: 24
payload: NOTIFICATION len: 28
notification: 0 (unknown) [ttl 0] (id 1)
18:51:24.941871 216.82.85.146.isakmp > 209.82.103.246.isakmp: [udp sum
ok] isakmp v1.0 exchange ID_PROT
cookie: e85ce0fda26a521f->0fd4aee964db42ae msgid: 00000000 len:
68
payload: ID len: 12 type: IPV4_ADDR = 216.82.85.146
payload: HASH len: 24 [ttl 0] (id 1)
18:51:24.944231 209.82.103.246.isakmp > 216.82.85.146.isakmp: [bad udp
cksum 1015!] isakmp v1.0 exchange QUICK_MODE
cookie: e85ce0fda26a521f->0fd4aee964db42ae msgid: 1595370b len:
152
payload: HASH len: 24
payload: SA len: 48 DOI: 1(IPSEC) situation: IDENTITY_ONLY
payload: PROPOSAL len: 36 proposal: 0 proto: RESERVED spisz:
0 xforms: 0
payload: NONCE len: 0 [|isakmp] [ttl 0] (id 1)
18:51:24.951690 216.82.85.146.isakmp > 209.82.103.246.isakmp: [bad udp
cksum 4830!] isakmp v1.0 exchange QUICK_MODE
cookie: e85ce0fda26a521f->0fd4aee964db42ae msgid: 1595370b len:
164
payload: HASH len: 24
payload: SA len: 48 DOI: 1(IPSEC) situation: IDENTITY_ONLY
payload: PROPOSAL len: 36 proposal: 0 proto: RESERVED spisz:
0 xforms: 0
payload: NONCE len: 0 [|isakmp] [ttl 0] (id 1)
18:51:24.953417 209.82.103.246.isakmp > 216.82.85.146.isakmp: [udp sum
ok] isakmp v1.0 exchange QUICK_MODE
cookie: e85ce0fda26a521f->0fd4aee964db42ae msgid: 1595370b len:
52
payload: HASH len: 24 [ttl 0] (id 1)
18:51:27.240071 209.82.103.246.isakmp > 216.82.85.146.isakmp: [udp sum
ok] isakmp v1.0 exchange INFO
cookie: 3098fcb858a41db1->0000000000000000 msgid: 00000000 len:
56
payload: NOTIFICATION len: 28
notification: INVALID COOKIE [ttl 0] (id 1)
18:51:31.236143 209.82.103.246.isakmp > 216.82.85.146.isakmp: [udp sum
ok] isakmp v1.0 exchange INFO
cookie: f3e9b11a72e576c1->0000000000000000 msgid: 00000000 len:
56
payload: NOTIFICATION len: 28
notification: INVALID COOKIE [ttl 0] (id 1)
18:51:35.236150 209.82.103.246.isakmp > 216.82.85.146.isakmp: [udp sum
ok] isakmp v1.0 exchange INFO
cookie: c2fe701eed6b58e2->0000000000000000 msgid: 00000000 len:
56
payload: NOTIFICATION len: 28
notification: INVALID COOKIE [ttl 0] (id 1)
18:51:39.235936 209.82.103.246.isakmp > 216.82.85.146.isakmp: [udp sum
ok] isakmp v1.0 exchange INFO
cookie: 0f67a445defb1f19->0000000000000000 msgid: 00000000 len:
56
payload: NOTIFICATION len: 28
notification: INVALID COOKIE [ttl 0] (id 1)
18:51:43.235962 209.82.103.246.isakmp > 216.82.85.146.isakmp: [udp sum
ok] isakmp v1.0 exchange INFO
cookie: 8d9067d2ef7ed9f0->0000000000000000 msgid: 00000000 len:
56
payload: NOTIFICATION len: 28
notification: INVALID COOKIE [ttl 0] (id 1)
18:52:47.553864 209.82.103.246.isakmp > 216.82.85.146.isakmp: [udp sum
ok] isakmp v1.0 exchange INFO
cookie: e85ce0fda26a521f->0fd4aee964db42ae msgid: 0c481fba len:
68
payload: HASH len: 24
payload: DELETE len: 16 [ttl 0] (id 1)


Link to isakmpd -d -DA=90 (740k-ish, hopefully still useable):
http://chris.upnix.com/gate1/isakmpddebug.txt
Chris Cameron
2004-08-05 13:49:59 UTC
Permalink
Make sure your Phase II negotiation timeouts match, this helps quite
a bit. How's communication between the two systems generically? Is
there random packet loss under non-vpn communication?
That was the first problem I fixed, fixing the phase 2 timeouts.

Communication is excellent outside the VPN. I'll leave 'ping's running
every which way and the only packet loss is from the packets going over
the VPN. Over the VPN it varies, but I've seen as high as 49% packet
loss when there is other traffic on the VPN.


Chris
Steven S.
2004-08-05 15:20:20 UTC
Permalink
Have you tried larger packets for non-vpn testing? Have you checked into
the possibility of packet fragmentation issues under the VPN? Any pf rules
and logged dropped packets?

Does anyone know if the reported "bad udp cksum" is important?

8:51:24.944231 209.82.103.246.isakmp > 216.82.85.146.isakmp: [bad udp cksum
1015!] isakmp v1.0 exchange QUICK_MODE

-Steve S.
Post by Chris Cameron
Make sure your Phase II negotiation timeouts match, this helps quite
a bit. How's communication between the two systems generically? Is
there random packet loss under non-vpn communication?
That was the first problem I fixed, fixing the phase 2 timeouts.
Communication is excellent outside the VPN. I'll leave 'ping's running
every which way and the only packet loss is from the packets going
over the VPN. Over the VPN it varies, but I've seen as high as 49%
packet loss when there is other traffic on the VPN.
Chris
Steven S.
2004-08-05 13:43:25 UTC
Permalink
What version of FW-1, which HotFix? On FP-3 & NG the 'vpn' command is
useful. 'vpn debug ikeon' writes to a file vpnd.elg, but unfortunately to
make much sense of the log you'll need the IKEView.exe tool, which Check
Point hordes. The 'vpn tunnelutil' will show you what FW-1 (or really
VPN-1) has for cookies and SPIs.

Make sure your Phase II negotiation timeouts match, this helps quite a bit.
How's communication between the two systems generically? Is there random
packet loss under non-vpn communication?

-Steve S.
Post by Chris Cameron
Still fighting to get a reliable VPN tunnel working. Thanks to
Hans-Joerg Hoexer for his help before, but that seems to just be the tip
of the iceburg.
The problem I'm having is, my VPN tunnel works, but it drops a
significant number of packets, and spews numerous errors on the OpenBSD
side (Firewall-1 isn't complaining at all).
Chris Cameron
2004-08-08 05:15:50 UTC
Permalink
Purely for the archives, but I believe this has been "fixed" for the
most part.

Firewall-1 had a "renegotiate IPSec SA after ever x KBytes" that was set
to 500k. This was the cause for the repeated renegotiations.

After disabling this, all the errors went away. So, don't entirely know
what was going on, but from reading through archives and PR's it seems
isakmpd reports errors in weird ways anyway.

I've left it running long enough that it's renegotiated on its own and
the errors didn't show up.



Chris


Firewall-1 Checkpoint VPN
Post by Chris Cameron
Still fighting to get a reliable VPN tunnel working. Thanks to
Hans-Joerg Hoexer for his help before, but that seems to just be the
tip of the iceburg.
The problem I'm having is, my VPN tunnel works, but it drops a
significant number of packets, and spews numerous errors on the
OpenBSD side (Firewall-1 isn't complaining at all).
Aug 4 03:48:41 gate1 isakmpd[2737]: exchange_setup_p1: expected
exchange type ID_PROT got AGGRESSIVE
Aug 4 03:49:11 gate1 last message repeated 2 times
On the firewall-1 side of things, Aggressive is disabled, in trying
all combinations of Aggressive and ID_PROT (for both Firewall-1 and
OBSD), It always gives the error above.
Loading...