Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-08 Thread Christos Zoulas 
On Mar 8,  2:26pm, fr...@phoenix.owl.de (Frank Wille) wrote:
-- Subject: Re: Simple IPSEC client with certificate - phase 1 time out

| http://www.netbsd.org/docs/network/ipsec/
| In section "Configuring IPsec kernel".
| 
| It also mentions IPSEC_ESP, which was removed together with IPSEC_NAT_T
| after netbsd-6.

Fixed.

christos

Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-08 Thread Frank Wille 
Greg Troxel wrote:

> It seems to me that if a kernel with "option IPSEC" and w/o swcrypto
> doesn't work, then perhaps it should fail to config, or log an error at
> runtime.  (Perhaps swcrypto isn't required, and it's just that there
> must be some crypto provider.)

As far as I understand swcrypto registers software encryption algorithms in
the kernel for 3des, aes, blowfish, etc.. They are not explicitely required
as you may also use hardware for that.

-- 
Frank Wille

Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-08 Thread Greg Troxel 

Frank Wille  writes:

> BTW, my problem with setkey on macppc was caused by the missing swcrypto
> pseudo device in the kernel.
>
> Our IPsec FAQ should mention that you need that, besides "option IPSEC". I
> know that amd64, i386 and sparc64 have these enabled by default now, but no
> other port has.

It seems to me that if a kernel with "option IPSEC" and w/o swcrypto
doesn't work, then perhaps it should fail to config, or log an error at
runtime.  (Perhaps swcrypto isn't required, and it's just that there
must be some crypto provider.)


signature.asc
Description: PGP signature

Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-08 Thread Christos Zoulas 
On Mar 8, 12:14pm, fr...@phoenix.owl.de (Frank Wille) wrote:
-- Subject: Re: Simple IPSEC client with certificate - phase 1 time out

| Christos Zoulas wrote:
| 
| >>| > If your server is behind NAT, I think that got broken at some point.
| >>| 
| >>| Oh no! :(
| >>
| >>Yes, it is almost working... The tunnel is up, and 3 out of 4 SAD's are
| >>present; the 4th one comes up as larval and then times out... 
| >
| >And it is now fixed and tested on little endian. I have done no testing
| >on big endian. I guess I could boot my sparc64 box and see if the extended
| >rest made the hardware more reliable :-)
| 
| Indeed. It is! Many thanks for your great work! Much appreciated. :)

Great!

| IPsec with Racoon behind NAT is confirmed to work now. Tested on macppc, so
| there is no endian problem.
| 
| Do we get a pullup for netbsd-7, and maybe netbsd-6?

I asked for them just now.

| BTW, my problem with setkey on macppc was caused by the missing swcrypto
| pseudo device in the kernel.
| 
| Our IPsec FAQ should mention that you need that, besides "option IPSEC". I
| know that amd64, i386 and sparc64 have these enabled by default now, but no
| other port has.

URL?

christos

Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-05 Thread Christos Zoulas 
In article <20160305160718.f2ef517f...@rebar.astron.com>,
Christos Zoulas <chris...@zoulas.com> wrote:
>On Mar 5,  4:32pm, fr...@phoenix.owl.de (Frank Wille) wrote:
>-- Subject: Re: Simple IPSEC client with certificate - phase 1 time out
>
>| Christos Zoulas wrote:
>| 
>| > If your server is behind NAT, I think that got broken at some point.
>| 
>| Oh no! :(
>
>Yes, it is almost working... The tunnel is up, and 3 out of 4 SAD's are
>present; the 4th one comes up as larval and then times out... 

And it is now fixed and tested on little endian. I have done no testing
on big endian. I guess I could boot my sparc64 box and see if the extended
rest made the hardware more reliable :-)

christos

Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-05 Thread Christos Zoulas 
On Mar 5,  4:32pm, fr...@phoenix.owl.de (Frank Wille) wrote:
-- Subject: Re: Simple IPSEC client with certificate - phase 1 time out

