hello,

dec 18 snap, running on i386

given is an ipsec gateway (i think it's running some older openswan or
some other swan) to which i need to connect, establishing a net-net
tunnel. the parameters needed are "IKE rekeying 1440 minutes (24
hours), IPSEC 3600 seconds (1 hour), both with 3DES/SHA1, no PFS", and
these are carved in stone, i was told.

i can't seem to get isakmpd to establish a tunnel with that site. it
seems as if phase 1 would have been negotiatied fine, but when isakmpd
then sends an `initial contact', then gets back an ipv4_addr, then
things literally stop happening here.

i checked isakmpd packet dumps on other machines, and from what i
gather, here my isakmpd is the one who should start entering into
phase 2 negotiations, but that never happens.

that's what the packet log tells me (X.Y.Z.185 is isakmpd, the local
side; A.B.C.42 is the remote side)

Dec 20 03:45:23.465777 0.0.0.0.500 > A.B.C.42.500:  [udp sum ok] isakmp v1.0 
exchange ID_PROT
        cookie: 636b40261faa87b0->0000000000000000 msgid: 00000000 len: 164
        payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY
            payload: PROPOSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0 
xforms: 1
                payload: TRANSFORM len: 36
                    transform: 0 ID: ISAKMP
                        attribute ENCRYPTION_ALGORITHM = 3DES_CBC
                        attribute HASH_ALGORITHM = SHA
                        attribute AUTHENTICATION_METHOD = PRE_SHARED
                        attribute GROUP_DESCRIPTION = MODP_1024
                        attribute LIFE_TYPE = SECONDS
                        attribute LIFE_DURATION = 00015180
        payload: VENDOR len: 20 (supports v2 NAT-T, 
draft-ietf-ipsec-nat-t-ike-02)
        payload: VENDOR len: 20 (supports v3 NAT-T, 
draft-ietf-ipsec-nat-t-ike-03)
        payload: VENDOR len: 20 (supports NAT-T, RFC 3947)
        payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 192)
Dec 20 03:45:23.530916 A.B.C.42.500 > X.Y.Z.185.500:  [udp sum ok] isakmp v1.0 
exchange ID_PROT
        cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: 00000000 len: 84
        payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY
            payload: PROPOSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0 
xforms: 1
                payload: TRANSFORM len: 36
                    transform: 1 ID: ISAKMP
                        attribute ENCRYPTION_ALGORITHM = 3DES_CBC
                        attribute HASH_ALGORITHM = SHA
                        attribute AUTHENTICATION_METHOD = PRE_SHARED
                        attribute GROUP_DESCRIPTION = MODP_1024
                        attribute LIFE_TYPE = SECONDS
                        attribute LIFE_DURATION = 00015180 [ttl 0] (id 1, len 
112)
Dec 20 03:45:23.548557 X.Y.Z.185.500 > A.B.C.42.500:  [udp sum ok] isakmp v1.0 
exchange ID_PROT
        cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: 00000000 len: 180
        payload: KEY_EXCH len: 132
        payload: NONCE len: 20 [ttl 0] (id 1, len 208)
Dec 20 03:45:24.141436 A.B.C.42.500 > X.Y.Z.185.500:  [udp sum ok] isakmp v1.0 
exchange ID_PROT
        cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: 00000000 len: 184
        payload: KEY_EXCH len: 132
        payload: NONCE len: 24 [ttl 0] (id 1, len 212)
Dec 20 03:45:24.162027 X.Y.Z.185.500 > A.B.C.42.500:  [udp sum ok] isakmp v1.0 
exchange ID_PROT
        cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: 00000000 len: 92
        payload: ID len: 12 type: IPV4_ADDR = X.Y.Z.185
        payload: HASH len: 24
        payload: NOTIFICATION len: 28
            notification: INITIAL CONTACT (636b40261faa87b0->83821d77d8a07cd2) 
[ttl 0] (id 1, len 120)
Dec 20 03:45:24.899941 A.B.C.42.500 > X.Y.Z.185.500:  [udp sum ok] isakmp v1.0 
exchange ID_PROT
        cookie: 636b40261faa87b0->83821d77d8a07cd2 msgid: 00000000 len: 68
        payload: ID len: 12 type: IPV4_ADDR = A.B.C.42
        payload: HASH len: 24 [ttl 0] (id 1, len 96)

and then silence. there's nothing not even down the road (i waited for
like 20 minutes for something, anything to happen) as `no proposal
chosen', or any other kind of message that would give a clue as to
where to start.


