[Openswan Users] openSWAN to Cisco IOS
John Serink
jserink2004 at yahoo.com
Wed Aug 23 13:39:09 EDT 2006
Comments below:
--- Andy Gay <andy at andynet.net> wrote:
> On Tue, 2006-08-22 at 17:02 -0400, Glenn Henshaw wrote:
> > On 22-Aug-06, at 12:22 PM, Andy Gay wrote:
> >
> > > On Tue, 2006-08-22 at 11:53 -0400, Glenn Henshaw wrote:
> > >> Having resolved some of the protocol incompatibilities, I can now
> > >> get the connection to progress past the key exchange. It stops before
> > >> bringing up the tunnel declaring "NO_PROPOSAL_CHOSEN". The Cisco end
> > >> thinks that the tunnel is up until the keep-alive expires.
> > >>
> > >> What can cause the "NO_PROPOSAL_CHOSEN" message from the Cisco?
> > >>
> > > The 2 ends can't agree on phase2 parameters. Everything has to match -
> > > left/right subnets, encryption/authentication algorithms, PFS,
> > > probably
> > > more...
> >
> > I walked through this with the Cisco tech at the other end, There
> > aren't any explicit failure logs pointing to a mismatch. There were
> > some before the encryption was matched up.
> >
> > The status on the Cisco does tentatively show the link as up for a
> > while.
> >
> > cisco#sh cryp isa sa
> > dst src state conn-id slot status
> > xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy QM_IDLE 231 0 ACTIVE
>
> That's the phase 1 SA. We know that's OK, you get ISAKMP SA established
> in your logs.
>
> You won't get any output from a 'show crypto ipsec sa', though.
>
> >
> >
> > >
> > > I don't think you're showing us enough of the cisco config. Shouldn't
> > > there be a crypto map that references the dynamic map? That's how it
> > > works on a PIX, maybe IOS is different.
> > >
> > > I'm guessing you probably need an ACL in the cisco which matches your
> > > left/rightsubnets, that needs to be referenced in the crypto map
> > > (something like "crypto map xx match address <acl>").
> >
> > This is a roadwarrior setup so the PSK is set up to match any host
> > like:
> >
> > crypto keyring QP_Spokes
> > pre-shared-key address 0.0.0.0 0.0.0.0 key shared_secret
> >
> That's phase 1 stuff again. We know that's OK.
>
> Again, you need a crypto map that references the dynamic map. Those maps
> are combined to determine the phase 2 parameters, which have to match
> your config. I know how to do that for a PIX, John Serink sent you a
> sample IOS config that shows much the same stuff - note the entry:
>
> crypto map rtptrans 10 ipsec-isakmp dynamic rtpmap
>
> But his config seems to be missing a 'match address' entry in the
> dynamic map, which is where the left/right subnets would be determined
> if it was a PIX. John - how does your config cover that?
Ok, now follow me here because I'm not entirely sure WHY this worked...
When using a single road warrier connection, I had the 'match address' ACL in
there but I couldn't figure out how to do that with multiple road warriers,
each one with its own subnet behind it....so I just dumped the 'match address'
entry and much to my amazement, it all just worked WITHOUT the 'match address'
command. The Cisco got all the correct subnet info and encrypted all the
correct packets perfectly! Why? Not sure, according to all of the Cisco
examples I have, this should not have worked, but having said that, Cisco
documentation always assumes Cisco to Cisco connections. My Guess as to why
this worked is that Openswan provides the subnet information to Cisco and this
is what made it go. It was essential however to have the ACL to tell the Cisco
which addresses not to NAT out the default route. And you absolutely MUST sort
out all the of the masq issues at the other side.
Trouble shooting this is a matter of doing this:
1. Cisco side debug cypto isakmp and on the Linux side tail -f
/var/log/auth.log and make sure the tunnels come up in both directions,
2. Once you have 1, turn off the crypto debug on the cisco and debug ip icmp
and on the Linux side tcpdump -i "your internetfacing interface" and do a tail
-f /var/log/syslog. WHat you're are looking for here is what is happening when
you ping from the linux box to the cisco. You "should" see the ping leave the
linux box as an ESP packet, arrive at the cisco and see the response from the
debug ip icmp. Now, you should see the ESP packet come back to the linux box on
the tcpdump output. If you get this far, your Cisco config is mostly fine, the
problem is on the Linux side. Your pings aren't getting through you likely have
one or a combination of the following 2 issues:
A. Your Cisco is NATing the outgoing ESP,
B. Your firewall rules on the Linux box are dropping the ESP packets or the
decrypted ICMP.
Once you've got that all sorted, you should be up and away.
Since you're using the KLIPS stack, you can also do a tcpdump -i ipsecX to
check what gets through.
>
> > The Cisco also allows access to 10.0.0.0/8 (but I can't find that
> > in the section of the config I have).
> >
> >
> > >
> > > Debug logs from the cisco will help. And your openswan logs will be
> > > much
> > > easier to read if you set plutodebug="none"....
> >
> > I can't get these as it's a commercial provider managing someone
> > elses network. I can ask questions though.
> >
> > ... Glenn
> >
> >
> > >
> > >>
> > >> ... Glenn
> > >>
> > >>
> > >> openSWAN config:
> > >> version 2.0
> > >> config setup
> > >> interfaces=%defaultroute
> > >> klipsdebug="none"
> > >> plutodebug="control"
> > >> nat_traversal=yes
> > >>
> > >> conn host
> > >> # host specific configuration
> > >> esp=3des-sha1-1024
> > >> ike=3des-sha1-1024
> > >> pfs=no
> > >> keyexchange=ike
> > >> # basic configuration
> > >> type=tunnel
> > >> left=%defaultroute
> > >> leftnexthop=%defaultroute
> > >> leftid=@xxxxxxxxx
> > >> right=xxx.xxx.xxx.xxx
> > >> rightsubnet=10.0.0.0/8
> > >> authby=secret
> > >> auto=start
> > >>
> > >> #disable opportunistic encryption
> > >> include /etc/config/ipsec.d/examples/no_oe.conf
> > >>
> > >> Cisco Config: (abbreviated)
> > >> crypto isakmp policy 10
> > >> encr 3des
> > >> authentication pre-share
> > >> group 2
> > >> crypto isakmp nat keepalive 30
> > >> crypto isakmp client configuration address-pool local xxxxxxxxxxxx
> > >> !
> > >> crypto isakmp profile L2L
> > >> keyring QP_Spokes
> > >> match identity address 0.0.0.0
> > >> !
> > >> crypto ipsec transform-set QP_Set esp-3des esp-sha-hmac
> > >> !
> > >> crypto dynamic-map xxxxxxxxxxx 40
> > >> set transform-set QP_Set
> > >> set isakmp-profile L2L
> > >> !
> > >>
> > >>
> > >>
> > >> openSWAN startup:
> > >> # ipsec auto --up host
> > >> 104 "host" #3: STATE_MAIN_I1: initiate
> > >> 003 "host" #3: received Vendor ID payload [draft-ietf-ipsec-nat-t-
> > >> ike-03] method set to=108
> > >> 106 "host" #3: STATE_MAIN_I2: sent MI2, expecting MR2
> > >> 003 "host" #3: received Vendor ID payload [Cisco-Unity]
> > >> 003 "host" #3: received Vendor ID payload [Dead Peer Detection]
> > >> 003 "host" #3: ignoring unknown Vendor ID payload
> > >> [0c447920daaa628dce64a39fb745f11d]
> > >> 003 "host" #3: received Vendor ID payload [XAUTH]
> > >> 003 "host" #3: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-
> > >> ike-02/03: i am NATed
> > >> 108 "host" #3: STATE_MAIN_I3: sent MI3, expecting MR3
> > >> 004 "host" #3: STATE_MAIN_I4: ISAKMP SA established
> > >> {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
> > >> group=modp1024}
> > >> 117 "host" #4: STATE_QUICK_I1: initiate
> > >> 010 "host" #4: STATE_QUICK_I1: retransmission; will wait 20s for
> > >> response
> > >> 010 "host" #4: STATE_QUICK_I1: retransmission; will wait 40s for
> > >> response
> > >> 031 "host" #4: max number of retransmissions (2) reached
> > >> STATE_QUICK_I1. No acceptable response to our first Quick Mode
> > >> message: perhaps peer likes no proposal000 "host" #4: starting keying
> > >> attempt 2 of an unlimited number, but releasing whack
> > >>
> > >>
> > >> local logs:
> > >> <83>Aug 21 16:53:18.406 2006 ipsec__plutorun: Starting Pluto
> > >> subsystem...
> > >> <84>Aug 21 16:53:18.597 2006 pluto[5458]: Starting Pluto (Openswan
> > >> Version 2.4.5rc6 X.509-1.5.4 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR;
> > >> Vendor ID OESTg[~pX at __)
> > >> <84>Aug 21 16:53:18.599 2006 pluto[5458]: Setting NAT-Traversal
> > >> port-4500 floating to on
> > >> <84>Aug 21 16:53:18.600 2006 pluto[5458]: port floating activation
> > >> criteria nat_t=1/port_fload=1
> > >> <84>Aug 21 16:53:18.602 2006 pluto[5458]: including NAT-Traversal
> > >> patch (Version 0.6c)
> > >> <87>Aug 21 16:53:18.603 2006 pluto[5458]: | opening /dev/urandom
> > >> <87>Aug 21 16:53:18.613 2006 pluto[5458]: | inserting event
> > >> EVENT_REINIT_SECRET, timeout in 3600 seconds
> > >> <87>Aug 21 16:53:18.633 2006 pluto[5458]: | inserting event
> > >> EVENT_PENDING_PHASE2, timeout in 120 seconds
> > >> <84>Aug 21 16:53:18.639 2006 pluto[5458]: ike_alg_register_enc():
> > >> Activating OAKLEY_AES_CBC: Ok (ret=0)
> > >> <84>Aug 21 16:53:18.641 2006 pluto[5458]: starting up 1 cryptographic
> > >> helpers
> > >> <87>Aug 21 16:53:18.655 2006 pluto[5461]: | opening /dev/urandom
> > >> <84>Aug 21 16:53:18.657 2006 pluto[5458]: started helper pid=5461
> > >> (fd:5)
> > >> <84>Aug 21 16:53:18.660 2006 pluto[5458]: Using KLIPS IPsec interface
> > >> code on 2.4.27-uc1
> > >> <87>Aug 21 16:53:18.664 2006 pluto[5458]: | inserting event
> > >> EVENT_SHUNT_SCAN, timeout in 120 seconds
> > >> <87>Aug 21 16:53:18.673 2006 pluto[5461]: ! helper 0 waiting on fd: 7
> > >> <84>Aug 21 16:53:18.701 2006 pluto[5458]: Changing to directory '/
> > >> etc/
> > >> config/ipsec.d/cacerts'
> > >> <84>Aug 21 16:53:18.749 2006 pluto[5458]: Changing to directory '/
> > >> etc/
> > >> config/ipsec.d/aacerts'
> > >> <84>Aug 21 16:53:18.751 2006 pluto[5458]: Changing to directory '/
> > >> etc/
> > >> config/ipsec.d/ocspcerts'
> > >> <84>Aug 21 16:53:18.753 2006 pluto[5458]: Changing to directory '/
> > >> etc/
> > >> config/ipsec.d/crls'
> > >> <84>Aug 21 16:53:18.755 2006 pluto[5458]: Warning: empty directory
> > >> <87>Aug 21 16:53:18.757 2006 pluto[5458]: | inserting event
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
More information about the Users
mailing list