[Openswan Users] Openswan to Cisco using Cisco isakmp profiles
John Serink
jserink2004 at yahoo.com
Fri Jan 25 00:17:03 EST 2008
Hi Peter:
Thank you for the email.
Will go through this bit by bit:
--- Peter McGill <petermcgill at goco.net> wrote:
> Not sure if it is still the case, but last I knew pfsgroup
> on openswan was broken. Just remove that line in your conf,
> and openswan will use the same group for phase 2 as it did
> in phase 1, which is what you want anyway.
It behaves the same whether PFSgroup is there or not.
> I've never used a cisco, but I notice in the config it has
> pool ippool. Note that openswan doesn't accept/use virtual
> ip addresses from remote servers or hand them out itself.
> So if that's what pool ippool is for then that won't work.
Ok, a bit of explaining here.
There are 2 ISAKMP profiles, 1 using Xauth, that is the one with the ippool and
the one without Xauth, no ippool. The Xauth one is for the Cisco VPN client to
connect to the router from windows or linux boxes. The other profile is the one
I am connecting to or want to connect to.
I thought that leftmodecfgserver would allow openswan to accept server config
stuff form the other side? That's not what I'm trying to do here though.
> Also I don't see anywhere on the cisco config where you set
> your openswan subnet 192.168.3.0/24, the cisco will need to
> know about this to accept/match phase 2 connection info, this
> is a universal ipsec thing. This among other things would
> also cause the error message your seeing. (No proposal chosen)
That is the thning....
If I take out the multiple ISAKMP profiles and have a single ISAKMP profile for
all connections(using the cisco as a hub with openswan spokes), then the Cisco
vpn client doesn't work of course, BUT, I can connect with as many openswan
clients as I want, WITHOUT having the cisco access list in place to tell the
router what traffic to encrypt and it works! When I do a show crypto ipsec
peers it shows all the correct destination networks etc. My only guess on WHY
this works is that the Cisco must pick the information up from Openswan during
the negotiation. Its one of those situations where it works but I'm not sure
why. Of course, I can't ping from spoke to spoke but I solved that but bringing
up GRE tunnels inside the IPSec tunnels and installing static routes in the
cisco and it works great. The biggest headache I had was getting the access
list right to tell the Cisco not to NAT the IPSec traffic.
I was just trying to duplicate that using ISAKMP profiles so that I could have
the VPN client functionality. Looks like it might not be possible.
Thank you very much for having a look at it Peter.
Cheers,
john
>
> Peter McGill
>
>
> > -----Original Message-----
> > From: users-bounces at openswan.org
> > [mailto:users-bounces at openswan.org] On Behalf Of John Serink
> > Sent: January 16, 2008 11:36 AM
> > To: users at openswan.org
> > Subject: [Openswan Users] Openswan to Cisco using Cisco
> > isakmp profiles
> >
> > Hi All:
> >
> > Here is my openswan version:
> > jerinkturion ipsec # ipsec --version
> > Linux Openswan U2.4.9/K2.6.20-gentoo-r7 (netkey)
> >
> > Cisco:
> > Cisco IOS Software, C1700 Software (C1700-K9O3SY7-M), Version
> > 12.4(17), RELEASE
> > SOFTWARE (fc1)
> > Technical Support: http://www.cisco.com/techsupport
> > Copyright (c) 1986-2007 by Cisco Systems, Inc.
> > Compiled Fri 07-Sep-07 14:17 by prod_rel_team
> >
> > ROM: System Bootstrap, Version 12.2(7r)XM2, RELEASE SOFTWARE (fc1)
> >
> > SingaporeiLab uptime is 5 weeks, 5 days, 9 hours, 31 minutes
> > System returned to ROM by reload
> > System image file is "flash:c1700-k9o3sy7-mz.124-17.bin"
> >
> > Here is my ipsec.conf file:
> > # This file: /usr/share/doc/openswan-2.4.9/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 plutodebug=all or 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,%v4:172.16.0.0/12
> > #
> > # enable this if you see "failed to find any available worker"
> > nhelpers=0
> > klipsdebug=none
> > plutodebug=none
> > interfaces=%defaultroute
> > uniqueids=yes
> >
> > # Add connections here
> >
> > conn singaporeiLab
> > authby=secret
> > auto=add
> > left=%defaultroute
> > leftid=@jserinkturion
> > leftsubnet=192.168.3.0/24
> > leftsourceip=192.168.3.1
> > ike=aes128-md5-modp1024
> > esp=aes128-md5
> > right=203.125.87.10
> > rightsubnet=192.168.1.0/24
> > rightsourceip=192.168.1.1
> > type=tunnel
> > pfs=yes
> > pfsgroup=modp1024
> > keyingtries=0
> >
> > # sample VPN connections, see /etc/ipsec.d/examples/
> >
> > #Disable Opportunistic Encryption
> > include /etc/ipsec/ipsec.d/examples/no_oe.conf
> >
> > Here is the pluto output:
> > jerinkturion ipsec # ipsec auto --up singaporeiLab
> > 104 "singaporeiLab" #1: STATE_MAIN_I1: initiate
> > 003 "singaporeiLab" #1: received Vendor ID payload
> > [draft-ietf-ipsec-nat-t-ike-03] method set to=108
> > 106 "singaporeiLab" #1: STATE_MAIN_I2: sent MI2, expecting MR2
> > 003 "singaporeiLab" #1: received Vendor ID payload [Cisco-Unity]
> > 003 "singaporeiLab" #1: received Vendor ID payload [Dead Peer
> > Detection]
> > 003 "singaporeiLab" #1: ignoring unknown Vendor ID payload
> > [4cdc21dd0e9ceb73db611297d2d8a2ac]
> > 003 "singaporeiLab" #1: received Vendor ID payload [XAUTH]
> > 003 "singaporeiLab" #1: NAT-Traversal: Result using
> > draft-ietf-ipsec-nat-t-ike-02/03: i am NATed
> > 108 "singaporeiLab" #1: STATE_MAIN_I3: sent MI3, expecting MR3
> > 004 "singaporeiLab" #1: STATE_MAIN_I4: ISAKMP SA established
> > {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_md5
> > group=modp1024}
> > 117 "singaporeiLab" #2: STATE_QUICK_I1: initiate
> > 010 "singaporeiLab" #2: STATE_QUICK_I1: retransmission; will
> > wait 20s for
> > response
> > 010 "singaporeiLab" #2: STATE_QUICK_I1: retransmission; will
> > wait 40s for
> > response
> > 031 "singaporeiLab" #2: max number of retransmissions (2) reached
> > STATE_QUICK_I1. No acceptable response to our first Quick
> > Mode message:
> > perhaps peer likes no proposal
> > 000 "singaporeiLab" #2: starting keying attempt 2 of an
> > unlimited number, but
> > releasing whack
> >
> >
> > So, the phase 1 is up, I can see that on the Cisco as well.
> > Here is the debug
> > from the Cisco:
> >
> > SingaporeiLab#show debug
> > Cryptographic Subsystem:
> > Crypto ISAKMP debugging is on
> > Crypto ISAKMP Error debugging is on
> > Crypto ISAKMP High Availability debugging is on
> >
> > *Jun 9 15:19:06.647: ISAKMP:(0:1:SW:1):purging node -14721836
> > SingaporeiLab#
> > *Jun 9 15:19:26.759: ISAKMP (0:134217729): received packet
> > from 203.127.153.65
> > dport 4500 sport 4500 Global (R) QM_IDLE
> > *Jun 9 15:19:26.759: ISAKMP: set new node 1678256259 to QM_IDLE
> > *Jun 9 15:19:26.763: ISAKMP:(0:1:SW:1): processing HASH
> > payload. message ID =
> > 1678256259
> > *Jun 9 15:19:26.763: ISAKMP:(0:1:SW:1): processing SA
> > payload. message ID =
> > 1678256259
> > *Jun 9 15:19:26.763: ISAKMP:(0:1:SW:1):Checking IPSec proposal 0
> > *Jun 9 15:19:26.763: ISAKMP: transform 0, ESP_AES
> > *Jun 9 15:19:26.763: ISAKMP: attributes in transform:
> > *Jun 9 15:19:26.763: ISAKMP: group is 2
> > *Jun 9 15:19:26.763: ISAKMP: encaps is 61443 (Tunnel-UDP)
> > *Jun 9 15:19:26.763: ISAKMP: SA life type in seconds
> > *Jun 9 15:19:26.767: ISAKMP: SA life duration (basic) of 28800
> > *Jun 9 15:19:26.767: ISAKMP: authenticator is HMAC-MD5
> > *Jun 9 15:19:26.767: ISAKMP: key length is 128
> > *Jun 9 15:19:26.767: ISAKMP:(0:1:SW:1):atts are acceptable.
> > *Jun 9 15:19:26.771: ISAKMP:(0:1:SW:1): IPSec policy
> > invalidated proposal
> > *Jun 9 15:19:26.771: ISAKMP:(0:1:SW:1): phase 2 SA policy
> > not acceptable!
> > (local 203.125.87.10 remote 203.127.153.65)
> > *Jun 9 15:19:26.771: ISAKMP: set new node -520296930 to QM_IDLE
> > *Jun 9 15:19:26.771: ISAKMP:(0:1:SW:1):Sending NOTIFY
> > PROPOSAL_NOT_CHOSEN
> > protocol 3
> > spi 2197619712, message ID = -520296930
> > *Jun 9 15:19:26.775: ISAKMP:(0:1:SW:1): sending packet to
> > 203.127.153.65
> > my_port 4500 peer_port 4500 (R) QM_IDLE
> > *Jun 9 15:19:26.775: ISAKMP:(0:1:SW:1):purging node -520296930
> > *Jun 9 15:19:26.775: ISAKMP:(0:1:SW:1):deleting node
> > 1678256259 error TRUE
> > reason "QM rejected"
> > *Jun 9 15:19:26.779: ISAKMP (0:134217729): Unknown Input
> > IKE_MESG_FROM_PEER,
> > IKE_QM_EXCH: for node 1678256259: state = IKE_QM_READY
> > *Jun 9 15:19:26.779: ISAKMP:(0:1:SW:1):Node 1678256259, Input =
> > IKE_MESG_FROM_PEER, IKE_QM_EXCH
> > *Jun 9 15:19:26.779: ISAKMP:(0:1:SW:1):Old State =
> > IKE_QM_READY New State =
> > IKE_QM_READY
> > *Jun 9 15:19:26.779: %CRYPTO-6-IKMP_MODE_FAILURE: Processing
> > of Quick mode
> > failed with peer at 203.127.153.65
> > *Jun 9 15:19:35.907: ISAKMP (0:134217729): received packet
> > from 203.127.153.65
> > dport 4500 sport 4500 Global (R) QM_IDLE
>
=== message truncated ===
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
More information about the Users
mailing list