We're trying to get a site-site (1.2.3.0/24 <-> 2.0.0.0/8) VPN going bwtween OBSD 4.5 and MS ISA 2006 Enterprise in a NLB cluster.
Thing is, after the Main mode completes, and our tunnel request for 1.2.3.0/24 -> 2.0.0.0/8 is accepted (as seen in the "Oakley log"), ISA sends a funny request (i.i.i.i is the ISA public IP address and b.b.b.b is the OBSD's):
Oct 27 11:52:32.095316 i.i.i.i.ipsec-nat-t >
b.b.b.b.ipsec-nat-t: [bad udp cksum 4650!]
udpencap: isakmp v1.0 exchange QUICK_MODE commit
cookie: 7fdb04f69765596c->61831f8128bdc2c8 msgid: 1431b381 len: 316
payload: HASH len: 24
payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY
payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4
xforms: 1 SPI: 0x29aefb52
payload: TRANSFORM len: 32
transform: 1 ID: 3DES
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 000004b0
attribute ENCAPSULATION_MODE = 61443 (unknown)
attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
attribute GROUP_DESCRIPTION = 2
payload: KEY_EXCH len: 132
payload: NONCE len: 24
payload: ID len: 16 type: IPV4_ADDR_SUBNET = 1.2.3.0/255.255.255.0
payload: ID len: 31 type: FQDN = "isa.full.domain.name.com" [ttl 0] (id 1, len 348)
OpenBSD doesn't acccept FQDN where it expects an IPV4_ADDR or IPV4_ADDR_SUBNET:
Oct 27 11:52:32.097219 b.b.b.b.ipsec-nat-t >
i.i.i.i.ipsec-nat-t: [bad udp cksum 2c00!] udpencap: isakmp v1.0
exchange INFO
cookie: 7fdb04f69765596c->61831f8128bdc2c8 msgid: 377e5ad8 len: 64
payload: HASH len: 24
payload: NOTIFICATION len: 12
notification: INVALID ID INFORMATION [ttl 0] (id 1, len 96)
And the conversation is terminated.
The relevant part of the Oakley log:
10-27: 11:52:17:209:17bc Receive: (get) SA = 0x020fdde0 from b.b.b.b.4500
10-27: 11:52:17:209:17bc ISAKMP Header: (V1.0), len = 292
10-27: 11:52:17:209:17bc I-COOKIE 7fdb04f69765596c
10-27: 11:52:17:209:17bc R-COOKIE 61831f8128bdc2c8
10-27: 11:52:17:209:17bc exchange: Oakley Quick Mode
10-27: 11:52:17:209:17bc flags: 1 ( encrypted )
10-27: 11:52:17:209:17bc next payload: HASH
10-27: 11:52:17:209:17bc message ID: 1431b381
10-27: 11:52:17:209:17bc processing HASH (QM)
10-27: 11:52:17:209:17bc ClearFragList
10-27: 11:52:17:209:17bc processing payload NONCE
10-27: 11:52:17:209:17bc processing payload KE
10-27: 11:52:17:209:17bc Quick Mode KE processed; Saved KE data
10-27: 11:52:17:209:17bc processing payload ID
10-27: 11:52:17:209:17bc processing payload ID
10-27: 11:52:17:209:17bc processing payload SA
10-27: 11:52:17:209:17bc Negotiated Proxy ID: Src 1.2.3.0.0 Dst 2.0.0.0.0
10-27: 11:52:17:209:17bc Src id for subnet. Mask 255.255.255.0
10-27: 11:52:17:209:17bc Dst id for subnet. Mask 255.0.0.0
10-27: 11:52:17:209:17bc Checking Proposal 1: Proto= ESP(3), num trans=1 Next=0
10-27: 11:52:17:209:17bc Checking Transform # 1: ID=Triple DES CBC(3)
10-27: 11:52:17:209:17bc SA life type in seconds
10-27: 11:52:17:209:17bc SA life duration 1200
10-27: 11:52:17:209:17bc tunnel mode is Tunnel Mode with UDP encapsulation (61443)
10-27: 11:52:17:209:17bc HMAC algorithm is SHA(2)
10-27: 11:52:17:209:17bc group description for PFS is 2
10-27: 11:52:17:209:17bc Finding Responder Policy for SRC=1.2.3.0.0000 DST=2.0.0.0.0000, SRCMask=255.255.255.0, DSTMask=255.0.0.0, Prot=0 InTunnelEndpt 2301d90a OutTunnelEndpt 47ef9dd5
10-27: 11:52:17:209:17bc QM PolicyName: ISA Server XXXXX QM Policy dwFlags 0
10-27: 11:52:17:209:17bc QMOffer[0] LifetimeKBytes 0 LifetimeSec 1200
10-27: 11:52:17:209:17bc QMOffer[0] dwFlags 0 dwPFSGroup 2
10-27: 11:52:17:209:17bc Algo[0] Operation: ESP Algo: Triple DES CBC HMAC: SHA
10-27: 11:52:17:209:17bc Phase 2 SA accepted: proposal=1 transform=1
10-27: 11:52:17:209:17bc GetSpi: src = 1.2.3.0.0000, dst = 2.0.0.0.0000, proto = 00, context = 00000000, srcMask = 255.255.255.0, destMask = 255.0.0.0, TunnelFilter 1
10-27: 11:52:17:209:17bc Setting SPI 699333458
10-27: 11:52:17:240:17bc constructing ISAKMP Header
10-27: 11:52:17:240:17bc constructing HASH (null)
10-27: 11:52:17:240:17bc constructing SA (IPSEC)
10-27: 11:52:17:240:17bc constructing QM KE
10-27: 11:52:17:240:17bc constructing NONCE (IPSEC)
10-27: 11:52:17:240:17bc constructing ID (proxy)
10-27: 11:52:17:240:17bc constructing ID (proxy)
10-27: 11:52:17:240:17bc FQDN ID <hexhexhexhexhexhexhexhex>
10-27: 11:52:17:240:17bc constructing HASH (QM)
This (above) is acceptance of our proposal as I gather ("Phase 2 SA accepted: proposal=1 transform=1", also found the correct policy). But then the funny request is sent to the OpenBSD (unfortunately it's not possible to tell from the log what ISA really wants):
10-27: 11:52:17:240:17bc
10-27: 11:52:17:240:17bc Sending: SA = 0x020FDDE0 to b.b.b.b:Type 2.4500
10-27: 11:52:17:240:17bc ISAKMP Header: (V1.0), len = 316
10-27: 11:52:17:240:17bc I-COOKIE 7fdb04f69765596c
10-27: 11:52:17:240:17bc R-COOKIE 61831f8128bdc2c8
10-27: 11:52:17:240:17bc exchange: Oakley Quick Mode
10-27: 11:52:17:240:17bc flags: 3 ( encrypted commit )
10-27: 11:52:17:240:17bc next payload: HASH
10-27: 11:52:17:240:17bc message ID: 1431b381
10-27: 11:52:17:240:17bc Ports S:9411 D:9411
From what I know about IPsec is this a request for tunnel between our (internal) network and ISA server itself (referenced by a FQDN). Now, even if it would resolve (it doesn't) and OBSD would eat it - why this tunnel?
ISA administrator claims that he has defined only one tunnel: 2.0.0.0/8 <-> 1.2.3.0/24
Has anyone seen such a thing? What can be done? What questions can/should I ask?
Thanks a lot...