| Christos Zoulas wrote:
| 
| > If your server is behind NAT, I think that got broken at some point.
| 
| Oh no! :(

Yes, it is almost working... The tunnel is up, and 3 out of 4 SAD's are
present; the 4th one comes up as larval and then times out... 

| > I meant to debug this... I guess I should just do it...
| 
| That would be so great! I can provide you with any information you need
| and can do all sorts of tests. Also with big endian hardware.
| 
| BTW, there is a strange problem with adding SAs in the 7.0 kernel.
| Maybe it doesn't work on big endian?

I don't know. make sure you have IPSEC_DEBUG in your kernel and you'll
get a lot of useful info.

| 1. NetBSD/macppc 7.0 (PowerBook G4):
| # setkey -c
| add 10.0.0.1 10.0.0.2 esp 1234 -E aes-cbc "testtesttesttest";
| Invalid argument.
| # setkey -D
| No SAD entries.
| 
| 2. NetBSD/amd64 7.0 (Asus i3):
| # setkey -c
| add 10.0.0.1 10.0.0.2 esp 1234 -E aes-cbc "testtesttesttest";
| # setkey -D
| 10.0.0.1 10.0.0.2 
| esp mode=any spi=1234(0x04d2) reqid=0(0x)
| E: aes-cbc  74657374 74657374 74657374 74657374
| seq=0x replay=0 flags=0x0040 state=mature 
| created: Mar  5 15:53:31 2016   current: Mar  5 16:20:54 2016
| diff: 1643(s)   hard: 0(s)  soft: 0(s)
| last: Mar  5 11:41:33 2016  hard: 0(s)  soft: 0(s)
| current: 0(bytes)   hard: 0(bytes)  soft: 0(bytes)
| allocated: 0hard: 0 soft: 0
| sadb_seq=0 pid=2037 refcnt=1
| 
| 
| So the "pfkey ADD failed" is not present on x86, but the "pfkey UPDATED
| failed" is still there. I was able to see the SA to be updated for a short
| time in "larval" state when phase 2 was established:

The updated failed is fine (No such file or directory means it was not
present), and then it succeeds adding it.

| # setkey -D
| 192.168.0.21[4500] 78.48.238.147[4500] 
| esp-udp mode=tunnel spi=17572466(0x010c2272) reqid=0(0x)
| E: aes-cbc  d5bd6bf8 2d5fd2f7 49c5ebdc d20c6299
| A: hmac-md5  3bd33ccd cd06e211 b5b7b926 399089e7
| seq=0x0002 replay=4 flags=0x state=mature 
| created: Mar  5 14:57:06 2016   current: Mar  5 14:57:14 2016
| diff: 8(s)  hard: 28800(s)  soft: 23040(s)
| last: Mar  5 14:57:07 2016  hard: 0(s)  soft: 0(s)
| current: 320(bytes) hard: 0(bytes)  soft: 0(bytes)
| allocated: 2hard: 0 soft: 0
| sadb_seq=1 pid=660 refcnt=2
| 78.48.238.147 192.168.0.21 
| esp mode=tunnel spi=120588728(0x073009b8) reqid=0(0x)
| seq=0x replay=0 flags=0x state=larval 
| sadb_seq=0 pid=660 refcnt=1

I hope to fix the problem soon... It has been broken forever.

christos

Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-05 Thread Frank Wille 
Christos Zoulas wrote:

> If your server is behind NAT, I think that got broken at some point.

Oh no! :(


> I meant to debug this... I guess I should just do it...

That would be so great! I can provide you with any information you need
and can do all sorts of tests. Also with big endian hardware.


BTW, there is a strange problem with adding SAs in the 7.0 kernel.
Maybe it doesn't work on big endian?

1. NetBSD/macppc 7.0 (PowerBook G4):
# setkey -c
add 10.0.0.1 10.0.0.2 esp 1234 -E aes-cbc "testtesttesttest";
Invalid argument.
# setkey -D
No SAD entries.

2. NetBSD/amd64 7.0 (Asus i3):
# setkey -c
add 10.0.0.1 10.0.0.2 esp 1234 -E aes-cbc "testtesttesttest";
# setkey -D
10.0.0.1 10.0.0.2 
esp mode=any spi=1234(0x04d2) reqid=0(0x)
E: aes-cbc  74657374 74657374 74657374 74657374
seq=0x replay=0 flags=0x0040 state=mature 
created: Mar  5 15:53:31 2016   current: Mar  5 16:20:54 2016
diff: 1643(s)   hard: 0(s)  soft: 0(s)
last: Mar  5 11:41:33 2016  hard: 0(s)  soft: 0(s)
current: 0(bytes)   hard: 0(bytes)  soft: 0(bytes)
allocated: 0hard: 0 soft: 0
sadb_seq=0 pid=2037 refcnt=1


So the "pfkey ADD failed" is not present on x86, but the "pfkey UPDATED
failed" is still there. I was able to see the SA to be updated for a short
time in "larval" state when phase 2 was established:

# setkey -D
192.168.0.21[4500] 78.48.238.147[4500] 
esp-udp mode=tunnel spi=17572466(0x010c2272) reqid=0(0x)
E: aes-cbc  d5bd6bf8 2d5fd2f7 49c5ebdc d20c6299
A: hmac-md5  3bd33ccd cd06e211 b5b7b926 399089e7
seq=0x0002 replay=4 flags=0x state=mature 
created: Mar  5 14:57:06 2016   current: Mar  5 14:57:14 2016
diff: 8(s)  hard: 28800(s)  soft: 23040(s)
last: Mar  5 14:57:07 2016  hard: 0(s)  soft: 0(s)
current: 320(bytes) hard: 0(bytes)  soft: 0(bytes)
allocated: 2hard: 0 soft: 0
sadb_seq=1 pid=660 refcnt=2
78.48.238.147 192.168.0.21 
esp mode=tunnel spi=120588728(0x073009b8) reqid=0(0x)
seq=0x replay=0 flags=0x state=larval 
sadb_seq=0 pid=660 refcnt=1


-- 
Frank Wille

Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-04 Thread Frank Wille 
Brett Lynn wrote:

On 04.03.16 09:20:12 you wrote:

> Well, let's say packet loss from the point of view of racoon, ipsec can
> be very sensitive to lossy networks so it is good the eliminate that as
> a cause.  The test with the windows client is valuable, it shows that
> ipsec can work from where you are.

Indeed. And I guess we can ignore a potential packet loss for now. I
debugged Racoon and studied the source over several hours and came to the
conclusion that IKE mode config only works with Hybrid authentication
modes. No plain "rsasig", which is a pity.

Might not be too difficult to add...


> As for the keep alives, the
> handling of those depends on the client and/or its configuration -
> maybe the windows client is configured to ignore the keep alives?

Now I guess that keep-alives are just sent to have some traffic, but no need
to reply them. The Lancom gateway does not sent them itself My own NetBSD
gateway generates them, but does not reply either.


> I do recall being able to get logging out of racoon.  Have you tried
> running racoon in the foreground

Correct. I discovered that in the meantime. "debug" output is never written
to syslog for security reasons (contains hexdumps of keys and
certificates).


>> Also I'm getting doubt whether "authentication_method rsasig" is
>> working at all. Until now I found no success stories with such a
>> configuration on the net, especially when using mode_cfg.
>> 
>
> As for a lot of things, it is hard to find success stories on the net -

True, but unfortunately I was right here. :|


> I have only done hybrid-xauth, part of that was validating a
> certificate.

Now I tried "hybrid_rsa_client", which perfectly does mode config, calls my
phase1-up script and adds the appropriate SPD entries.

There is no phase 2 negotiation before I try to connect to any VPN address,
but I think that's normal.

Unfortunately even the proven hybrid authentication fails for me. The kernel
cannot update or add keys for SAD:

racoon: INFO: initiate new phase 2 negotiation:
192.168.1.5[4500]<=>77.182.71.224[4500] 
racoon: INFO: NAT detected -> UDP encapsulation (ENC_MODE 1->3). 
racoon: INFO: Adjusting my encmode UDP-Tunnel->Tunnel 
racoon: INFO: Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1) 
/netbsd: key_set_natt_ports: type 2, sport = 4500, dport = 4500
/netbsd: key_update: no SA index found.
/netbsd: key_set_natt_ports: type 2, sport = 4500, dport = 4500
/netbsd: key_setsaval: unable to initialize SA type 3.
racoon: ERROR: pfkey UPDATE failed: No such file or directory 
racoon: ERROR: pfkey ADD failed: Invalid argument 
racoon: ERROR: 77.182.71.224 give up to get IPsec-SA due to time up to wait.


On the other hand, the Racoon server/gateway has no problem. It may have
something to do with NAT-T...?

-- 
Frank Wille

Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-03 Thread Brett Lymn 
On Wed, Mar 02, 2016 at 12:40:30PM +0100, Frank Wille wrote:
> >
> > OK and here is where things fall apart.  The client sends an "are you
> > there" request and vpn server sends a reply but it seems like the
> > packet did not get through and then things go bad from there...
> 
> What makes you think so? Looking at the tcpdump directly from the NetBSD
> client shows that the ACK from the Lancom router arrived (those were the
> only packets at 11:52:27):
> 
> 11:52:27.567012 IP 192.168.1.5.4500 > 1.2.3.4.4500: NONESP-encap: isakmp:
> phase 2/others I inf[E]
> 11:52:27.609318 IP 1.2.3.4.4500 > 192.168.1.5.4500: NONESP-encap: isakmp:
> phase 2/others R inf[E]
> 
> IMHO, DPD works fine.
> 

Because racoon says that it didn't receive the ack from the lancom -
either it received the packet and didn't like it or racoon didn't see it
for some reason.  It is good that the packet made it all the way back,
it would be better if we could understand what, if anything, racoon did
with it.

> 
> >> [VPN-Status] 2016/03/01 11:52:37,096
> >> VPN: connection for VPNCLIENT15EF90 (91.56.237.127) timed out: no
> >> response
> 
> BTW, this timeout is always 30 seconds after phase1 has been established. No
> matter what I do. With of without DPD. With or without mode_cfg.
> 

Right, that is the lancom losing patience and tearing down its side of
the connection.

> 
> > OK so what we can see here is that there seems to be some packet loss
> > that is causing the NetBSD client to wait for an answer but during that
> > time the vpn server decides nothing is happening and tears the
> > connection down.  So, some things to consider:
> 
> I'm not so sure about that packet loss. The only possible packet loss, which
> Greg already noticed in a parallel thread on tech-net, seems to be with
> NAT-T keepalive. But a test with a working Windows client using the same
> certificate on the same LAN showed that those keepalive messages are not
> replied either.
> 

Well, let's say packet loss from the point of view of racoon, ipsec can
be very sensitive to lossy networks so it is good the eliminate that as
a cause.  The test with the windows client is valuable, it shows that
ipsec can work from where you are.  As for the keep alives, the handling
of those depends on the client and/or its configuration - maybe the
windows client is configured to ignore the keep alives?

> 
> > 0) How reliable is the internet connection on the client side?  It
> > seems these days there is an assumption the connection is fast.
> 
> ADSL with approx. 6 MBit down and 1 MBit up. But our DSLAM is already
> capable of 50 or 100 MBit, and only 30m away.
> 
> I do not remember having any reliability problems.
> 

