[Openswan Users] Routing Problem?

Thu Jun 26 15:01:24 EDT 2008

Bert,

You can also change your ike line to match their DH Group specifically.
	ike=3des-md5;modp1024
However leave esp as is (esp=3des-md5).

Also note that your rightsubnet line is wrong.
	rightsubnet=192.4.223.0/32
Should probably instead be:
	rightsubnet=192.4.223.0/24

If after restarting with that configuration, the NO_PROPOSAL_CHOSEN continues,
then try the following additions to the cisco config.

I've never used Cisco myself but from the instructions at:
http://wiki.openswan.org/index.php/Openswan/CiscoPIX

I would say that the following needs to be added to cisco: no-xauth no-config-mode
Like so...
crypto isakmp key ******** address 209.98.199.133 no-xauth no-config-mode

no-config-mode is a must since it is for cisco only.
no-xauth is easiest as openswan doesn't use it by default.

If the remote admin insists on using xauth then you'll need to lookup instructions
for using xauth with openswan. I've never used it personally though.

The cisco should also have:
access-list bert permit ip 192.4.223.0 255.255.255.0 209.98.199.133 255.255.255.255
crypto map vpnmap 10 match address bert

If the NO_PROPOSAL_CHOSEN continues have the cisco admin check the above uri for instructions.

Peter McGill
IT Systems Analyst
Gra Ham Energy Limited 