with an other peer, at this point i also see

Dec 20 03:55:29.817971 me.500 > otherpeer.500:  [udp sum ok] isakmp v1.0 
exchange ID_PROT
        cookie: 857f6ffe85cd2ad6->3d173193c107d434 msgid: 00000000 len: 228
        payload: KEY_EXCH len: 132
        payload: NONCE len: 20
        payload: NAT-D-DRAFT len: 24
        payload: NAT-D-DRAFT len: 24 [ttl 0] (id 1, len 256)
Dec 20 03:55:29.914622 otherpeer.500 > me.500:  [udp sum ok] isakmp v1.0 
exchange ID_PROT
        cookie: 857f6ffe85cd2ad6->3d173193c107d434 msgid: 00000000 len: 228
        payload: KEY_EXCH len: 132
        payload: NONCE len: 20
        payload: NAT-D-DRAFT len: 24
        payload: NAT-D-DRAFT len: 24 [ttl 0] (id 1, len 256)

and this is when phase2 negotiations actually begin, and eventually
complete, and a tunnel is established. the only difference i see in
this case is that this latter peer supports some features, which at
the end aren't being used, but still get negotiated to some extent. i
don't know whether this is a useful piece of information.

following is the isakmpd.conf i'm trying to use. i set
default-phase-{1,2}-lifetime so that even in the proposal it alredy
send 86400 seconds for p1, but that didn't seem to make a difference
either...

[General]
Retransmits=            5
Exchange-max-time=      120
Check-interval=         1
Default-phase-1-lifetime=               86400,60:86400
Default-phase-2-lifetime=               3600,60:86400


[Phase 1]
A.B.C.42=               ISAKMP-Peer-Remote-peer

[Phase 2]
Connections=            IPsec-Remote-peer-192-168-168-0-24

[ISAKMP-Peer-Remote-peer]
Phase=                  1
Transport=              udp
Address=                A.B.C.42
Configuration=          Remote-peer-main-mode
Authentication=         ***

[Remote-peer-main-mode]
EXCHANGE_TYPE=          ID_PROT
Transforms=             3DES-SHA-GRP2

[Remote-peer-quick-mode]
EXCHANGE_TYPE=          QUICK_MODE
Transforms=             QM-ESP-3DES-SHA-SUITE

[IPSec-Remote-peer-192-168-168-0-24]
Phase=                  2
ISAKMP-Peer=            ISAKMP-Peer-Remote-peer
Configuration=          Remote-peer-quick-mode
Remote-ID=              Net-Remote-peer-192-168-168-0-24
Local-ID=               Net-Local-192-168-102-0-24

[Net-Local-192-168-102-0-24]
ID-type=                IPV4_ADDR_SUBNET
Network=                192.168.102.0
Netmask=                255.255.255.0

[Net-Remote-peer-192-168-168-0-24]
ID-type=                IPV4_ADDR_SUBNET
Network=                192.168.168.0
Netmask=                255.255.255.0


i managed to get a tunnel up with this peer, using astaro security
linux and it's clicky interface to openswan, so at least to *some*
extent and/or in *some* way, the peer must have produced a working
configuration at their side.

on the astaro box i did the same settings in click-language that are
above in isakmpd.conf-talk. the tunnel came up fine with that, but
understandably i wouldn't quite like to keep that solution.

(as a side note, i just remembered ike-scan, and ran it against the
peer. it says:

Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK
Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)

so i tried with 28800 seconds as well, same result.)

any insight is greatly appreciated.

thanks,

-- 
[-]

mkdir /nonexistent

Reply via email to