[Openswan Users] openswan startup and version interoperability

Brian Sheets brians at fl240.com
Mon Jul 31 19:57:24 CEST 2006


No, no established on the other side

I get this if I try to ipsec auto --up net-to-net on gateway1

gateway1:~# ipsec auto --up net-to-net
112 "net-to-net" #603: STATE_QUICK_I1: initiate
010 "net-to-net" #603: STATE_QUICK_I1: retransmission; will wait 20s for
response
010 "net-to-net" #603: STATE_QUICK_I1: retransmission; will wait 40s for
response
031 "net-to-net" #603: max number of retransmissions (2) reached
STATE_QUICK_I1.  No acceptable response to our first Quick Mode message:
perhaps peer likes no proposal
000 "net-to-net" #603: starting keying attempt 2 of an unlimited number,
but releasing whack

But I get nothing if I try to command on the other box, it's like it
hangs, but there is logging output 

Anything I can send to the list to help troubleshoot this?

Brian

-----Original Message-----
From: Andy Gay [mailto:andy at andynet.net] 
Sent: Monday, July 31, 2006 8:19 AM
To: Brian Sheets
Cc: users at openswan.org
Subject: RE: [Openswan Users] openswan startup and version
interoperability

On Sat, 2006-07-29 at 09:16 -0700, Brian Sheets wrote:
> And here is the error message on the rightside
> 
> Jul 29 16:05:24 gateway1 pluto[13029]: "net-to-net" #8: transition
from
> state STATE_MAIN_R2 to state STATE_MAIN_R3
> Jul 29 16:05:24 gateway1 pluto[13029]: "net-to-net" #8: sent MR3,
ISAKMP
> SA established

Interesting. That side thinks phase 1 is complete. Do you get "ISAKMP SA
established" on the other side as well?

> Jul 29 16:05:25 gateway1 pluto[13029]: "net-to-net" #8: next payload
> type of ISAKMP Hash Payload has an unknown value: 198
> Jul 29 16:05:25 gateway1 pluto[13029]: "net-to-net" #8: malformed
> payload in packet
> Jul 29 16:05:25 gateway1 pluto[13029]: "net-to-net" #8: sending
> encrypted notification PAYLOAD_MALFORMED to xx.xx.xx.xx
> Jul 29 16:05:25 gateway1 pluto[13029]: "net-to-net" #8: Informational
> Exchange message must be encrypted

Seems the phase 2 session keys aren't getting generated properly.
Usually implies something doesn't match between the 2 configs. But IIRC
you said you have an identical config on each system...

A couple of thoughts - 
Are you sure you're using the correct public keys? Make sure your
ipsec.secrets doesn't have multiple entries that could match. What are
the 2 ends showing for the other end's identity (look for the log entry
reading "Peer ID is ...". Or better, post all the logs from both sides).

I use certificates for almost all my tunnels, but I do have a few
working with raw RSA keys. Here's a config that's working for me, if you
want to compare:

conn ToThem
	left=%defaultroute
	leftsubnet=<mynet>/24
	right=<their IP address>
	rightsubnet=<theirnet>/24
 	rightrsasigkey=0sAQOipa027kvlXU+lQ/GvNCHghcZ.....
	pfs=yes
	compress=no

In ipsec.secrets I just have:

<my IP address> : RSA {
        # RSA 2192 bits   me   Mon Dec 20 20:11:07 2004
        # for signatures only, UNSAFE FOR ENCRYPTION
        #pubkey=0sAQORRWd1QO031JQEK55QfcJEKxmWA....
..
..
	}

The other end has that pubkey as the peer rsasigkey, of course.
Notice I don't specify my RSA public key, it'll find that in
ipsec.secrets, and I don't specify identities, so it'll default to IP
address. I doubt that matters, but you could try simplifying your
configs like mine to see if anything changes.