> -----Original Message-----
> From: Bert Olsson [mailto:bso at bertolsson.com] 
> Sent: June 26, 2008 2:33 PM
> To: petermcgill at goco.net
> Subject: RE: [Openswan Users] Routing Problem?
> 
> 
> Peter:
> 
> It seems to be some type of Cisco on the other side.
> Here is what we were given:
> 
> 
> crypto isakmp policy 620
>  encr 3des
>  hash md5
>  authentication pre-share
>  group 2
> 
> crypto isakmp key ******** address 209.98.199.133
> 
> crypto ipsec transform-set encrpt-md5 esp-3des esp-md5-hmac
> 
> crypto map vpnmap 620 ipsec-isakmp
>  set peer 209.98.199.133
>  set transform-set encrpt-md5
> 
> 
> On Thu, 2008-06-26 at 14:13 -0400, Peter McGill wrote:
> > Bert,
> > 
> > You're still getting NO_PROPOSAL_CHOSEN.
> > This indicates a settings mismatch between the two endpoints.
> > Could you provide details on the device make/model and
> > configuration of the remote device, or what settings you were
> > told to use by remote admin.
> > 
> > left/rightsubnets, ike,esp, left/right, left/rightids, pfs
> > all need to match the settings on the other end.
> > 
> > When the tunnel is completed you will see both
> > Main Mode 4 ISAKMP SA established (phase1, this your seeing)
> > (phase1, single encrypted keying channel between endpoints.)
> > Quick Mode 2 IPSec SA established (phase2, this your not seeing)
> > (phase2, actual traffic tunnel, of which there may be multiple,
> > one for each subnet pair.)
> > 
> > Peter McGill
> > IT Systems Analyst
> > Gra Ham Energy Limited 
> > 
> > > -----Original Message-----
> > > From: Bert Olsson [mailto:bso at bertolsson.com] 
> > > Sent: June 26, 2008 1:54 PM
> > > To: petermcgill at goco.net
> > > Subject: RE: [Openswan Users] Routing Problem?
> > > 
> > > Peter:
> > > 
> > > Yep, those were spaces.  It looks like the connection
> > > completes now.  However, I still seem to have the same
> > > problem.  If I ping a machine on the destination subnet
> > > (say, 192.4.223.142), I see no traffic to the remote
> > > VPN address (which I assume would mean the packets are
> > > going through the tunnel).  I do, however, see what I
> > > think are "normal" ICMPs going over the default interface
> > > (the pings are, as expected being rejected by the other side).
> > > 
> > > Here's that tcpdump:
> > > 
> > > tcpdump host 192.4.223.142
> > > tcpdump: verbose output suppressed, use -v or -vv for 
> full protocol
> > > decode
> > > listening on eth0, link-type EN10MB (Ethernet), capture 
> size 96 bytes
> > > 12:45:22.757488 IP ruglyweb1.mn2.visi.com >
> > > bcl2lq01e0.ins.telcordia.com: ICMP echo request, id 38734, seq 10,
> > > length 64
> > > 12:45:23.757197 IP ruglyweb1.mn2.visi.com >
> > > bcl2lq01e0.ins.telcordia.com: ICMP echo request, id 38734, seq 11,
> > > length 64
> > > 12:45:24.756915 IP ruglyweb1.mn2.visi.com >
> > > bcl2lq01e0.ins.telcordia.com: ICMP echo request, id 38734, seq 12,
> > > length 64
> > > 12:45:25.756628 IP ruglyweb1.mn2.visi.com >
> > > bcl2lq01e0.ins.telcordia.com: ICMP echo request, id 38734, seq 13,
> > > length 64
> > > 12:45:26.756339 IP ruglyweb1.mn2.visi.com >
> > > bcl2lq01e0.ins.telcordia.com: ICMP echo request, id 38734, seq 14,
> > > length 64
> > > 12:45:27.756049 IP ruglyweb1.mn2.visi.com >
> > > bcl2lq01e0.ins.telcordia.com: ICMP echo request, id 38734, seq 15,
> > > length 64
> > > 
> > > The new barf output is below.  Thanks so much for your speedy 
> > > response.
> > > 
> > > Bert
> > > 
> > > On Thu, 2008-06-26 at 13:09 -0400, Peter McGill wrote:
> > > > Bert,
> > > > 
> > > > > How does it know how to use the VPN connection for the
> > > > > remote subnet?  Is there supposed to be a network device
> > > > > for VPN (like ipsec0)? I'm clearly missing something, but
> > > > > cannot figure it out.
> > > > The traffic which is from leftsubnet to rightsubnet enters the
> > > > tunnel automatically, you cannot route it manually.
> > > > In your case traffic from 209.98.199.133 to 192.4.223.0/32.
> > > > You only have ipsec0 when using the klips kernel modules, you're
> > > > using the netkey kernel modules so your ipsec uses the internet
> > > > interface, eth0 in your case.
> > > > 
> > > > According to your logs the tunnel is not completed:
> > > > > Jun 26 11:11:32 ruglyweb1 pluto[9542]: "mgi" #4: 
> > > initiating Quick Mode
> > > > > PSK+ENCRYPT+TUNNEL+UP+IKEv2ALLOW to replace #3 {using isakmp#1
> > > > > msgid:dc18ab8c proposal=3DES(3)_192-MD5(1)_128 
> pfsgroup=no-pfs}
> > > > > Jun 26 11:11:32 ruglyweb1 pluto[9542]: "mgi" #1: ignoring 
> > > > > informational
> > > > > payload, type NO_PROPOSAL_CHOSEN msgid=00000000
> > > > > Jun 26 11:11:32 ruglyweb1 pluto[9542]: "mgi" #1: received 
> > > and ignored
> > > > > informational message
> > > > > Jun 26 11:12:42 ruglyweb1 pluto[9542]: "mgi" #4: max number of
> > > > > retransmissions (2) reached STATE_QUICK_I1.  No 
> > > acceptable response to
> > > > > our first Quick Mode message: perhaps peer likes no proposal
> > > > Key error being NO_PROPOSAL_CHOSEN.
> > > > 
> > > > I suspect this is due to the following error in your ipsec.conf:
> > > > >         ike=3des-md5
> > > > >         esp=3des-md5
> > > > While these lines look ok, they are indented with 
> spaces, and should
> > > > properly be indented with a single tab.
> > > > 
> > > > Thank you for the complete barf, makes it easier to diagnose.
> > > > If this doesn't fix your problem, try sending your ping 
> test results
> > > > and the new log output to see if the error has changed.
> > > > 
> > > > Peter McGill
> > > > IT Systems Analyst
> > > > Gra Ham Energy Limited 
> > > > 
> > > > > -----Original Message-----
> > > > > From: users-bounces at openswan.org 
> > > > > [mailto:users-bounces at openswan.org] On Behalf Of Bert Olsson
> > > > > Sent: June 26, 2008 12:28 PM
> > > > > To: users at openswan.org
> > > > > Subject: [Openswan Users] Routing Problem?
> > > > > 
> > > > > I am trying to establish a VPN connection using openswan
> > > > > from an RHEL5 box.  The VPN connection seems to come up
> > > > > just fine, but when I look at ping packets going to the
> > > > > remote subnet, the packets are going over the default
> > > > > interface (i.e., they are not ESP packets over VPN).
> > > > > 
> > > > > How does it know how to use the VPN connection for the
> > > > > remote subnet?  Is there supposed to be a network device
> > > > > for VPN (like ipsec0)? I'm clearly missing something, but
> > > > > cannot figure it out.
> > > > > 
> > > > > Thanks for any help.
> > > > > 
> > > > > Bert Olsson
> > > > > 
> > > > > ipsec --barf output: