ipsec-tools-devel — Development discussion of IPsec Tools

[Ipsec-tools-devel] Not all tunnels come up on a gateway after a reboot

[Harsha <ine...@gm...>]

Hi all,

I have a gateway hosting about 50-60  IPSec tunnels. When I reboot the
box, all the tunnels don't come up. For the tunnels that don't come
up, I see that they are stuck in phase 2 with the following log-

2008-11-23 23:36:38 I29 respond new phase 2 negotiation:
10.55.66.10[0]<=>10.60.20.252[0]
2008-11-23 23:36:38 E29 no policy found: 10.60.20.252/32[0]
10.55.66.10/32[0] proto=any dir=in
2008-11-23 23:36:38 E29 failed to get proposal for responder
2008-11-23 23:36:38 E29 failed to pre-process packet.

Googling told that in cases where people had seen this log, it had to
do with key settings. But in my case I know my settings are fine
because before the reboot the tunnels are up fine and if I manually
restart IPSec on the boxes again, they come up fine.

Can running 50-60 endpoints be causing a problem? I also saw this
draft (which is kinda old)-
http://tools.ietf.org/html/draft-vidya-ipsec-failover-ps-00

I looked up the version of code being used and it is badly outdated.
For example isakmp_quick.c is version 1.93 and it is dated May 7th
2002 here-
http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/racoon/Attic/isakmp_quick.c

Unfortunately moving to the latest code completely is not a option. I
can however apply a patch that may help solve this specific problem.
It will be great if anyone knows of any code change that may help this
condition. Any other pointers and suggestions are greatly welcome.

Many thanks,
Harsha

[Ipsec-tools-devel] port matching issues

[Paul M. <pau...@ce...>]

I have just spent several days investigating a bug only to find that it
is addressed in 0.8 (thats OK - thats life)

 

It is the situation where when matching an inbound quick that has ports
in its ID

old code incorrectly picked the first entry without regard to ports.

The fix is roughly what I was typing

 

But I think the checked in fix is wrong

 

a) subnets

assume I have

 

spdadd subnet subnet[21] in

spdadd subnet[21] subnet out

 

then the strict match fails (it doesnt do subnet masking)

 

 

b) wild match wrong

secondly if i have locally

 

spdadd addr[80] -> addr in esp

 

and a remote machine has connected to port 21

 

then if the strict fails the wild match can match this and it seems
highly unlikely that that is the correct thing to do

the remote port certainly is not 80

 

c) remote side has no port specified

locally I have

 

 

spdadd subnet subnet[21] in

spdadd subnet[21] subnet out

spdadd subnet subnet[21] out

spdadd subnet[21] subnet in

 

what should happen when the remote connects?

The ID payload will not have a port in it

but the spd db does have a port so the strict match will fail

then the wild match will pick the first entry that matches regardless of
port

and that will most likely be wrong  (we are back to where we were b4 the
fix)

 

However it can be argued that this is a misconfiguration (both sides
should have port specified)

 

For the first issue I think its better to call cmpspidxwild but with a
flag saying strict port match or not

I have not got to the rest yet

[Ipsec-tools-devel] Racoon problem - ERROR: invalid value of DOI 0x00000034

[Anh K. <kq...@ya...>]

Hi all,

I've met a problem about invalid value of DOI when setup ipsec with transport mode between 2 machine (10.38.7.238 <--> 10.38.7.239).
Here is my configuration

------------------------ Machine 10.38.7.238----------
----- setkey.conf-------
flush;
spdflush;
spdadd 10.38.7.239 10.38.7.238 any -P in ipsec ah/transport//require;
spdadd 10.38.7.238 10.38.7.239 any -P out ipsec ah/transport//require;

---- racoon.conf---------
path pre_shared_key "/home/khuong/data/psk.txt" ;

listen {
        adminsock disabled;
        isakmp 10.38.7.238;
}

remote anonymous
{
        exchange_mode main ;
        my_identifier address ;
        doi ipsec_doi;
        lifetime time 24 hour ;
        esp_frag 552;
        ike_frag on;
        proposal {
                encryption_algorithm des;
                hash_algorithm md5;
                authentication_method pre_shared_key ;
                dh_group 2 ;
        }
}
sainfo anonymous
{
        pfs_group 2;
        lifetime time 12 hour ;
        encryption_algorithm des ;
        authentication_algorithm hmac_md5 ;
        compression_algorithm deflate ;
}

