ipsec-tools-devel — Development discussion of IPsec Tools

[Ipsec-tools-devel] ipsec-tools 0.8.1

[Richard K. <kr...@cf...>]

Dear Devs,

I've upgraded my ipsec-tools installation from 0.8.0 to 0.8.1, and found 
that when racoon is the initiator, it sends packets from port 4500 instead 
of 500 as in the previous version. I've not done further investigation, 
but this leads to the connection not establishing.

This is the change between the two versions in src/racoon/isakmp.c:

diff --git a/src/racoon/isakmp.c b/src/racoon/isakmp.c
index 048ca71..2672f7a 100644
--- a/src/racoon/isakmp.c
+++ b/src/racoon/isakmp.c
@@ -1,4 +1,4 @@
-/*     $NetBSD: isakmp.c,v 1.71 2011/03/15 13:20:14 vanhu Exp $        */
+/*     $NetBSD: isakmp.c,v 1.71.2.2 2012/08/29 08:55:26 tteras Exp $   */

  /* Id: isakmp.c,v 1.74 2006/05/07 21:32:59 manubsd Exp */

@@ -2186,7 +2186,7 @@ isakmp_post_acquire(iph2, iph1hint, nopassive)
                         "because of passive mode, "
                         "ignore the acquire message for %s.\n",
                         saddrwop2str(iph2->dst));