Good - another thing we can tick off as not being a cause.

> 
> > 1) Since one side is doing NAT-T, do you have port forwarding on the
> > router so that the IKE packets (udp 500 and 4500) are forwarded back to
> > the vpn client?  Though it seems you must already have this right to
> > get the phase 1 done...
> 
> That's an interesting question. No, I don't have port forwarding enabled. Do
> I really need that? I thought one of the reasons for using NAT-T is to work
> around such problems?
> 

Yes, I think you are correct... my flaky memory is probably throwing
that up because I was running a vpn server behind a NAT and had to do
the port forwarding.  As you have stated, NAT-T is supposed to work
around those issues.

> But, as you said, I see UDP 500 and 4500 packets coming through on both
> sides, and the Windows client is working over the same router. So I guess
> everything is fine...
> 

Yes, at a network infrastructure level it seems so given that the
windows client just works.

> 
> without. Now I did:
> 
> pass in from any to any
> pass out from any to any
> 
> ...for a test. But it didn't change anything. So I don't think there is a
> firewall problem.
> 

OK, that sounds like it eliminates a firewall issue.

> 
> > 3) some firewalls/routers don't like large udp packets, there are some
> > racoon settings for fragmenting packets - perhaps you need those.
> 
> I already had "ike_frag on" in my config. Now I also added "esp_frag 552",
> without making any difference.
> 

Try dropping the esp_frag to, say, 352 just to see what happens.  I know
the man page says 552 should be safe but that seems a bit close to the
minimum mtu which is 576.  At least a very low frag value will eliminate
the possibility of the packet getting fragmented.  Also, does the NetBSD
client network interface have any tcp checksum offload turned on?

> My current racoon.conf:
> 

That all looks fairly sensible to me...

> 
> Unfortunately "log debug" doesn't work at all. I get no debug messages out
> of racoon.
> 

I do recall being able to get logging out of racoon.  Have you tried
running racoon in the foreground (i.e. using the -F flag along with
multiple -d) also have you used the -l flag to log to a file instead of
syslog?

> Also I'm getting doubt whether

Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-02 Thread Frank Wille 
Thor Lancelot Simon wrote:

> Consider disabling dead peer detection?

Yes, tried that. The only difference is that "racoonctl vc 1.2.3.4" does not
return, as it never realizes that the VPN server is dead.

Otherwise the Lancom still terminates my connection after 30s.

-- 
Frank Wille

Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-02 Thread Frank Wille 
Brett Lymn wrote:

> Well, there is a chance that the negotiation was failing due to packets
> not going where you expect.  That doesn't appear to be happening but
> checking the simple things can't hurt and can save a lot of grief :)

Sure. I will do what I can. Thanks for your detailed analyzation, BTW.


>> [VPN-Status] 2016/03/01 11:52:07,121
>> IKE info: Phase-1 [responder] for peer VPNCLIENT15EF90 initiator id
>> [...]
>
> This is good - we have a phase 1 done here, note the initiator and
> responder cookies match the SPI numbers from the NetBSD side.  Looking
> good at this point.

Besides that IKE mode config is not requested by the NetBSD client, although
explicitely stated in the racoon.conf.


>> [VPN-Status] 2016/03/01 11:52:27,223
>> IKE info: NOTIFY received of type ISAKMP_NOTIFY_DPD_R_U_THERE for peer
>> VPNCLIENT15EF90 Seq-Nr 0xe8, expected 0xe8
>
>> 
>> [VPN-Status] 2016/03/01 11:52:27,224
>> IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE_ACK sent for Phase-1 SA to peer
>> VPNCLIENT15EF90, sequence nr 0xe8
>
>
> OK and here is where things fall apart.  The client sends an "are you
> there" request and vpn server sends a reply but it seems like the
> packet did not get through and then things go bad from there...

What makes you think so? Looking at the tcpdump directly from the NetBSD
client shows that the ACK from the Lancom router arrived (those were the
only packets at 11:52:27):

11:52:27.567012 IP 192.168.1.5.4500 > 1.2.3.4.4500: NONESP-encap: isakmp:
phase 2/others I inf[E]
11:52:27.609318 IP 1.2.3.4.4500 > 192.168.1.5.4500: NONESP-encap: isakmp:
phase 2/others R inf[E]

IMHO, DPD works fine.


>> [VPN-Status] 2016/03/01 11:52:37,096
>> VPN: connection for VPNCLIENT15EF90 (91.56.237.127) timed out: no
>> response

BTW, this timeout is always 30 seconds after phase1 has been established. No
matter what I do. With of without DPD. With or without mode_cfg.


> OK so what we can see here is that there seems to be some packet loss
> that is causing the NetBSD client to wait for an answer but during that
> time the vpn server decides nothing is happening and tears the
> connection down.  So, some things to consider:

I'm not so sure about that packet loss. The only possible packet loss, which
Greg already noticed in a parallel thread on tech-net, seems to be with
NAT-T keepalive. But a test with a working Windows client using the same
certificate on the same LAN showed that those keepalive messages are not
replied either.


> 0) How reliable is the internet connection on the client side?  It
> seems these days there is an assumption the connection is fast.

ADSL with approx. 6 MBit down and 1 MBit up. But our DSLAM is already
capable of 50 or 100 MBit, and only 30m away.

I do not remember having any reliability problems.


> 1) Since one side is doing NAT-T, do you have port forwarding on the
> router so that the IKE packets (udp 500 and 4500) are forwarded back to
> the vpn client?  Though it seems you must already have this right to
> get the phase 1 done...

That's an interesting question. No, I don't have port forwarding enabled. Do
I really need that? I thought one of the reasons for using NAT-T is to work
around such problems?

But, as you said, I see UDP 500 and 4500 packets coming through on both
sides, and the Windows client is working over the same router. So I guess
everything is fine...


> 2) any firewall rules blocking the incoming traffic?  Again, just check
> though it doesn't make much sense give you have managed to get so far
> along.

My home router is a Soekris running NetBSD. A few days ago I added the
following ipf rules:

pass in quick proto 4 from any to any  
pass in quick proto esp from any to any
pass in quick proto ah from any to any
pass in quick proto udp from any port = 500 to any port = 500  
pass in quick proto udp from any port = 4500 to any port = 4500
pass out quick proto 4 from any to any  
pass out quick proto esp from any to any
pass out quick proto ah from any to any
pass out quick proto udp from any port = 500 to any port = 500  
pass out quick proto udp from any port = 4500 to any port = 4500

But I don't think they are required, as the Windows VPN-client worked
without. Now I did:

pass in from any to any
pass out from any to any

...for a test. But it didn't change anything. So I don't think there is a
firewall problem.


> 3) some firewalls/routers don't like large udp packets, there are some
> racoon settings for fragmenting packets - perhaps you need those.

I already had "ike_frag on" in my config. Now I also added "esp_frag 552",
without making any difference.

My current racoon.conf:

path include "/etc/racoon";
path certificate "/etc/racoon/certs";
path script "/etc/racoon/scripts";

# "log" specifies logging level.  It is followed by either "notify", "debug"
# or "debug2".
log debug;

#timer
#{
#   natt_keepalive 15 seconds;
#}

remote "wpsd"
{
remote_address 1.2.3.4;
exchange_mode main,base;

my_identifier asn1dn;

Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-01 Thread Thor Lancelot Simon 
Consider disabling dead peer detection?

Thor

Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-01 Thread Brett Lymn 
On Tue, Mar 01, 2016 at 09:09:07AM -0500, Greg Troxel wrote:
> 
> In my experience, SPD entries are added outside of racoon to tell the
> kernel that certain traffic should have IPsec protection.   I don't
> understand how in your setup that's supposed to work, or what is
> triggering racoon to start the negotiation.
> 

A SPD sets the policy for encrypting an outgoing packet.  If you are
simply creating a tunnel between two machines I think you don't need it
but if you have a machine that wants to access a network on the other
side of a tunnel then you need a SPD to tell ipsec to use a particular
SAD to encrypt and send the packet.  I cannot recall myself but I think
raccoon should set up the SPD if you have told it there is a network
range on the remote end.  If racoon is configured with passive off then
it will attempt negotiation when it starts, I expect this is what is
happening.

-- 
Brett Lymn
Let go, or be dragged - Zen proverb.

Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-01 Thread Brett Lymn 
On Tue, Mar 01, 2016 at 01:11:08PM +0100, Frank Wille wrote:
> Brett Lymn wrote:
> 
> > OK, does phase 2 actually complete?
> 
> I doubt that. Currently I'm not even sure whether phase 1 completes, because
> the phase1-up script is never called. On the other hand the phase1-down
> script is called, as soon as the connection is terminated.
> 

Well, it does seem to get close see below.

> 
> > What does a "setkey -aD" output?
> 
> No SAD entries. And no SPD entries either.
> I guess they would be added by the phase1-up script...?
> 

In the logs you can see the SAD entries get created but they get removed
when the connection gets torn down.

> 
> > Have you tried a tcpdump to see what is going on at the network level?
> 
> Yes, always. I have attached the tcpdump from my client and the vpn-status
> log of the Lancom-router (the VPN "server").
> 

That's helpful.  I normally use -s 0 -x with my tcpdump so I can see
what is in the packets but it may not be very useful here.

> 
> > You should expect encrypted packets, if you are seeing stuff in the
> > clear then check your routing and ensure the packets are properly
> > routed to the vpn tunnel end point.
> 
> This is something to worry about as soon as both phases have been completed,
> which definitely is not the case. ;)
> 

Well, there is a chance that the negotiation was failing due to packets
not going where you expect.  That doesn't appear to be happening but
checking the simple things can't hurt and can save a lot of grief :)

> 
> > It has been a long while since I played with this but I seem to recall
> > that you do get a log of what is being proposed by both sides.
> 
> The proposal is accepted (refer to the Lancom VPN log).
> 

Yes and by NetBSD too, you can actually see the phase 1 has completed in
the racoon logs but then the SA gets removed.

> Looking at the tcpdump I wonder why the NetBSD client says it is exchanging
> "isakmp: phase 2" packets, while the Lancom still calls these isakmp
> notifies "Phase-1 SA"?
> 

As Greg said, this is probably just terminology, I wouldn't get hung up
on that too much.


OK, lets have a bit of a look at the logs and see what is going on...

> Mar  1 11:52:07 powerbook racoon: [1.2.3.4] INFO: received INITIAL-CONTACT 
> Mar  1 11:52:07 powerbook racoon: INFO: ISAKMP-SA established 
> 192.168.1.5[4500]-1.2.3.4[4500] spi:4da2f5f910bbdf44:444ae08dd7de45a5 

This is good - we have a security association here, note the SPI numbers
here, they will be useful later.

> Mar  1 11:53:12 powerbook racoon: [1.2.3.4] INFO: DPD: remote (ISAKMP-SA 
> spi=4da2f5f910bbdf44:444ae08dd7de45a5) seems to be dead. 
> Mar  1 11:53:12 powerbook racoon: INFO: purging ISAKMP-SA 
> spi=4da2f5f910bbdf44:444ae08dd7de45a5. 
> Mar  1 11:53:12 powerbook racoon: INFO: purged ISAKMP-SA 
> spi=4da2f5f910bbdf44:444ae08dd7de45a5. 
> Mar  1 11:53:12 powerbook racoon: INFO: ISAKMP-SA deleted 
> 192.168.1.5[4500]-1.2.3.4[4500] spi:4da2f5f910bbdf44:444ae08dd7de45a5 
> Mar  1 11:53:12 powerbook racoon: INFO: KA remove: 
> 192.168.1.5[4500]->1.2.3.4[4500] 

Then the SA gets torn down.

> 11:52:06.441891 IP 192.168.1.5.500 > 1.2.3.4.500: isakmp: phase 1 I ident

Nothing really out of place in the tcpdump...

the log from the other side is interesting:

> 
> [VPN-Status] 2016/03/01 11:52:07,096
> IKE info: exchange_finalize: assuming identified for road-warrior with cert, 
> id=VPNCLIENT15EF90, RemoteGW=91.56.237.127
> 
> 
> [VPN-Status] 2016/03/01 11:52:07,121
> IKE info: Phase-1 [responder] for peer VPNCLIENT15EF90 initiator id 
> CN=VPNCLIENT15,O=WPS,C=DE,L=HERFORD,ST=NRW,OU=IT,postalCode=32052, responder 
> id CN=ZENTRALE,O=WPS,C=DE,L=HERFORD,ST=NRW,OU=IT,postalCode=32052
> IKE info: initiator cookie: 0x4da2f5f910bbdf44, responder cookie: 
> 0x444ae08dd7de45a5
> IKE info: NAT-T enabled in mode rfc, we are not behind a nat, the remote side 
> is  behind a nat
> IKE info: SA ISAKMP for peer VPNCLIENT15EF90 encryption aes-cbc 
> authentication MD5
> IKE info: life time ( 28800 sec/ 0 kb) DPD 0 sec
> 

This is good - we have a phase 1 done here, note the initiator and
responder cookies match the SPI numbers from the NetBSD side.  Looking
good at this point.

> 
> [VPN-Status] 2016/03/01 11:52:23,541
> IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE sent for Phase-1 SA to peer 
> VPNCLIENT15EF90, sequence nr 0x7a8b3f4b
> 
> 
> [VPN-Status] 2016/03/01 11:52:23,614
> IKE info: NOTIFY received of type ISAKMP_NOTIFY_DPD_R_U_THERE_ACK for peer 
> VPNCLIENT15EF90 Seq-Nr 0x7a8b3f4b, expected 0x7a8b3f4b
> 

This is good, we see a query and response

> 
> [VPN-Status] 2016/03/01 11:52:27,223
> IKE info: NOTIFY received of type ISAKMP_NOTIFY_DPD_R_U_THERE for peer 
> VPNCLIENT15EF90 Seq-Nr 0xe8, expected 0xe8
> 
> 
> [VPN-Status] 2016/03/01 11:52:27,224
> IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE_ACK sent for Phase-1 SA to peer 
> VPNCLIENT15EF90, sequence nr 0xe8
> 

OK and here is where things fall apart.  The client sends an "are you
there" request and vpn server sends

Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-01 Thread Greg Troxel 

Frank Wille  writes:

  >> What does a "setkey -aD" output?

  > No SAD entries. And no SPD entries either.
  > I guess they would be added by the phase1-up script...?

In my experience, SPD entries are added outside of racoon to tell the
kernel that certain traffic should have IPsec protection.   I don't
understand how in your setup that's supposed to work, or what is
triggering racoon to start the negotiation.

> Looking at the tcpdump I wonder why the NetBSD client says it is exchanging
> "isakmp: phase 2" packets, while the Lancom still calls these isakmp
> notifies "Phase-1 SA"?
>
> IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE sent for Phase-1 SA to peer
> VPNCLIENT15EF90, sequence nr 0x7a8b3f4b

I think this is ok.   I have not read the specs in a long time, but I
think that notifications (INITIAL_CONTACT, DPD, etc.) are sent as phase
2 other messages (meaning they are protected in the phase 1 SA), but are
considered control messages about the phase 1 SA.   Other phase 2
messages are used to create a phase 2 SA, which is loaded into the
kernel, and then data flows over that.

So I don't think the 1/2 terminology difference about notifies is a problem.


signature.asc
Description: PGP signature

Re: Simple IPSEC client with certificate - phase 1 time out

2016-03-01 Thread Frank Wille 
Brett Lymn wrote:

> OK, does phase 2 actually complete?

I doubt that. Currently I'm not even sure whether phase 1 completes, because
the phase1-up script is never called. On the other hand the phase1-down
script is called, as soon as the connection is terminated.


> What does a "setkey -aD" output?

No SAD entries. And no SPD entries either.
I guess they would be added by the phase1-up script...?


> Have you tried a tcpdump to see what is going on at the network level?

Yes, always. I have attached the tcpdump from my client and the vpn-status
log of the Lancom-router (the VPN "server").


> You should expect encrypted packets, if you are seeing stuff in the
> clear then check your routing and ensure the packets are properly
> routed to the vpn tunnel end point.

This is something to worry about as soon as both phases have been completed,
which definitely is not the case. ;)


> It has been a long while since I played with this but I seem to recall
> that you do get a log of what is being proposed by both sides.

The proposal is accepted (refer to the Lancom VPN log).

Looking at the tcpdump I wonder why the NetBSD client says it is exchanging
"isakmp: phase 2" packets, while the Lancom still calls these isakmp
notifies "Phase-1 SA"?

IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE sent for Phase-1 SA to peer
VPNCLIENT15EF90, sequence nr 0x7a8b3f4b

-- 
Frank Wille
Mar  1 11:40:50 powerbook racoon: INFO: @(#)ipsec-tools cvs 
(http://ipsec-tools.sourceforge.net) 
Mar  1 11:40:50 powerbook racoon: INFO: @(#)This product linked OpenSSL 1.0.1p 
9 Jul 2015 (http://www.openssl.org/) 
Mar  1 11:40:50 powerbook racoon: INFO: Reading configuration from 
"/etc/racoon/racoon.conf" 
Mar  1 11:40:50 powerbook racoon: INFO: 192.168.1.5[500] used for NAT-T 
Mar  1 11:40:50 powerbook racoon: INFO: 192.168.1.5[500] used as isakmp port 
(fd=7) 
Mar  1 11:40:50 powerbook racoon: INFO: 192.168.1.5[4500] used for NAT-T 
Mar  1 11:40:50 powerbook racoon: INFO: 192.168.1.5[4500] used as isakmp port 
(fd=8) 
Mar  1 11:40:50 powerbook racoon: INFO: 127.0.0.1[500] used for NAT-T 
Mar  1 11:40:50 powerbook racoon: INFO: 127.0.0.1[500] used as isakmp port 
(fd=9) 
Mar  1 11:40:50 powerbook racoon: INFO: 127.0.0.1[4500] used for NAT-T 
Mar  1 11:40:50 powerbook racoon: INFO: 127.0.0.1[4500] used as isakmp port 
(fd=10) 
Mar  1 11:52:06 powerbook racoon: INFO: accept a request to establish IKE-SA: 
1.2.3.4 
Mar  1 11:52:06 powerbook racoon: INFO: initiate new phase 1 negotiation: 
192.168.1.5[500]<=>1.2.3.4[500] 
Mar  1 11:52:06 powerbook racoon: INFO: begin Identity Protection mode. 
Mar  1 11:52:06 powerbook racoon: INFO: received Vendor ID: 
draft-ietf-ipsec-nat-t-ike-02  
Mar  1 11:52:06 powerbook racoon: INFO: received Vendor ID: 
draft-ietf-ipsec-nat-t-ike-03 
Mar  1 11:52:06 powerbook racoon: INFO: received Vendor ID: RFC 3947 
Mar  1 11:52:06 powerbook racoon: INFO: received Vendor ID: 
draft-ietf-ipsra-isakmp-xauth-06.txt 
Mar  1 11:52:06 powerbook racoon: INFO: received Vendor ID: DPD 
Mar  1 11:52:06 powerbook racoon: [1.2.3.4] INFO: Selected NAT-T version: RFC 
3947 
Mar  1 11:52:06 powerbook racoon: [1.2.3.4] INFO: Hashing 1.2.3.4[500] with 
algo #1  
Mar  1 11:52:06 powerbook racoon: [192.168.1.5] INFO: Hashing 192.168.1.5[500] 
with algo #1  
Mar  1 11:52:06 powerbook racoon: INFO: Adding remote and local NAT-D payloads. 
Mar  1 11:52:06 powerbook racoon: [192.168.1.5] INFO: Hashing 192.168.1.5[500] 
with algo #1  
Mar  1 11:52:06 powerbook racoon: INFO: NAT-D payload #0 doesn't match 
Mar  1 11:52:06 powerbook racoon: [1.2.3.4] INFO: Hashing 1.2.3.4[500] with 
algo #1  
Mar  1 11:52:06 powerbook racoon: INFO: NAT-D payload #1 verified 
Mar  1 11:52:06 powerbook racoon: INFO: NAT detected: ME  
Mar  1 11:52:06 powerbook racoon: INFO: KA list add: 
192.168.1.5[4500]->1.2.3.4[4500] 
Mar  1 11:52:07 powerbook racoon: WARNING: unable to get certificate CRL(3) at 
depth:0 
SubjectName:/postalCode=32052/OU=IT/ST=NRW/L=HERFORD/C=DE/O=WPS/CN=ZENTRALE 
Mar  1 11:52:07 powerbook racoon: WARNING: unable to get certificate CRL(3) at 
depth:1 SubjectName:/C=DE/O=LANCOM SYSTEMS/CN=LANCOM CA 
Mar  1 11:52:07 powerbook racoon: [1.2.3.4] INFO: received INITIAL-CONTACT 
Mar  1 11:52:07 powerbook racoon: INFO: ISAKMP-SA established 
192.168.1.5[4500]-1.2.3.4[4500] spi:4da2f5f910bbdf44:444ae08dd7de45a5 
Mar  1 11:53:12 powerbook racoon: [1.2.3.4] INFO: DPD: remote (ISAKMP-SA 
spi=4da2f5f910bbdf44:444ae08dd7de45a5) seems to be dead. 
Mar  1 11:53:12 powerbook racoon: INFO: purging ISAKMP-SA 
spi=4da2f5f910bbdf44:444ae08dd7de45a5. 
Mar  1 11:53:12 powerbook racoon: INFO: purged ISAKMP-SA 
spi=4da2f5f910bbdf44:444ae08dd7de45a5. 
Mar  1 11:53:12 powerbook racoon: INFO: ISAKMP-SA deleted 
192.168.1.5[4500]-1.2.3.4[4500] spi:4da2f5f910bbdf44:444ae08dd7de45a5 
Mar  1 11:53:12 powerbook racoon: INFO: KA remove: 
192.168.1.5[4500]->1.2.3.4[4500] 
11:52:06.441891 IP 192.168.1.5.500 > 1.2.3.4.500: isakmp: phase 1 I ident
11:52:06.500027 IP 1.2.3.4.500 >

Re: Simple IPSEC client with certificate - phase 1 time out

2016-02-29 Thread Brett Lymn 
On Sun, Feb 28, 2016 at 02:35:26PM +0100, Frank Wille wrote:
> 
> I don't even need hybrid or xauth. Just a plain signed certificate on both
> sides. A simple "road-warrior" client. Until now I found no example
> configurations for this case.
> 

Yes, it quite frustrating and complex...

> 
> >  IIRC, looping in phase 1 means both ends cannot agree on an
> > authentication method or the credentials presented are not correct.
> 
> Yes. But phase 1 is definitely ok in my case. I have now access to the
> VPN-status log of my office's Lancom router and it accepted everything:
> 

That is a good start.

> 
> But after 30 seconds and a few Phase 2 Inf messages it just says:
> 

OK, does phase 2 actually complete?  What does a "setkey -aD" output?
Have you tried a tcpdump to see what is going on at the network level?
You should expect encrypted packets, if you are seeing stuff in the
clear then check your routing and ensure the packets are properly routed
to the vpn tunnel end point.

> > Try increasing the debug level on raccoon and see what it is offering
> > to the remote end and see if that matches what you expect.
> 
> I tried everything. IPSEC_DEBUG in the kernel. "log debug2" in racoon.conf
> and starting the racoon daemon with -. I don't get any more information
> out of it.
> 

It has been a long while since I played with this but I seem to recall
that you do get a log of what is being proposed by both sides.  I know
that it doesn't give any clear messages like "we failed because I didn't
like this option" but there should be a lot of transactional information
that can point to a solution.  Are you seeing this?

> 
> Unfortunately that's not possible. I cannot change the configuration of my
> office's router, because it will break the working VPN connection of all
> Windows notebooks.
> 

Yes, that is not surprising but it seems that you are doing phase 1 ok
anyway so I guess there is not much point.

-- 
Brett Lymn
Let go, or be dragged - Zen proverb.

Re: Simple IPSEC client with certificate - phase 1 time out

2016-02-29 Thread Frank Wille 
Brett Lymn wrote:

On 28.02.16 10:18:13 you wrote:

> Once upon a time I did manage to get hybrid xauth working using a
> NetBSD server and windows clients, so certificates did work for me.

I don't even need hybrid or xauth. Just a plain signed certificate on both
sides. A simple "road-warrior" client. Until now I found no example
configurations for this case.


>  IIRC, looping in phase 1 means both ends cannot agree on an
> authentication method or the credentials presented are not correct.

Yes. But phase 1 is definitely ok in my case. I have now access to the
VPN-status log of my office's Lancom router and it accepted everything:

[VPN-Status] 2016/02/29 12:31:52,304
IKE info: Phase-1 [responder] for peer VPNCLIENT15EF90 initiator id
CN=VPNCLIENT15,O=WPS,C=DE,L=HERFORD,ST=NRW,OU=IT,postalCode=32052,
responder id CN=ZENTRALE,O=WPS,C=DE,L=HERFORD,ST=NRW,OU=IT,postalCode=32052
IKE info: initiator cookie: 0x4f5e1f08e12bd21c, responder cookie:
0x2e8dc875b4e07c26
IKE info: NAT-T enabled in mode rfc, we are not behind a nat, the remote
side is  behind a nat
IKE info: SA ISAKMP for peer VPNCLIENT15EF90 encryption aes-cbc
authentication MD5
IKE info: life time ( 28800 sec/ 0 kb) DPD 0 sec


But after 30 seconds and a few Phase 2 Inf messages it just says:

[VPN-Status] 2016/02/29 12:32:22,284
VPN: connection for VPNCLIENT15EF90 (91.56.236.148) timed out: no response

[VPN-Status] 2016/02/29 12:32:22,284
VPN: Error: IFC-R-Connection-timeout-dynamic (0x1205) for VPNCLIENT15EF90
(91.56.236.148)


> Try increasing the debug level on raccoon and see what it is offering
> to the remote end and see if that matches what you expect.

I tried everything. IPSEC_DEBUG in the kernel. "log debug2" in racoon.conf
and starting the racoon daemon with -. I don't get any more information
out of it.


>  If you have
> control over the other end then try simplifying things by using a
> pre-shared key (PSK) method of authentication

Unfortunately that's not possible. I cannot change the configuration of my
office's router, because it will break the working VPN connection of all
Windows notebooks.

Thanks,

-- 
Frank Wille

Re: Simple IPSEC client with certificate - phase 1 time out

2016-02-28 Thread Brett Lymn 
On Fri, Feb 26, 2016 at 11:21:09AM +0100, Frank Wille wrote:
> 
> > Would be really nice if there was an IPSEC secret decoder ring for
> > device compatibility/setup.
> 
> Indeed. Over the last days I wondered that there is only few information
> about IPSEC configuration on the net (especially with signed certificates),
> although the same Racoon software is used in all BSDs, Linux, Android and
> Mac OSX ... :|
> 

It would be nice but ipsec is such a hairy beast and things can change
between firmware vesions of the same device which makes it difficult.

Once upon a time I did manage to get hybrid xauth working using a NetBSD
server and windows clients, so certificates did work for me.  IIRC,
looping in phase 1 means both ends cannot agree on an authentication
method or the credentials presented are not correct.  Try increasing the
debug level on raccoon and see what it is offering to the remote end and
see if that matches what you expect.  If you have control over the other
end then try simplifying things by using a pre-shared key (PSK) method
of authentication, get that working first and then move on to
certificates after.  That way you can start from a known working setup
and focus on certificate problems.

Debugging ipsec is quite awful to do, you don't get a lot of logging and
what you do get can be downright confusing.

-- 
Brett Lymn
Let go, or be dragged - Zen proverb.

Re: Simple IPSEC client with certificate - phase 1 time out

2016-02-26 Thread Frank Wille 
Andy Ruhl wrote:

> It might be worth trying some other OS or device just to sanity check
> it and make sure it CAN work before you assume it's a NetBSD issue.

I know that this Lancom router successfully establishes a connection to
several other Lancom routers and to dozends of Windows clients, running the
Windows Lancom VPN client software.

So the problem is the Racoon configuration under NetBSD.


> Would be really nice if there was an IPSEC secret decoder ring for
> device compatibility/setup.

Indeed. Over the last days I wondered that there is only few information
about IPSEC configuration on the net (especially with signed certificates),
although the same Racoon software is used in all BSDs, Linux, Android and
Mac OSX ... :|

-- 
Frank Wille

Re: Simple IPSEC client with certificate - phase 1 time out

2016-02-25 Thread Andy Ruhl 
On Thu, Feb 25, 2016 at 3:10 PM, Frank Wille  wrote:
> Seems I forgot IPSEC_DEBUG, so I missed important information? I tried it
> again with a 7.0 kernel and IPSEC_DEBUG on my PowerBook and the cause
> turned out to be a bad "authentication_method" in my propsal:
>
> Feb 25 22:30:08 powerbook racoon: [1.2.3.4] ERROR: notification
> NO-PROPOSAL-CHOSEN received in unencrypted informational exchange.
>
> I had to replace "hybrid_rsa_client" by "rsasig" - although I'm not
> completely sure about the difference. I have a signed certificate and don't
> want to use any username or password authentication with xauth, so "rsasig"
> is probably ok...?
>
>
> Now I reach phase 2 and it looks to me that the VPN connection is
> established for a second, but a few seconds later I get "DPD: remote seems
> to be dead". No idea at the moment.
>
> Do I have to worry about "WARNING: unable to get certificate CRL(3)" ?
>
> What does "KA" mean?

Sorry, not a lot of help here, I just felt like replying.

I've been trying to get IPSEC transport mode set up between NetBSD and
a stupid router who's name I won't mention and it's not working. I
tried it with Linux and it's not working. I tried it with another
brand of router and it's not working. I tried the same brand of router
and it works. Probably because all the names of the toggles line up or
something ridiculous like that.

It might be worth trying some other OS or device just to sanity check
it and make sure it CAN work before you assume it's a NetBSD issue.

Would be really nice if there was an IPSEC secret decoder ring for
device compatibility/setup.

Andy

Re: Simple IPSEC client with certificate - phase 1 time out

2016-02-25 Thread Frank Wille 
On 25.02.16 18:52:52 I wrote:

> and the VPN connection
> # racoonctl vc 1.2.3.4
>
> ...it fails very early:
>
> [...]
> Feb 25 17:24:08 arwen racoon: INFO: begin Identity Protection mode. 
> Feb 25 17:24:59 arwen racoon: ERROR: phase1 negotiation failed due to
> time up. 05349d3fe352e138:

Seems I forgot IPSEC_DEBUG, so I missed important information? I tried it
again with a 7.0 kernel and IPSEC_DEBUG on my PowerBook and the cause
turned out to be a bad "authentication_method" in my propsal:

Feb 25 22:30:08 powerbook racoon: [1.2.3.4] ERROR: notification
NO-PROPOSAL-CHOSEN received in unencrypted informational exchange. 

I had to replace "hybrid_rsa_client" by "rsasig" - although I'm not
completely sure about the difference. I have a signed certificate and don't
want to use any username or password authentication with xauth, so "rsasig"
is probably ok...?


Now I reach phase 2 and it looks to me that the VPN connection is
established for a second, but a few seconds later I get "DPD: remote seems
to be dead". No idea at the moment.

Do I have to worry about "WARNING: unable to get certificate CRL(3)" ?

What does "KA" mean?

---8<---
Feb 25 22:31:25 powerbook racoon: INFO: @(#)ipsec-tools cvs
(http://ipsec-tools.sourceforge.net) 
Feb 25 22:31:25 powerbook racoon: INFO: @(#)This product linked OpenSSL
1.0.1p 9 Jul 2015 (http://www.openssl.org/) 
Feb 25 22:31:25 powerbook racoon: INFO: Reading configuration from
"/etc/racoon/racoon.conf" 
Feb 25 22:31:25 powerbook racoon: INFO: 192.168.1.5[500] used for NAT-T 
Feb 25 22:31:25 powerbook racoon: INFO: 192.168.1.5[500] used as isakmp port
(fd=7) 
Feb 25 22:31:25 powerbook racoon: INFO: 192.168.1.5[4500] used for NAT-T 
Feb 25 22:31:25 powerbook racoon: INFO: 192.168.1.5[4500] used as isakmp
port (fd=8) 
Feb 25 22:31:25 powerbook racoon: INFO: 127.0.0.1[500] used for NAT-T 
Feb 25 22:31:25 powerbook racoon: INFO: 127.0.0.1[500] used as isakmp port
(fd=9) 
Feb 25 22:31:25 powerbook racoon: INFO: 127.0.0.1[4500] used for NAT-T 
Feb 25 22:31:25 powerbook racoon: INFO: 127.0.0.1[4500] used as isakmp port
(fd=10) 
Feb 25 22:31:35 powerbook racoon: INFO: accept a request to establish
IKE-SA: 1.2.3.4 
Feb 25 22:31:35 powerbook racoon: INFO: initiate new phase 1 negotiation:
192.168.1.5[500]<=>1.2.3.4[500] 
Feb 25 22:31:35 powerbook racoon: INFO: begin Identity Protection mode. 
Feb 25 22:31:35 powerbook racoon: INFO: received Vendor ID:
draft-ietf-ipsec-nat-t-ike-02  
Feb 25 22:31:35 powerbook racoon: INFO: received Vendor ID:
draft-ietf-ipsec-nat-t-ike-03 
Feb 25 22:31:35 powerbook racoon: INFO: received Vendor ID: RFC 3947 
Feb 25 22:31:35 powerbook racoon: INFO: received Vendor ID:
draft-ietf-ipsra-isakmp-xauth-06.txt 
Feb 25 22:31:35 powerbook racoon: INFO: received Vendor ID: DPD 
Feb 25 22:31:35 powerbook racoon: [1.2.3.4] INFO: Selected NAT-T version:
RFC 3947 
Feb 25 22:31:35 powerbook racoon: [1.2.3.4] INFO: Hashing 1.2.3.4[500] with
algo #1  
Feb 25 22:31:35 powerbook racoon: [192.168.1.5] INFO: Hashing
192.168.1.5[500] with algo #1  
Feb 25 22:31:35 powerbook racoon: INFO: Adding remote and local NAT-D
payloads. 
Feb 25 22:31:35 powerbook racoon: [192.168.1.5] INFO: Hashing
192.168.1.5[500] with algo #1  
Feb 25 22:31:35 powerbook racoon: INFO: NAT-D payload #0 doesn't match 
Feb 25 22:31:35 powerbook racoon: [1.2.3.4] INFO: Hashing 1.2.3.4[500] with
algo #1  
Feb 25 22:31:35 powerbook racoon: INFO: NAT-D payload #1 verified 
Feb 25 22:31:35 powerbook racoon: INFO: NAT detected: ME  
Feb 25 22:31:35 powerbook racoon: INFO: KA list add:
192.168.1.5[4500]->1.2.3.4[4500] 
Feb 25 22:31:36 powerbook racoon: WARNING: unable to get certificate CRL(3)
at depth:0
SubjectName:/postalCode=32052/OU=IT/ST=NRW/L=HERFORD/C=DE/O=WPS/CN=ZENTRALE

Feb 25 22:31:36 powerbook racoon: WARNING: unable to get certificate CRL(3)
at depth:1 SubjectName:/C=DE/O=LANCOM SYSTEMS/CN=LANCOM CA 
Feb 25 22:31:36 powerbook racoon: [1.2.3.4] INFO: received INITIAL-CONTACT 
Feb 25 22:31:36 powerbook racoon: INFO: ISAKMP-SA established
192.168.1.5[4500]-1.2.3.4[4500] spi:554e0ed2b394bee9:df77769896bfb2bd 
Feb 25 22:32:42 powerbook racoon: [1.2.3.4] INFO: DPD: remote (ISAKMP-SA
spi=554e0ed2b394bee9:df77769896bfb2bd) seems to be dead. 
Feb 25 22:32:42 powerbook racoon: INFO: purging ISAKMP-SA
spi=554e0ed2b394bee9:df77769896bfb2bd. 
Feb 25 22:32:42 powerbook racoon: INFO: purged ISAKMP-SA
spi=554e0ed2b394bee9:df77769896bfb2bd. 
Feb 25 22:32:42 powerbook racoon: INFO: ISAKMP-SA deleted
192.168.1.5[4500]-1.2.3.4[4500] spi:554e0ed2b394bee9:df77769896bfb2bd 
Feb 25 22:32:42 powerbook racoon: INFO: KA remove:
192.168.1.5[4500]->1.2.3.4[4500] 
---8<---

-- 
Frank Wille