--------------------------- Machine 10.38.7.239------------------------
------ setkey.conf-------------
flush;
spdflush;
spdadd 10.38.7.239 10.38.7.238 any -P out ipsec ah/transport//require;
spdadd 10.38.7.238 10.38.7.239 any -P in ipsec ah/transport//require;

------ racoon.conf ------------
path pre_shared_key "/home/khuong/data/psk.txt" ;

listen {
        adminsock disabled;
        isakmp 10.38.7.239;
}

remote anonymous
{
        exchange_mode main ;
        my_identifier address ;
        doi ipsec_doi;
        lifetime time 24 hour ;
        esp_frag 552;
        ike_frag on;
        proposal {
                encryption_algorithm des;
                hash_algorithm md5;
                authentication_method pre_shared_key ;
                dh_group 2 ;
        }
}
sainfo anonymous
{
        pfs_group 2;
        lifetime time 12 hour ;
        encryption_algorithm des ;
        authentication_algorithm hmac_md5 ;
        compression_algorithm deflate ;
}

After run setkey and racoon commands, I try ping from machine 238 to machine 239 and met the problem about DOI value. Below is the log

-------- On machine 238 --------------------
1970-01-01 01:12:21: INFO: @(#)ipsec-tools 0.6.6 (http://ipsec-tools.sourceforge.net)
1970-01-01 01:12:21: INFO: @(#)This product linked OpenSSL 0.9.7f 22 Mar 2005 (http://www.openssl.org/)
1970-01-01 01:12:21: DEBUG: call pfkey_send_register for AH
1970-01-01 01:12:21: DEBUG: call pfkey_send_register for ESP
1970-01-01 01:12:21: DEBUG: call pfkey_send_register for IPCOMP
1970-01-01 01:12:21: DEBUG: reading config file racoon.conf
1970-01-01 01:12:21: WARNING: racoon.conf:4: "disabled" admin port support not compiled in
1970-01-01 01:12:21: WARNING: racoon.conf:14: "552" Your kernel does not support esp_frag
1970-01-01 01:12:21: DEBUG: compression algorithm can not be checked because sadb message doesn't support it.
1970-01-01 01:12:21: INFO: 10.38.7.238[500] used as isakmp port (fd=5)
1970-01-01 01:12:21: INFO: 10.38.7.238[500] used for NAT-T
1970-01-01 01:12:21: DEBUG: get pfkey X_SPDDUMP message
1970-01-01 01:12:21: DEBUG: get pfkey X_SPDDUMP message
1970-01-01 01:12:21: DEBUG: sub:0xbfba95c8: 10.38.7.239/32[0] 10.38.7.238/32[0] proto=any dir=fwd
1970-01-01 01:12:21: DEBUG: db :0x1008a160: 10.38.7.239/32[0] 10.38.7.238/32[0] proto=any dir=in
1970-01-01 01:12:21: DEBUG: get pfkey X_SPDDUMP message
1970-01-01 01:12:21: DEBUG: sub:0xbfba95c8: 10.38.7.238/32[0] 10.38.7.239/32[0] proto=any dir=out
1970-01-01 01:12:21: DEBUG: db :0x1008a160: 10.38.7.239/32[0] 10.38.7.238/32[0] proto=any dir=in
1970-01-01 01:12:21: DEBUG: sub:0xbfba95c8: 10.38.7.238/32[0] 10.38.7.239/32[0] proto=any dir=out
1970-01-01 01:12:21: DEBUG: db :0x1008a3a0: 10.38.7.239/32[0] 10.38.7.238/32[0] proto=any dir=fwd
1970-01-01 01:12:38: DEBUG: get pfkey ACQUIRE message
1970-01-01 01:12:38: DEBUG: suitable outbound SP found: 10.38.7.238/32[0] 10.38.7.239/32[0] proto=any dir=out.
1970-01-01 01:12:38: DEBUG: sub:0xbfba959c: 10.38.7.239/32[0] 10.38.7.238/32[0] proto=any dir=in
1970-01-01 01:12:38: DEBUG: db :0x1008a160: 10.38.7.239/32[0] 10.38.7.238/32[0] proto=any dir=in
1970-01-01 01:12:38: DEBUG: suitable inbound SP found: 10.38.7.239/32[0] 10.38.7.238/32[0] proto=any dir=in.
1970-01-01 01:12:38: DEBUG: new acquire 10.38.7.238/32[0] 10.38.7.239/32[0] proto=any dir=out
1970-01-01 01:12:38: DEBUG: anonymous sainfo selected.
1970-01-01 01:12:38: DEBUG:  (proto_id=AH spisize=4 spi=00000000 spi_p=00000000 encmode=Transport reqid=0:0)
1970-01-01 01:12:38: DEBUG:   (trns_id=MD5 authtype=hmac-md5)
1970-01-01 01:12:38: DEBUG: anonymous configuration selected for 10.38.7.239.
1970-01-01 01:12:38: INFO: IPsec-SA request for 10.38.7.239 queued due to no phase1 found.
1970-01-01 01:12:38: DEBUG: ===
1970-01-01 01:12:38: INFO: initiate new phase 1 negotiation: 10.38.7.238[500]<=>10.38.7.239[500]
1970-01-01 01:12:38: INFO: begin Identity Protection mode.
1970-01-01 01:12:38: DEBUG: new cookie:
d4cf2492bc097ba2
1970-01-01 01:12:38: DEBUG: add payload of len 52, next type 13
1970-01-01 01:12:38: DEBUG: add payload of len 16, next type 0
1970-01-01 01:12:38: DEBUG: 104 bytes from 10.38.7.238[500] to 10.38.7.239[500]
1970-01-01 01:12:38: DEBUG: sockname 10.38.7.238[500]
1970-01-01 01:12:38: DEBUG: send packet from 10.38.7.238[500]
1970-01-01 01:12:38: DEBUG: send packet to 10.38.7.239[500]
1970-01-01 01:12:38: DEBUG: src4 10.38.7.238[500]
1970-01-01 01:12:38: DEBUG: dst4 10.38.7.239[500]
1970-01-01 01:12:38: DEBUG: 1 times of 104 bytes message will be sent to 10.38.7.239[500]
1970-01-01 01:12:38: DEBUG:
d4cf2492 bc097ba2 00000000 00000000 01100200 00000000 00000068 0d000038
00000001 00000001 0000002c 01010001 00000024 01010000 800b0001 000c0004
00015180 80010001 80030001 80020001 80040002 00000014 afcad713 68a1f1c9
6b8696fc 77570100
1970-01-01 01:12:38: DEBUG: resend phase1 packet d4cf2492bc097ba2:0000000000000000
1970-01-01 01:12:38: DEBUG: ===
1970-01-01 01:12:38: DEBUG: 104 bytes message received from 10.38.7.239[500] to 10.38.7.238[500]
1970-01-01 01:12:38: DEBUG:
d4cf2492 bc097ba2 48b361df 992759d7 01100200 00000000 00000068 0d000038
00000034 00000001 0000002c 01010001 00000024 01010000 800b0001 000c0004
00015180 80010001 80030001 80020001 80040002 00000014 afcad713 68a1f1c9
6b8696fc 77570100
1970-01-01 01:12:38: DEBUG: begin.
1970-01-01 01:12:38: DEBUG: seen nptype=1(sa)
1970-01-01 01:12:38: DEBUG: seen nptype=13(vid)
1970-01-01 01:12:38: DEBUG: succeed.
1970-01-01 01:12:38: INFO: received Vendor ID: DPD
1970-01-01 01:12:38: DEBUG: total SA len=52
1970-01-01 01:12:38: DEBUG:
00000034 00000001 0000002c 01010001 00000024 01010000 800b0001 000c0004
00015180 80010001 80030001 80020001 80040002
1970-01-01 01:12:38: ERROR: invalid value of DOI 0x00000034.
1970-01-01 01:12:38: ERROR: failed to get valid proposal.

------------------- On machine 239 -----------------------
1970-01-01 01:04:51: INFO: @(#)ipsec-tools 0.6.6 (http://ipsec-tools.sourceforge.net)
1970-01-01 01:04:51: INFO: @(#)This product linked OpenSSL 0.9.7f 22 Mar 2005 (http://www.openssl.org/)
1970-01-01 01:04:51: DEBUG: call pfkey_send_register for AH
1970-01-01 01:04:51: DEBUG: call pfkey_send_register for ESP
1970-01-01 01:04:51: DEBUG: call pfkey_send_register for IPCOMP
1970-01-01 01:04:51: DEBUG: reading config file racoon.conf
1970-01-01 01:04:51: WARNING: racoon.conf:4: "disabled" admin port support not compiled in
1970-01-01 01:04:51: WARNING: racoon.conf:14: "552" Your kernel does not support esp_frag
1970-01-01 01:04:51: DEBUG: compression algorithm can not be checked because sadb message doesn't support it.
1970-01-01 01:04:51: INFO: 10.38.7.239[500] used as isakmp port (fd=5)
1970-01-01 01:04:51: INFO: 10.38.7.239[500] used for NAT-T
1970-01-01 01:04:52: DEBUG: get pfkey X_SPDDUMP message
1970-01-01 01:04:52: DEBUG: get pfkey X_SPDDUMP message
1970-01-01 01:04:52: DEBUG: sub:0xbfc235d8: 10.38.7.238/32[0] 10.38.7.239/32[0] proto=any dir=in
1970-01-01 01:04:52: DEBUG: db :0x1008a160: 10.38.7.239/32[0] 10.38.7.238/32[0] proto=any dir=out
1970-01-01 01:04:52: DEBUG: get pfkey X_SPDDUMP message
1970-01-01 01:04:52: DEBUG: sub:0xbfc235d8: 10.38.7.238/32[0] 10.38.7.239/32[0] proto=any dir=fwd
1970-01-01 01:04:52: DEBUG: db :0x1008a160: 10.38.7.239/32[0] 10.38.7.238/32[0] proto=any dir=out
1970-01-01 01:04:52: DEBUG: sub:0xbfc235d8: 10.38.7.238/32[0] 10.38.7.239/32[0] proto=any dir=fwd
1970-01-01 01:04:52: DEBUG: db :0x1008a3a0: 10.38.7.238/32[0] 10.38.7.239/32[0] proto=any dir=in
1970-01-01 01:04:56: DEBUG: ===
1970-01-01 01:04:56: DEBUG: 104 bytes message received from 10.38.7.238[500] to 10.38.7.239[500]
1970-01-01 01:04:56: DEBUG:
d4cf2492 bc097ba2 00000000 00000000 01100200 00000000 00000068 0d000038
00000001 00000001 0000002c 01010001 00000024 01010000 800b0001 000c0004
00015180 80010001 80030001 80020001 80040002 00000014 afcad713 68a1f1c9
6b8696fc 77570100
1970-01-01 01:04:56: DEBUG: anonymous configuration selected for 10.38.7.238.
1970-01-01 01:04:56: DEBUG: ===
1970-01-01 01:04:56: INFO: respond new phase 1 negotiation: 10.38.7.239[500]<=>10.38.7.238[500]
1970-01-01 01:04:56: INFO: begin Identity Protection mode.
1970-01-01 01:04:56: DEBUG: begin.
1970-01-01 01:04:56: DEBUG: seen nptype=1(sa)
1970-01-01 01:04:56: DEBUG: seen nptype=13(vid)
1970-01-01 01:04:56: DEBUG: succeed.
1970-01-01 01:04:56: INFO: received Vendor ID: DPD
1970-01-01 01:04:56: DEBUG: total SA len=52
1970-01-01 01:04:56: DEBUG:
00000001 00000001 0000002c 01010001 00000024 01010000 800b0001 000c0004
00015180 80010001 80030001 80020001 80040002
1970-01-01 01:04:56: DEBUG: begin.
1970-01-01 01:04:56: DEBUG: seen nptype=2(prop)
1970-01-01 01:04:56: DEBUG: succeed.
1970-01-01 01:04:56: DEBUG: proposal #1 len=44
1970-01-01 01:04:56: DEBUG: begin.
1970-01-01 01:04:56: DEBUG: seen nptype=3(trns)
1970-01-01 01:04:56: DEBUG: succeed.
1970-01-01 01:04:56: DEBUG: transform #1 len=36
1970-01-01 01:04:56: DEBUG: type=Life Type, flag=0x8000, lorv=seconds
1970-01-01 01:04:56: DEBUG: type=Life Duration, flag=0x0000, lorv=4
1970-01-01 01:04:56: DEBUG: type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC
1970-01-01 01:04:56: DEBUG: encryption(des)
1970-01-01 01:04:56: DEBUG: type=Authentication Method, flag=0x8000, lorv=pre-shared key
1970-01-01 01:04:56: DEBUG: type=Hash Algorithm, flag=0x8000, lorv=MD5
1970-01-01 01:04:56: DEBUG: hash(md5)
1970-01-01 01:04:56: DEBUG: type=Group Description, flag=0x8000, lorv=1024-bit MODP group
1970-01-01 01:04:56: DEBUG: hmac(modp1024)
1970-01-01 01:04:56: DEBUG: pair 1:
1970-01-01 01:04:56: DEBUG:  0x1008ad50: next=(nil) tnext=(nil)
1970-01-01 01:04:56: DEBUG: proposal #1: 1 transform
1970-01-01 01:04:56: DEBUG: prop#=1, prot-id=ISAKMP, spi-size=0, #trns=1
1970-01-01 01:04:56: DEBUG: trns#=1, trns-id=IKE
1970-01-01 01:04:56: DEBUG: type=Life Type, flag=0x8000, lorv=seconds
1970-01-01 01:04:56: DEBUG: type=Life Duration, flag=0x0000, lorv=4
1970-01-01 01:04:56: DEBUG: type=Encryption Algorithm, flag=0x8000, lorv=DES-CBC
1970-01-01 01:04:56: DEBUG: type=Authentication Method, flag=0x8000, lorv=pre-shared key
1970-01-01 01:04:56: DEBUG: type=Hash Algorithm, flag=0x8000, lorv=MD5
1970-01-01 01:04:56: DEBUG: type=Group Description, flag=0x8000, lorv=1024-bit MODP group
1970-01-01 01:04:56: DEBUG: Compared: DB:Peer
1970-01-01 01:04:56: DEBUG: (lifetime = 86400:86400)
1970-01-01 01:04:56: DEBUG: (lifebyte = 0:0)
1970-01-01 01:04:56: DEBUG: enctype = DES-CBC:DES-CBC
1970-01-01 01:04:56: DEBUG: (encklen = 0:0)
1970-01-01 01:04:56: DEBUG: hashtype = MD5:MD5
1970-01-01 01:04:56: DEBUG: authmethod = pre-shared key:pre-shared key
1970-01-01 01:04:56: DEBUG: dh_group = 1024-bit MODP group:1024-bit MODP group
1970-01-01 01:04:56: DEBUG: an acceptable proposal found.
1970-01-01 01:04:56: DEBUG: hmac(modp1024)
1970-01-01 01:04:56: DEBUG: new cookie:
48b361df992759d7
1970-01-01 01:04:56: DEBUG: add payload of len 52, next type 13
1970-01-01 01:04:56: DEBUG: add payload of len 16, next type 0
1970-01-01 01:04:56: DEBUG: 104 bytes from 10.38.7.239[500] to 10.38.7.238[500]
1970-01-01 01:04:56: DEBUG: sockname 10.38.7.239[500]
1970-01-01 01:04:56: DEBUG: send packet from 10.38.7.239[500]
1970-01-01 01:04:56: DEBUG: send packet to 10.38.7.238[500]
1970-01-01 01:04:56: DEBUG: src4 10.38.7.239[500]
1970-01-01 01:04:56: DEBUG: dst4 10.38.7.238[500]
1970-01-01 01:04:56: DEBUG: 1 times of 104 bytes message will be sent to 10.38.7.238[500]
1970-01-01 01:04:56: DEBUG:
d4cf2492 bc097ba2 48b361df 992759d7 01100200 00000000 00000068 0d000038
00000034 00000001 0000002c 01010001 00000024 01010000 800b0001 000c0004
00015180 80010001 80030001 80020001 80040002 00000014 afcad713 68a1f1c9
6b8696fc 77570100
1970-01-01 01:04:56: DEBUG: resend phase1 packet d4cf2492bc097ba2:48b361df992759d7

Who met the prolem before? and thanks for any help to troubleshoot it.

-- Anh Khuong--


      

Re: [Ipsec-tools-devel] rapid repeat acquires

[VANHULLEBUS Y. <va...@fr...>]

Hi.


On Tue, Feb 17, 2009 at 08:13:33AM +0200, Timo Ters wrote:
> Paul Moore wrote:
> > when an acquire triggers a ph2 and that in turn fires a ph1 creation no
> > flags are set in the ph2 entry that makes it look pending
> > 
> > this means that if another acquire arrives very quickly then the waiting
> > ph2 get killed as a zombie in getph2byid call in pk_recvacquire
> >[snip]
> > 
> > although I think an explicit 'waiting for phase1' state would be better
> 
> To me, it looks like the whole test in getph2byid() is a bit funny.
> Furthermore, it returns on first match, so it might or might not
> expire the ph2 depending on various things.
> 
> I'm guessing the intent is to check there if there is a ph2 that has
> been there for a long time, but has not been killed for some reason
> (bug in the other parts of code: e.g. timers not expiring or the
> checkph1 logic failing).
> 
> My opinion is to just remove the "Zombie check" getph2byid().
> Emmanuel, Yvan, any ideas why that check is there?

The "zombie check" is an ugly hack I made a while ago, because we knew
we had some race conditions where such zombie handlers could be
created and block the whole tunnel until you restart racoon, but we
didn't understood at that time what were exactly those race
conditions.

I believe we fixed those race conditions now (does anyone has a
"zombie" in his logs ?), the check has just been kept because we were
not sure that *all* those race conditions have been fixed....


Note about the context on Solaris: racoon should have a better
reaction when getting faster acquire requests, but it is a quite bad
idea to send such acquires so fast (well, it is at least useless: we
do know that a negociation in the real world takes at least 1-2
seconds).


Yvan.

Re: [Ipsec-tools-devel] rapid repeat acquires

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

Paul Moore wrote:
> when an acquire triggers a ph2 and that in turn fires a ph1 creation no
> flags are set in the ph2 entry that makes it look pending
> 
> this means that if another acquire arrives very quickly then the waiting
> ph2 get killed as a zombie in getph2byid call in pk_recvacquire
>[snip]
> 
> although I think an explicit 'waiting for phase1' state would be better

To me, it looks like the whole test in getph2byid() is a bit funny.
Furthermore, it returns on first match, so it might or might not
expire the ph2 depending on various things.

I'm guessing the intent is to check there if there is a ph2 that has
been there for a long time, but has not been killed for some reason
(bug in the other parts of code: e.g. timers not expiring or the
checkph1 logic failing).

My opinion is to just remove the "Zombie check" getph2byid().
Emmanuel, Yvan, any ideas why that check is there?

- Timo

Re: [Ipsec-tools-devel] heap corruption in setkey with priority

[Dan M. <da...@su...>]

A good set of tests to run for memory corruption checking on Solaris is:

(using sh & derivatives)

	LD_PRELOAD=libumem.so UMEM_DEBUG=default <command>

(using csh & derivatives)

	(setenv LD_PRELOAD libumem.so; setenv UMEM_DEBUG default ; <command>)

If libumem (user-space version of the Solaris kmem) detects corruption, it'll
core-dump your app and you can look at it with mdb post-mortem to see what's
up.  This includes the "::findleaks" dcmd, which does exactly what you think
it does.  Take a core dump on a running (with libumem) racoon or setkey with
gcore and then run ::findleaks.

Since you're working on the port, you might as well exploit your target's
toolset.

Dan

Re: [Ipsec-tools-devel] heap corruption in setkey with priority

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

Paul Moore wrote:
> spdadd ........ prio 10000 none;
>[snip]
> 
> $3.buf contains "10000 none" - yacc does not insert a \0
> 
> so the sprintf runs over
> 
> On linux it doesnt seem to do any harm (I guess the allocation unit was
> rounded up)
> 
> corrupts the heap on solaris
> 
> however this code can be replaced by one line :-
> p_priority_offset = -atol($3.buf)
> 
> I dont know where the original  code came from buts its almost a
> dailywtf candidate

Thanks. Applied.

Could you send future patches in "diff -u" format? Or at least mention the
source files and line numbers.

Thanks,
  Timo

[Ipsec-tools-devel] heap corruption in setkey with priority

[Paul M. <pau...@ce...>]

spdadd ........ prio 10000 none;

 

                                                /* buffer big enough to
hold a prepended negative sign */

                                                offset_buf =
malloc($3.len + 2);

                                                if (offset_buf == NULL) 

                                                {

 
__ipsec_errcode = EIPSEC_NO_BUFS;

                                                                return
-1;

                                                }

 

                                                /* positive input value
means higher priority, therefore lower

                                                   actual value so that
is closer to the beginning of the list */

                                                sprintf (offset_buf,
"-%s", $3.buf);

 

                                                errno = 0;

                                                p_priority_offset =
atol(offset_buf);

                                                free(offset_buf);

 

$3.buf contains "10000 none" - yacc does not insert a \0

so the sprintf runs over

On linux it doesnt seem to do any harm (I guess the allocation unit was
rounded up)

corrupts the heap on solaris

 

however this code can be replaced by one line :-

 

p_priority_offset = -atol($3.buf)

 

I dont know where the original  code came from buts its almost a
dailywtf candidate

 

[Ipsec-tools-devel] rapid repeat acquires

[Paul M. <pau...@ce...>]

when an acquire triggers a ph2 and that in turn fires a ph1 creation no
flags are set in the ph2 entry that makes it look pending

 

this means that if another acquire arrives very quickly then the waiting
ph2 get killed as a zombie in getph2byid call in pk_recvacquire

 

                                                if(p->status <
PHASE2ST_ESTABLISHED &&

                                                   p->retry_counter == 0

                                                   && p->sce == NULL &&
p->scr == NULL){

 
plog(LLV_DEBUG, LOCATION, NULL,

 
"Zombie ph2 found, expiring it\n");

 
isakmp_ph2expire(p);

 

status = PHASE2ST_STATUS2

sce,scr,retyr_count = 0

 

I suspect that this has not been a problem in the past because Linux
seems to retry its acquires fairly slowly, solaris is very impatient (~1
second between acquires)

 

simple fix is to do

                                                if(p->status <
PHASE2ST_ESTABLISHED &&

                                                   p->retry_counter == 0
&& p->retry_checkph1 == 0

                                                   && p->sce == NULL &&
p->scr == NULL){

 
plog(LLV_DEBUG, LOCATION, NULL,

 
"Zombie ph2 found, expiring it\n");

 
isakmp_ph2expire(p);

 

and add retry_checkph1 = 0 in isakmp_chkph1there

although I think an explicit 'waiting for phase1' state would be better

Re: [Ipsec-tools-devel] Question re: certificate based authentication

[Dan S. <dan...@uc...>]

Sorry, I accidentally pressed send too soon :X

 > cat ifcfg-ipsec0
DST=128.135.19.61
TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK

I don't understand how this file should be modified, and I can't really 
find any documentation on how to do this.  I'm assuming the IKE_METHOD 
should be set to RSA or something among those lines, but I can't find 
any man page or good documentation for these interface configuration 
files.  Am I looking in the wrong place?

I guess I don't really understand how the ipsec0 interface configuration 
relates to the racoon daemon itself.  It seems like these parameters are 
already configured in the racoon.conf and are redundant.

Can somebody maybe point me to some documentation or explain how 
ifcfg-eth0 should be configured for RSA certificate authentication?

Thanks,

Dan


Dan Sullivan wrote:
> Hello,
> 
> I am not 100% sure I'm asking this question in the right place but I'll 
> take a stab at sending to this list again.  The support I got here last 
> time was great, so I'm hoping that somebody could either answer my 
> question or point me in the right direction.
> 
> Basically, a while back I had some questions about setkey/racoon.conf 
> and building Phase 2 SA using a PSK.  I got that up working fine, but 
> now I want to take it a step further.  I'm trying to get this setup 
> using certificates.
> 
> It looks to me like the racoon configuration to do this is 
> straightforward; essesntially do the following;
> 
> 1) cp /path/to/cacert.pem /etc/racoon/certs
> 2) cd /etc/racoon/certs
> 3) ln -s cacert.pem `openssl x509 -hash -noout -in cacert.pem`.0
> 4) change racoon.conf to change authentication type, set certificate 
> type, set identifier, and turn verify_cert on
> 
> So, I understand that part and I am pretty confident that it will work. 
>   What I am really confused about and can't find any documentation for 
> is how the ipsec0 interface should be configured.  Currently, my 
> ifcfg-ipsec0 configuration file looks like this:
> 
> 
> 
> 

[Ipsec-tools-devel] Question re: certificate based authentication

[Dan S. <dan...@uc...>]

Hello,

I am not 100% sure I'm asking this question in the right place but I'll 
take a stab at sending to this list again.  The support I got here last 
time was great, so I'm hoping that somebody could either answer my 
question or point me in the right direction.

Basically, a while back I had some questions about setkey/racoon.conf 
and building Phase 2 SA using a PSK.  I got that up working fine, but 
now I want to take it a step further.  I'm trying to get this setup 
using certificates.

It looks to me like the racoon configuration to do this is 
straightforward; essesntially do the following;

1) cp /path/to/cacert.pem /etc/racoon/certs
2) cd /etc/racoon/certs
3) ln -s cacert.pem `openssl x509 -hash -noout -in cacert.pem`.0
4) change racoon.conf to change authentication type, set certificate 
type, set identifier, and turn verify_cert on