-               return 0;
+               return -1;
         }

         /*
@@ -2943,7 +2943,7 @@ copy_ph1addresses(iph1, rmconf, remote, local)
                 port = myaddr_getsport(iph1->local);
                 if (port == 0)
                         port = PORT_ISAKMP;
-               set_port(iph1->local, PORT_ISAKMP);
+               set_port(iph1->local, port);
         }

  #ifdef ENABLE_NATT

The second hunk makes racoon choose the port 4500 instead of 500. But I 
simply dont understand the code deeply, and effectively the diff seems to 
fix something, so in my oppinion it is to be fixed some other way.

Thanks in advance,

Kojedzinszky Richard

Re: [Ipsec-tools-devel] Problem with racoon version 0.8.1

[Timo T. <tim...@ik...>]

On Thu, 21 Nov 2013 16:33:46 +0000
John Williams <joh...@pc...> wrote:

> I'm following the instructions in chapter 7 of the "Linux advanced
> routing and traffic control howto", to set up a TCP connection
> protected by IPsec. Not a VPN, and no NAT involved; just two machines
> on a LAN.
> 
> With ipsec-tools 0.8.0 everything works fine, but with version 0.8.1
> on one of the servers, racoon fails to establish a security
> association, and nothing works.
> 
> I've traced the problem to this change between 0.8.0 and 0.8.1:
> 
> --- ipsec-tools-0.8.0/src/racoon/isakmp.c
> +++ ipsec-tools-0.8.1/src/racoon/isakmp.c
> @@ -2943,7 +2943,7 @@
>  		port = myaddr_getsport(iph1->local);
>  		if (port == 0)
>  			port = PORT_ISAKMP;
> -		set_port(iph1->local, PORT_ISAKMP);
> +		set_port(iph1->local, port);
>  	}
>  
>  #ifdef ENABLE_NATT
> 
> If I reverse this change, it starts working. I notice that
> myaddr_setsport() is returning 4500, whereas PORT_ISAKMP has the value
> 500. Any idea what has gone wrong?
> 
> racoon is compiled with NAT-traversal enabled (I'm using the package
> from Arch Linux), but "nat_traversal" is not turned on in the
> racoon.conf file, which is just as in the "howto" except for the
> obvious change to the IP addresses.

I believe this is fixed already in 0.8-branch. IIRC, the
myaddr_getsport() linux version was return bad values. There's a bunch
of other fixes in 0.8-branch too, so it might be a time to make 0.8.2
soon.

- Timo

[Ipsec-tools-devel] Problem with racoon version 0.8.1

[John W. <joh...@pc...>]

Hello,

I posted this on the ipsec-tools-users list, and they sent me here
instead...

I'm following the instructions in chapter 7 of the "Linux advanced
routing and traffic control howto", to set up a TCP connection
protected by IPsec. Not a VPN, and no NAT involved; just two machines
on a LAN.

With ipsec-tools 0.8.0 everything works fine, but with version 0.8.1
on one of the servers, racoon fails to establish a security
association, and nothing works.

I've traced the problem to this change between 0.8.0 and 0.8.1:

--- ipsec-tools-0.8.0/src/racoon/isakmp.c
+++ ipsec-tools-0.8.1/src/racoon/isakmp.c
@@ -2943,7 +2943,7 @@
 		port = myaddr_getsport(iph1->local);
 		if (port == 0)
 			port = PORT_ISAKMP;
-		set_port(iph1->local, PORT_ISAKMP);
+		set_port(iph1->local, port);
 	}
 
 #ifdef ENABLE_NATT

If I reverse this change, it starts working. I notice that
myaddr_setsport() is returning 4500, whereas PORT_ISAKMP has the value
500. Any idea what has gone wrong?

racoon is compiled with NAT-traversal enabled (I'm using the package
from Arch Linux), but "nat_traversal" is not turned on in the
racoon.conf file, which is just as in the "howto" except for the
obvious change to the IP addresses.

John

[Ipsec-tools-devel] General error events

[Alexander S. <ale...@gm...>]

   Is there any interest in adding error event for racoon management 
interfaces?
Current event list contains no events to indicate errors happening 
during Phase 1 and 2 processing:

#define EVT_RACOON_QUIT            0x0001

#define EVT_PHASE1_UP            0x0100
#define EVT_PHASE1_DOWN            0x0101
#define EVT_PHASE1_NO_RESPONSE        0x0102
#define EVT_PHASE1_NO_PROPOSAL        0x0103
#define EVT_PHASE1_AUTH_FAILED        0x0104
#define EVT_PHASE1_DPD_TIMEOUT        0x0105
#define EVT_PHASE1_PEER_DELETED        0x0106
#define EVT_PHASE1_MODE_CFG        0x0107
#define EVT_PHASE1_XAUTH_SUCCESS    0x0108
#define EVT_PHASE1_XAUTH_FAILED        0x0109

#define EVT_PHASE2_NO_PHASE1        0x0200
#define EVT_PHASE2_UP            0x0201
#define EVT_PHASE2_DOWN            0x0202
#define EVT_PHASE2_NO_RESPONSE        0x0203


For example in case of rsa signature auth and if private key can't be 
read there is no event generation.
Only bunch of debug messages in log:
2013-11-20 12:14:06: ERROR: oakley.c:1808:oakley_getsign(): failed to 
get private key.
2013-11-20 12:14:06: [192.168.100.1] ERROR: isakmp.c:847:ph1_main(): 
failed to process ph1 packet (side: 0, status: 6).
2013-11-20 12:14:06: [192.168.100.1] ERROR: isakmp.c:613:isakmp_main(): 
phase1 negotiation failed.
2013-11-20 12:14:06: DEBUG: isakmp_cfg.c:2071:isakmp_cfg_setenv(): 
Starting a script.
2013-11-20 12:14:06: DEBUG: oakley.c:3023:oakley_delivm(): IV freed

Only errors caused by interaction with peer are reported through events. 
Not even EVT_PHASE1_DOWN.
I am advocating for addition of generic errors events for both phases. 
Something like EVT_PHASE1_ERROR and EVT_PHASE2_ERROR.
Is there any chances for my changes to get in source tree? Or maybe I 
shouldn't be bothering with creating of patch?
Not much activity here for last year.

[Ipsec-tools-devel] Phase 2 negotiation fails if remaining Phase 1 lifetime is less that Phase 2 lifetime

[JL <ips...@rr...>]

I have a problem I have been unable to get to the bottom of.


I have a VPN tunnel where my end is racoon on linux. I suspect the other
end of the VPN tunnel is interpreting all soft timeouts as hard timeouts.
But I don't know what to do about it.


So, for example, if I have a VPN which has, amongst the normal other config:
  remote ZZZZZ {
    exchange mode main;
    lifetime time 15 minute;
    proposal { ... }
  }
  sainfo address XXXXX/XX any address YYYYY/YY any {
    lifetime time 5 minute;
    ...
  }
  sainfo address YYYYY/YY any address XXXXX/XX any {
    lifetime time 5 minute;
    ...
  }

Then what happens is:
  * 00:00 - Phase 1 negotiates, Phase 2 negotiates SA1, Ping succeeds
  * 00:04 - SA1 hits softlimit; new Phase 2 negotiates new SA2
  * 00:05 - SA1 hits hardlimit; is deleted
  * 00:08 - SA2 hits softlimit; new Phase 2 negotiates new SA3
  * 00:09 - SA2 hits hardlimit; is deleted
  * 00:12 - SA3 hits softlimit; new Phase 2 FAILS to negotiate & Pings fail
  * 00:13 - Multiple failed Phase 2 attempts
  * 00:14 - Multiple failed Phase 2 attempts
  * 00:15 - Phase 1 negotiates, Phase 2 negotiates SA4, Ping succeeds
  * 00:19 - SA4 hits softlimit; new Phase 2 negotiates new SA5
  * 00:20 - SA4 hits hardlimit; is deleted
  * 00:23 - SA5 hits softlimit; new Phase 2 negotiates new SA6
  * 00:24 - SA5 hits hardlimit; is deleted
  * 00:27 - SA6 hits softlimit; new Phase 2 FAILS to negotiate & Pings fail
  * 00:28 - Multiple failed Phase 2 attempts
  * 00:29 - Multiple failed Phase 2 attempts
  * 00:30 - Phase 1 negotiates, Phase 2 negotiates SA7, Ping succeeds
... And so on. The linked PDF shows this in a graphical form. (The timings
are slightly fudged; by the time we get to 00:30 it is really 00:30:20-ish;
but for clarity I am rounding everything back to minute boundaries).
​
 VPN Trace.pdf<https://docs.google.com/file/d/0B1FWjXAdhWdabkZJeElkeEhtZ1E/edit?usp=drive_web>
​
I know these timings are silly - I am specifically using them to shrink the
amount of time I needed to discover what was going on. This same pattern
holds true even with realistic lifetimes, like 8hr/1hr. It also holds true
if I set the Phase 1 and SA lifetimes to the same value.

I have no control over or ability to debug the far end. I don't even know
what hardware/software it is running.

It appears to me that there are two problems.
  1) We cannot negotiate a Phase 2 if the lifetime of the Phase 2 would be
longer than the remaining time on the current Phase 1, and
  2) On failing to negotiate a Phase 2, the dying Phase 2 is not accepted
by the other end.


At any point I am in this problem, I can restart racoon while deleting the
SAD entries. This forces a new Phase 1, followed by a new Phase 2, and I am
fine - until, of course, the system needs to negotiate the Phase 2 which
will overlap the end of the Phase 1 lifetime. This is a fine work-around;
but it is not a solution - I need something that will not result in dropped
packets or manual intervention.


The trouble is, I have no idea what to do about this. Is there a way to
convince racoon to lie during the ISAKMP, so that racoon will always expire
the Phase 1 while the far end thinks it is still valid; and early enough
that the Phase 2 that would fail will initiate a new Phase 1? Or is there
another solution anyone can think of?

Thanks,​<https://docs.google.com/file/d/0B1FWjXAdhWdabkZJeElkeEhtZ1E/edit?usp=drive_web>
​
-- 
Jarrod Lowe

Re: [Ipsec-tools-devel] New compiler error in latest ipsec-tools

[Rainer W. <rwe...@mo...>]

Alexander Sbitnev <ale...@gm...> writes:
> Sorry if I it was fixed long ago.
> Got error during compilation on latest Ubuntu:
>
> ipsec_doi.c: In function ‘get_proppair_and_doi_sit’:
> ipsec_doi.c:1186:24: error: argument to ‘sizeof’ in ‘memset’ call is the 
> same expression as the destination; did you mean to dereference it? 
> [-Werror=sizeof-pointer-memaccess]
>
> Since "pair" defined as "struct prop_pair **pair", I suppose the line in 
> question should be:
> memset(pair, 0, sizeof(*pair));
> instead of:
> memset(pair, 0, sizeof(pair));

That's something which already showed up here a while ago. The complete
code block is

        pair = racoon_calloc(1, MAXPROPPAIRLEN * sizeof(*pair));
        if (pair == NULL) {
                plog(LLV_ERROR, LOCATION, NULL,
                        "failed to get buffer.\n");
                goto bad;
        }
        memset(pair, 0, sizeof(pair));

pair is a struct proppair **. This means the memset is technically
correct because sizeof(pair) == sizeof(*pair). But considering that the
allocated memory was already zeroed by racoon_calloc, zeroeing it again
doesn't accomplish anything useful and the statement can be deleted.

[Ipsec-tools-devel] New compiler error in latest ipsec-tools

[Alexander S. <ale...@gm...>]

Sorry if I it was fixed long ago.
Got error during compilation on latest Ubuntu:

ipsec_doi.c: In function ‘get_proppair_and_doi_sit’:
ipsec_doi.c:1186:24: error: argument to ‘sizeof’ in ‘memset’ call is the 
same expression as the destination; did you mean to dereference it? 
[-Werror=sizeof-pointer-memaccess]

Since "pair" defined as "struct prop_pair **pair", I suppose the line in 
question should be:
memset(pair, 0, sizeof(*pair));
instead of:
memset(pair, 0, sizeof(pair));