[strongSwan] No answer to first packet (IKE Phase 1)

[Martin Werthmöller]

Am Sa, 15 Dez 2012 um 09:43 GMT +0100 schrieb Andreas Steffen:
> Hi Martin,
> 
> it might be that the gateway does not like strongSwan's authentication
> or crypto proposals. Pluto 4.x e.g. does not support IKEv1 Aggressive
> Mode.
> 
Mmh. I compared the proposals of the strongSwan client with the
windows client based on the network dump (tcpdump -v -v -v). It seems
nearly identical.

** Windows Client

$CLIENT_ADDRESS.10952 > $GW_ADDRESS.500: [udp sum ok] isakmp 1.0
msgid 00000000 cookie d986fa3e946e1f12->0000000000000000: phase 1 Iident:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
          (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike
              (type=enc value=aes)
              (type=hash value=md5)
              (type=auth value=rsa sig)
              (type=group desc value=modp1024)
              (type=lifetype value=sec)
              (type=lifeduration value=7080)
              (type=keylen value=0080))))
         (vid: len=8)
         (vid: len=16)
         (vid: len=16)
         (vid: len=16)
         (vid: len=16)
         (vid: len=16)
         (vid: len=16)
         (vid: len=16)
         (vid: len=16)
         (vid: len=20)


** strongSwan
 
$CLIENT_ADDRESS.500 > $GW_ADDRESS.500: [udp sum ok] isakmp 1.0
msgid 00000000 cookie 11c0ecba8587f030->0000000000000000: phase 1 I ident:
    (sa: doi=ipsec situation=identity
        (p: #0 protoid=isakmp transform=1
          (t: #0 id=ike
            (type=lifetype value=sec)
            (type=lifeduration value=7080)
            (type=enc value=aes)
            (type=hash value=md5)
            (type=keylen value=0080)
            (type=auth value=rsa sig)
            (type=group desc value=modp1024))))
        (vid: len=16 882fe56d6fd20dbc2251613b2ebe5beb)
        (vid: len=8 09002689dfd6b712)
        (vid: len=16 afcad71368a1f1c96b8696fc77570100)
        (vid: len=16 4a131c81070358455c5728f20e95452f)
        (vid: len=16 7d9419a65310ca6f2c179d9215529d56)
        (vid: len=16 cd60464335df21f87cfdb2fc68b6a448)
        (vid: len=16 90cb80913ebb696e086381b5ec427b1f)
        (vid: len=16 4485152d18b6bbcd0be8a8469579ddcc)



With iptables, I try to move the source port of the strongSwan client
to 10952. Same result.

The only difference I see, is the order of the parameters in the
packet or - more deeply - the XAUTH parameter  


> 
> On 12/14/2012 02:38 PM, Martin Werthmöller wrote:
> > Hi Strongswan users,
> > 
> > we like to setup a IPSec connection to a Telco Tec LiSS VPN Gateway.
> > We test the VPN connection with a windows client (NCP). Here, the
> > connection will be established immediately.
> > 
> > As we run our strongSwan client, the connection establishment runs
> > into a timeout.
> > 
> >   010 "liss" #3: STATE_MAIN_I1: retransmission; will wait 20s for response
> >  
> > The pluto debug log shows no more information about this. 
> > The Windows Client and the strongSwan client uses the same certificate
> > an connection settings (configfile beneath).
> > 
> > We also capture the traffic of both connections establishments via
> > tcpdump. With our strongSwan client, the VPN gateway will no answer to
> > the first UDP packet from pluto. We examined the first packets of both
> > clients.
> > 
> > Here we saw a difference at the Payload (Vendor ID (13) of both
> > packets.
> > 
> > ** NCP client
> > 
> > Type Payload: Vendor ID (13) : Unknown Vendor ID
> > Type Payload: Vendor ID (13) : draft-ietf-ipsec-nat-t-ike-03
> > Type Payload: Vendor ID (13) : draft-ietf-ipsec-nat-t-ike-02\n
> > Type Payload: Vendor ID (13) : draft-ietf-ipsec-nat-t-ike-00
> > Type Payload: Vendor ID (13) : RFC 3947 Negotiation of NAT-Traversal in the IKE 
> > Type Payload: Vendor ID (13) : RFC 3706 DPD (Dead Peer Detection)
> > Type Payload: Vendor ID (13) : Unknown Vendor ID
> > Type Payload: Vendor ID (13) : Unknown Vendor ID
> > Type Payload: Vendor ID (13) : Unknown Vendor ID
> > Type Payload: Vendor ID (13) : Microsoft L2TP/IPSec VPN Client
> > 
> > 
> > ** stronSwan client
> > 
> > Type Payload: Vendor ID (13) : strongSwan
> > Type Payload: Vendor ID (13) : XAUTH
> > Type Payload: Vendor ID (13) : RFC 3706 DPD (Dead Peer Detection)
> > Type Payload: Vendor ID (13) : RFC 3947 Negotiation of Traversal in the IKE
> > Type Payload: Vendor ID (13) : draft-ietf-ipsec-nat-t-ike-03
> > Type Payload: Vendor ID (13) : draft-ietf-ipsec-nat-t-ike-02
> > Type Payload: Vendor ID (13) : draft-ietf-ipsec-nat-t-ike-02\n
> > Type Payload: Vendor ID (13) : draft-ietf-ipsec-nat-t-ike-00
> > 
> > 
> > Beside the differences in "Unknown Vendor ID" and the "L2TP Client"
> > the strongSwan packet conatains the XAUTH "Flag".
> > 
> > May this be the problem of the gateway timeouts?
> > 
> > How could we disable the XAUT at the first packet?   
> > 
> > 
> > Best regards,
> > Martin Werthmoeller
> > 
> 
> 
> -- 
> ======================================================================
> Andreas Steffen                         andreas.steffen at strongswan.org
> strongSwan - the Linux VPN Solution!                www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==
> 




-- 
LWsystems - IT-Service and Consulting
mw at lw-systems.de * http://www.lw-systems.de