> 
> 
> -----Original Message-----
> From: Andy Gay [mailto:andy at andynet.net] 
> Sent: Sunday, July 23, 2006 11:07 PM
> To: Brian Sheets
> Cc: users at openswan.org
> Subject: RE: [Openswan Users] openswan startup and version
> interoperability
> 
> On Sun, 2006-07-23 at 22:53 -0700, Brian Sheets wrote:
> > What level of debug to get the info I need to troubleshoot?
> 
> None. Debug is for developers looking for bugs in the code. It fills
> your logs with huge amounts of stuff that's not relevant. Slows
> everything to a crawl as well. If your problems are bad enough the
> developers may ask you to enable some debugging, but I've never seen
> that happen.
> Turning debug off does NOT stop normal logging of connection events.
> 
> > 
> > Brian
> > 
> > -----Original Message-----
> > From: Andy Gay [mailto:andy at andynet.net] 
> > Sent: Sunday, July 23, 2006 7:29 PM
> > To: Brian Sheets
> > Cc: users at openswan.org
> > Subject: Re: [Openswan Users] openswan startup and version
> > interoperability
> > 
> > On Sun, 2006-07-23 at 18:09 -0700, Brian Sheets wrote:
> > >  Debian linux, kernel vmlinuz-2.6.15-1-686, openswan version
> > > 1:2.4.5+dfsg-
> > >  0.2
> > >  
> > >  Trying to connect to openswan 2.2.0
> > >  
> > >  Config on both sides
> > >  
> > >  version 2.0     # conforms to second version of ipsec.conf
> > > specification
> > >  
> > >  config setup
> > >          plutodebug=all
> > 
> > Bad idea. Comment this out please.
> > 
> > >          interfaces=%defaultroute
> > >  
> > > 
> > >
> >
>
virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:
> > >  !10.0.0.0/24
> > >  
> > >  conn net-to-net
> > >      left=207.7.xx.xx
> > >      leftsubnet=10.1.0.0/16
> > >      leftid=@l3-gateway1.xx.net       #
> > >      leftrsasigkey=<the really long key>
> > >      leftnexthop=%defaultroute      # correct in many situations
> > >      right=198.172.xx.xx
> > >      rightsubnet=10.200.0.0/16
> > >      rightid=@gateway1.xx.net
> > >      rightrsasigkey=<the other really long key>
> > >      rightnexthop=%defaultroute     # correct in many situations
> > >      auto=add                       # authorizes but doesn't start
> > this
> > >                                     # connection at startup
> > >  # Add connections here
> > >  
> > >  #Disable Opportunistic Encryption
> > >  include /etc/ipsec.d/examples/no_oe.conf
> > > 
> > >  
> > >  startup on the 2.6.15 kernal box gives me
> > >  
> > >  l3-gateway1:/etc/init.d# sh ./ipsec restart
> > >  ipsec_setup: Stopping Openswan IPsec...
> > >  ipsec_setup: Starting Openswan IPsec 2.4.5...
> > >  ipsec_setup: insmod
> > /lib/modules/2.6.15-1-686/kernel/net/key/af_key.ko
> > >  ipsec_setup: insmod /lib/modules/2.6.15-1-
> > >  686/kernel/net/ipv4/xfrm4_tunnel.ko
> > >  ipsec_setup: insmod
> > > /lib/modules/2.6.15-1-686/kernel/net/xfrm/xfrm_user.ko
> > >  ipsec_setup: insmod /lib/modules/2.6.15-1-
> > >  686/kernel/drivers/char/hw_random.ko
> > >  ipsec_setup: FATAL: Error inserting hw_random
> (/lib/modules/2.6.15-1-
> > >  686/kernel/drivers/char/hw_random.ko): No such device
> > >  ipsec_setup: insmod /lib/modules/2.6.15-1-
> > >  686/kernel/drivers/crypto/padlock.ko
> > >  ipsec_setup: FATAL: Error inserting padlock
(/lib/modules/2.6.15-1-
> > >  686/kernel/drivers/crypto/padlock.ko): No such device
> > >  
> > >  In addition, ipsec auto --up net-to-net hangs from the command
> line,
> > > but
> > >  on the other, openswan 2.2 system, there is an attempt to make a
> > >  connection in the logs
> > >  
> > >  So, my question, are the errors bad?
> > No. Just means you don't have a hardware RNG or the padlock device.
> > 
> > >  What could be causing it to hang?
> > No idea. You'll need to post logs. PLEASE turn off plutodebug=all
> first!
> > 
> > >  
> > >  Thanks
> > >  
> > >  Brian
> > > 
> > > _______________________________________________
> > > Users at openswan.org
> > > http://lists.openswan.org/mailman/listinfo/users
> > > Building and Integrating Virtual Private Networks with Openswan:
> > >
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n(3155
> > 
> > 
> > 
> > 
> 
> 
> 




More information about the Users mailing list