[Vpn-help] next bug- SA failed -release 2.1.0

[Dietmar Papperitz]

Hallo Matthew,

i think it's will be the best you get a lancom.:-) I use a workaround for
setting the IKE lifetime to 86400 sec.

Greetings
Dietmar

-----Ursprüngliche Nachricht-----
Von: vpn-help-bounces at lists.shrew.net
[mailto:vpn-help-bounces at lists.shrew.net] Im Auftrag von Matthew Grooms
Gesendet: Dienstag, 1. Juli 2008 23:23
An: Dietmar Papperitz
Cc: vpn-help at lists.shrew.net
Betreff: Re: [Vpn-help] next bug- SA failed -release 2.1.0

Dietmar Papperitz wrote:
> Hallo Matthew,
> 
> i send the same logs to Lancom Systems. They looked at the logs and have
> seen this different to you. The LC engineers mean that the ShrewSoft VPN
> Client makes the problems. Your client don't send IKE Packets to Lancom.
> Only sending delete notifications for phase2 and phase1. They  said that
all
> implementation is RFC conform.
> 
> Sorry, what should I do? The NCP entry VPN Client and Netgear VPN client
> work perfect with lancom. Both also were tested with a lot of vpn
gateways.
> But for both you must pay a lot of money.
> 

Dietmar,

I have no doubt that both NCP and Netgear clients work fine. I'm sure 
the Lancom device is entirely RFC compliant. I'm also sure the Shrew 
Soft client is also RFC. It renegotiates with Cisco, Juniper, Zywall and 
many open source products without any problems at all. That doesn't mean 
we don't have a problem related to compatibility with Lancom :)

Did you see the log output I returned to you with comments? It clearly 
shows the Lancom device receiving a new phase1 negotiation. If they saw 
the same logs that I did, I don't know why they claim there is no new 
phase1 attempt. I have attached a portion below, with all sensitive 
information removed, that shows the output I am referring to ...

----------------------------------------------------------------------

We already have an ISAKMP established at the top of the log output which 
is being used to protect DPD messages ...

[VPN-Status] 2008/06/24 19:37:23,890
IKE info: NOTIFY received of type ISAKMP_NOTIFY_DPD_R_U_THERE for peer 
XXXXXXX Seq-Nr 0x235b8db5, expected 0x235b8db5

[VPN-Status] 2008/06/24 19:37:23,890
IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE_ACK sent for Phase-1 SA to peer 
XXXXXXX, sequence nr 0x235b8db5

Here we see the client attempting to negotiate a replacement ISAKMP SA 
since the old one is about to die ...

[VPN-Status] 2008/06/24 19:37:29,180
IKE info: The remote server y.y.y.y:500 peer def-main-peer id <no_id> 
supports NAT-T in mode draft
IKE info: The remote server y.y.y.y:500 peer def-main-peer id <no_id> 
supports NAT-T in mode draft
IKE info: The remote server y.y.y.y:500 peer def-main-peer id <no_id> 
supports NAT-T in mode rfc
IKE info: The remote server y.y.y.y:500 peer def-main-peer id <no_id> 
supports NAT-T in mode rfc
IKE info: The remote server y.y.y.y:500 peer def-main-peer id <no_id> 
negotiated rfc-3706-dead-peer-detection
IKE info: The remote server y.y.y.y:500 peer def-main-peer id <no_id> 
supports NAT-T in mode rfc
IKE info: The remote server y.y.y.y:500 peer def-main-peer id <no_id> 
supports NAT-T in mode rfc
IKE info: The remote server y.y.y.y:500 peer def-main-peer id <no_id> 
supports NAT-T in mode rfc
IKE info: The remote server y.y.y.y:500 peer def-main-peer id <no_id> 
supports NAT-T in mode rfc
IKE info: The remote server y.y.y.y:500 peer def-main-peer id <no_id> 
supports NAT-T in mode rfc

[VPN-Status] 2008/06/24 19:37:29,180
IKE info: Phase-1 remote proposal 1 for peer def-main-peer matched with 
local proposal 1

The Lancom says that it matched a local proposal but thats where the 
details end. We don't see any evidence that it responds in this Lancom 
log, the Shrew Soft log or the packet output. Its hard to say what the 
problem might be. We know the Lancom got the packet, we just don't see 
any log errors or any response packet :(
_______________________________________________
vpn-help mailing list
vpn-help at lists.shrew.net
http://lists.shrew.net/mailman/listinfo/vpn-help