[Openswan Users] auth=ah broken on 2.4.12 release?

[austinxxh-ipsec at yahoo.com]

Yes "ah=hmac-md5-96" can work however it's still using "auth=esp" as the default mode per my understanding.

the problem is that "auth=ah" did not work, i thought "auth=ah" means "AH-only, no-ESP" however when "auth=ah" was used, "ipsec spi" shows both AH and ESP, and it only allows uni-directional traffic.

So my problem stays the same, "auth=ah" did not work, more strangely "auth=ah" will show AH+ESP instead of AH-only. I'm not sure if we can set up an AH-only(no ESP) mode using openswan-2.4.12 at all, I did use OCF with our hardware security engine and it worked well under "auth=esp", with or without "ah=" and "esp=".

thanks,
xiao


--- On Thu, 9/4/08, David McCullough <David_Mccullough at securecomputing.com> wrote:

> From: David McCullough <David_Mccullough at securecomputing.com>
> Subject: Re: [Openswan Users] auth=ah broken on 2.4.12 release?
> To: austinxxh-ipsec at yahoo.com
> Cc: users at openswan.org
> Date: Thursday, September 4, 2008, 7:52 PM
> Jivin austinxxh-ipsec at yahoo.com lays it down ...
> > When I use "auth=ah", "ipsec spi"
> will show both ESP and AH, while I am expecting an AH-only.
> The tunnel is up but not bi-directional. A message here :
> http://osdir.com/ml/network.openswan.devel/2007-05/msg00001.html
> says it's expected, I don't really know why.
> > 
> > If I replaced "auth=ah" with
> "auth=esp(default)", then adding
> "esp=3des-sha1", I only saw ESP, then adding one
> more line as "ah=hmac-md5-96", then I saw AH as
> well. In general I feel "auth=esp" works well.
> However I do not really know what "auth=ah" does
> in openswan and if it indeed works.
> > 
> > I will try manual to see if "auth=ah" works
> at all.
> 
> 
> Here is a config I used to test AH on an older 2.4 Openswan
> release
> using OCF.
> 
> 	version 2
> 	config setup
> 			interfaces = "ipsec0=eth3"
> 			klipsdebug = none
> 			plutodebug = none
> 			manualstart = test
> 			uniqueids = yes
> 
> 	conn test
> 			type = tunnel
> 			leftsubnet = 192.168.0.0/24
> 			left = 10.31.1.2
> 			right = 10.31.1.1
> 			spi = 0x101
> 			ahkey = 0x4a923631_4d4b2a73_11b4fb88_633d40d9
> 			ah = hmac-md5-96
> 
> Hope that helps,
> 
> Cheers,
> Davidm
> 	
> > --- On Thu, 9/4/08, Paul Wouters
> <paul at xelerance.com> wrote:
> > 
> > > From: Paul Wouters <paul at xelerance.com>
> > > Subject: Re: [Openswan Users] auth=ah broken on
> 2.4.12 release?
> > > To: austinxxh-ipsec at yahoo.com
> > > Cc: dev at openswan.org
> > > Date: Thursday, September 4, 2008, 12:14 PM
> > > On Wed, 3 Sep 2008, austinxxh-ipsec at yahoo.com
> wrote:
> > > 
> > > > If I switch "auth=esp" to
> > > "auth=ah" in ipsec.conf, all other
> settings stay
> > > the same, the AH+ESP tunnel is set up correctly,
> however,
> > > when I ping from PC1 to PC2, I can only observe
> "ICMP
> > > request" from PC1 all the way to
> RIGHT_GATEWAY when I
> > > run "tcpdump -i eth0" on LEFT_GATEWAY
> and
> > > RIGHT_GATEWAY, there is never an "ICMP
> reply" was
> > > seen on the wire.
> > > 
> > > Note that "AH+ESP" is ambiguous. ESP
> contains
> > > some AH-like constructs, but "AH+ESP"
> (something
> > > you can mistakenly
> > > configure with racoon/ipsec-tools) is something
> you should
> > > never do.
> > > 
> > > > Considering "auth=esp" works fine,
> and the
> > > only change I made is to change "esp"
> to
> > > "ah", does that mean
> "auth=ah" mode is
> > > not working under 2.4.12 release?
> > > 
> > > I guess that might be the case. I think there is
> some open
> > > bug report on ah not working with auto= and only
> > > with manual=.
> > > 
> > > Paul
> > _______________________________________________
> > 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=283155
> > 
> 
> -- 
> David McCullough,  david_mccullough at securecomputing.com,  
> Ph:+61 734352815
> Secure Computing - SnapGear  http://www.uCdot.org  
> http://www.snapgear.com