[Openswan Users] can't get connected :-(

[Ian Zimmerman]

Hi,

I have been struggling to make use of my employer's VPN.
They gave me instructions assuming I'd use SSH Sentinel on Windows.

The instructions:

The remote public IP (1.2.3.4)
The local private address (192.168.254.102/32)
The remote private subnet (10.0.0.0/8)
The local ID (addy at asid.com)
The PSK "notreallythis"
tunnel mode, ESP, aggressive mode on, cipher AES-256.

here's my ipsec.secrets:

# RCSID $Id: ipsec.secrets.proto,v 1.3.6.1 2005/09/28 13:59:14 paul Exp $
# This file holds shared secrets or RSA private keys for inter-Pluto
# authentication.  See ipsec_pluto(8) manpage, and HTML documentation.

# RSA private key for this host, authenticating it to any other host
# which knows the public part.  Suitable public keys, for ipsec.conf, DNS,
# or configuration of other implementations, can be extracted conveniently
# with "ipsec showhostkey".

%any 1.2.3.4: PSK "notreallythis"


here's my ipsec.conf:

# /etc/ipsec.conf - Openswan IPsec configuration file
# RCSID $Id: ipsec.conf.in,v 1.15.2.2 2005/11/14 20:10:27 paul Exp $

# This file:  /usr/share/doc/openswan/ipsec.conf-sample
#
# Manual:     ipsec.conf.5


version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
        # plutodebug / klipsdebug = "all", "none" or a combation from below:
        # "raw crypt parsing emitting control klips pfkey natt x509 private"
        # eg:
        # plutodebug="control parsing"
        #
        # Only enable klipsdebug=all if you are a developer
        #
        # NAT-TRAVERSAL support, see README.NAT-Traversal
        # nat_traversal=yes
        # virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12
        rp_filter=%unchanged
        plutodebug=all
        plutowait=yes
        
# Add connections here

# sample VPN connection
#conn sample
#               # Left security gateway, subnet behind it, nexthop toward right.
#               left=10.0.0.1
#               leftsubnet=172.16.0.0/24
#               leftnexthop=10.22.33.44
#               # Right security gateway, subnet behind it, nexthop toward left.
#               right=10.12.12.1
#               rightsubnet=192.168.0.0/24
#               rightnexthop=10.101.102.103
#               # To authorize this connection, but not actually start it, 
#               # at startup, uncomment this.
#               #auto=start

conn myfailedconn
        left=%defaultroute
        leftsubnet=192.168.254.102/32
        right=1.2.3.4
        rightsubnet=10.0.0.0/8
        auto=start
        authby=secret
        leftid=addy at asid.com
        aggrmode=yes
        ike=aes-256     

#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf


now assume my local public interface's address is 5.6.7.8
here's the log output when I start ipsec / pluto:

Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: algorithm ESP auth attr: id=251, name=(null), keysizemin=0, keysizemax=0
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1:  
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1:  
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: stats db_ops.c: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0} 
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1:  
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: "myfailedconn": 192.168.254.102/32===5.6.7.8[addy at asid.com]...1.2.3.4===10.0.0.0/8; prospective erouted; eroute owner: #0
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: "myfailedconn":     srcip=unset; dstip=unset; srcup=ipsec _updown; dstup=ipsec _updown;
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: "myfailedconn":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: "myfailedconn":   policy: PSK+ENCRYPT+TUNNEL+PFS+UP+AGGRESSIVE; prio: 32,8; interface: eth0; 
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: "myfailedconn":   newest ISAKMP SA: #0; newest IPsec SA: #0; 
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: "myfailedconn":   IKE algorithms wanted: 7_256-1-5, 7_256-2-5, 7_256-1-2, 7_256-2-2, flags=strict
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: "myfailedconn":   IKE algorithms found:  7_256-1_128-5, 7_256-2_160-5, 7_256-1_128-2, 7_256-2_160-2, 
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1:  
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1: #1: "myfailedconn":500 STATE_AGGR_I1 (sent AI1, expecting AR1); EVENT_SO_DISCARD in -1s; nodpd
Jun 20 01:54:24 dellgw ipsec__plutorun: 000 "myfailedconn" #1:  
Jun 20 01:54:24 dellgw ipsec__plutorun: ...could not start conn "myfailedconn"
Jun 20 01:54:24 dellgw ipsec__plutorun: !pluto failure!:  exited with error status 134 (signal 6)
Jun 20 01:54:24 dellgw ipsec__plutorun: restarting IPsec after pause...



can you read anything from this?  It seems the algorithms don't match at
the end, but then the names don't bear any relation to aes-256 (for me,
I'm no an encryption guru).

BTW, the ike= parameter in ipsec.conf is not documented in the manpage, 
I had to guess about it after getting an earlier error message.

-- 
A true pessimist won't be discouraged by a little success.