[Openswan Users] modecfg supplied IP address and multiple subnets

[Northfield Stuart]

On 15 Mar 2012, at 00:30, Paul Wouters wrote:

> On Wed, 14 Mar 2012, Northfield Stuart wrote:
> 
>> I have successfully configured my linux test environment to connect and authenticate with the pfsense box and all three phase 2 associations are brought up (configured as multiple subnets in a single conn entry in ipsec.conf - see below), but I can only access some of the remote subnets.
>> 
>> I observe (from the pfsense diagnostics) that two of the three SPDs are being defined (at the pfsense end) with the source as the subnet declared at the client end rather than the virtual IP address issued by the gateway via modecfg (which does appear on the third subnet SPD).
> 
> Is there a difference in behaviour in you use three cons with
> rightsubnet= versus one conn with rightsubnets= ?

I had already tried this and it appears to behave the same.

>> Is this right? The iOS/Mac ipsec clients appear to use the modecfg supplied IP address across all three subnet SPDs, which is I think what I would expect - i.e. the linux client should also apply the IP address to all three phase 2 associations.
> 
>> I don't yet have anonymised logging, but the client end configuration included below (in case I have missed something obvious - have been trying to resolve this for a couple of days now).
> 
> It would be useful to get a plutodebug=all log if possible (without the
> leftsubnet/leftsourceips specified.. you can send it to me off-list,
> but try to do the least anonymising.


Interestingly, if I remove both then no connection is established at all (not sure what's going on there). The log I am supplying had a leftsubnet defined, but no leftsourceip - will supply log privately, but here is my take on what is happening:

When openswan starts, it instigates three phase 2 associations (metanate/0x1,metanate/0x2,metanate/0x3), one per subnet.

All three phase 2 associations are placed in pending state, and metanate/0x3 is used to bring up the phase 1 association.

During XAuth/modecfg, the client address and source IP address of metanate/0x3 are set to the modecfg supplied value.

Having completed phase 1, the three phase 2 associations are kicked off.

On completion, metanate/0x1 and metanate/0x2 are using the leftsubnet value from the configuration, but metanate/0x3 is using the modecfg supplied address.

I took some time to study the code, and I think that when the unpend() function in programs/pluto/pending.c is called from programs/pluto/xauth.c at the end of phase 1, it needs to copy the client and source IP addresses from the connection it has been passed (i.e. the one which has been used to established phase 1) to all of the connections it is now 'unpending' (i.e. all of the phase 2 associations waiting on this phase 1 association). I attach a simple patch which I tried as an experiment and for my configuration this then works as expected (as long as there is no leftsourceip defined anyway). 

(NB this patch does the minumum required and I'm sure needs polish, and probably to take other flags into account, before being incorporated into the source base - but it is enough to prove the concept. At the very least it should probably detect when the source and destination connection pointers are the same.)

Does this seem the right way to go?

Regards

Stu

diff -aur openswan-2.6.37/programs/pluto/pending.c openswan-2.6.37-sjn/programs/pluto/pending.c
--- openswan-2.6.37/programs/pluto/pending.c	2011-10-28 22:11:53.000000000 +0100
+++ openswan-2.6.37-sjn/programs/pluto/pending.c	2012-03-14 19:08:45.000000000 +0000
@@ -187,6 +187,25 @@
     {
 	if (p->isakmp_sa == st)
 	{
+	  if (st->st_connection->spd.this.has_client)
+	  {
+	    char caddr[SUBNETTOT_BUF];
+
+	    memcpy(&p->connection->spd.this.client,
+		   &st->st_connection->spd.this.client,
+		   sizeof(p->connection->spd.this.client));
+	    subnettot(&p->connection->spd.this.client, 0, caddr, sizeof(caddr));
+	    DBG(DBG_CONTROL, DBG_log("propagating client IP address %s", caddr));
+	    p->connection->spd.this.has_client = TRUE;
+
+	    if(addrbytesptr(&p->connection->spd.this.host_srcip, NULL) == 0
+	       || isanyaddr(&p->connection->spd.this.host_srcip)) {
+	      openswan_log("setting ip source address to %s"
+			   , caddr);
+
+	      p->connection->spd.this.host_srcip = p->connection->spd.this.client.addr;
+	    }
+	  }
 	    DBG(DBG_CONTROL
 		, DBG_log("unqueuing pending Quick Mode with %s \"%s\" %s"
 			  , ip_str(&p->connection->spd.that.host_addr)


--
Stuart Northfield
+44 (0) 1223 566759 (Direct), +44 (0) 1223 566727 (Fax)
Metanate Limited. Registered in England No 4046086 at:
Lincoln House, Station Court, Great Shelford, Cambridge CB22 5NE, UK
www.metanate.com (Consultancy) www.schemus.com (Data synchronisation)

This e-mail and all attachments it may contain is confidential and
intended solely for the use of the individual to whom it is addressed.
Any views or opinions presented are those of the author and do not
necessarily represent those of Metanate Ltd.  If you are not the
intended recipient, be advised that you have received this e-mail in
error and that any use, dissemination, printing, forwarding or copying
of this e-mail is strictly prohibited.  Please contact the sender if
you have received this e-mail in error.