So, I understand that part and I am pretty confident that it will work. 
  What I am really confused about and can't find any documentation for 
is how the ipsec0 interface should be configured.  Currently, my 
ifcfg-ipsec0 configuration file looks like this:

Re: [Ipsec-tools-devel] per-identity remote options

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

Timo Teräs wrote:
> Timo Teräs wrote:
>> Okay then. As earlier mentioned I'm doing progress. I put a very
>> initial draft of this patch available to (the patch number 03):
>> http://solidboot.com/~fabled/ipsec-tools/

Patch refreshed again.

>> This is not production ready as it is not doing all required things.
>> It also has many problems that I am aware of. It's just to show
>> the general idea, and what I'm aiming towards. The patch is broke
>> wrt. GSS stuff. And security wise too; we need to call
>> revalidate_ph1() from ipsecdoi_checkid1() now.
> 
> Compiles again with GSS. Security wise still broken. And not too
> well tested either.

Should honor all security configuration stuff again.

Tested with two remotes:
1. Having different proposals, so selection can happen early
2. Having similar proposal, but different CA, so selection
   happens late.

Both seemed to work okay as responder and initiator.

> I'm still working on the following three points:
> 
>> 2. The remoteconf options for nonce_size, nat_traversal and
>>    dpd_* cannot be used. They affect the initial exchanges where
>>    correct remoteconf might not be known depending on phase1
>>    exchange_mode and authentication type.
> 
> I guess I'll add global options for these.

Still hard coded. Globally configurable default seems to
be the way to go.

>> 3. I'm not sure how we should figure out if certificate request
>>    should be sent. My best effort would be to send it if
>>    authentication type supports certificates. In that case we
>>    would send CR for each CA we trust (it's allowed to send
>>    multiple CR). Or we could just send one non-specific CR.
> 
> I'm thinking we send a specific CR for each CA we support.
> Possibly having a global option to override this and send only
> non-specific CR. There was earlier a patch for sending specific
> CR:s, but there was some problems with it. I'll dig it up and
> fix it up for this use scenario.

Implemented as such: CR for each CA subject / expect cert Issuer
is sent. Also when being responder, multiple CR:s are parsed
and the CR DN is parsed and used to select appropriate remoteconf.

>> 4. We need to have "named" remoteconfs, so we can inherit from
>>    them and refer to them when initiating a connection through
>>    admin interface.
> 
> And this is just coding. Will implement later on.

These are implemented too.

So now it's missing:
- more testing
- manpages/usage update
- writing of remoteconf back to file is not yet updated

It's relatively large patch, and also cleans up several internal
aspects, so I hope it'll get tested by others. I'll start
considering to committing it once I've polished off the missing
few bits.

- Timo