[vpn-help] Problem Connecting to Commercial Gateway ...

[Matthew Grooms]

Kimmo Koivisto wrote:
> 
> Beta 4 died in my laptop, it was able to establish IPsec SA, but died couple 
> seconds later.
> 

I would be very interested in seeing the debug output up to the point 
where it dies. This may give me a better clue as to where the problem is 
occurring.

> To understand those problems, can you Matthew answer to these:
> 
> - does shrew support fragmentation for ipsec data? In my vmware environment 
> which might not correspond to real pc, I was able to ping with 3000 bytes 
> without IPsec but with shrew enabled, I could not get more that 14xx bytes 
> through ipsec tunnel. 
> 

There is a 'pre-fragment packets' option in the first config tab that 
enables special fragmentation handling ( ip/esp/frag-ip ). If this 
option is disabled, normal IP fragmentation is performed ( frag-ip/esp/ip ).

> - does shrew support unique tunnels (setkey keywords unique/require).
> 

Absolutely. I will negotiate multiple IPSEC SAs with unique SPIs.

> - When I disconnected shrew, I did not see any SA delete traffic in tcpdump. 
> Should shrew send SA deletes?
> 

At the moment, it fails to send delete or notification messages in 
several instances where the RFC says it is should. This is a deficiency 
and will be corrected before the 1.0 release.

> - How does shrew react when it receives IKE SA delete, does it delete IPsec 
> SA's too or only the IKE SA?
> 

Well, this is what the RFC says about delete payload processing ...

NOTE: The Delete Payload is not a request for the responder to delete
    an SA, but an advisory from the initiator to the responder.  If the
    responder chooses to ignore the message, the next communication from
    the responder to the initiator, using that security association, will
    fail.  A responder is not expected to acknowledge receipt of a Delete
    payload.

... and then later states ...

The Informational Exchange with a Delete Payload provides a
    controlled method of informing a peer entity that the transmitting
    entity has deleted the SA(s).  Deletion of Security Associations MUST
    always be performed under the protection of an ISAKMP SA. The
    receiving entity SHOULD clean up its local SA database.  However,
    upon receipt of a Delete message the SAs listed in the Security
    Parameter Index (SPI) field of the Delete payload cannot be used with
    the transmitting entity.  The SA Establishment procedure must be
    invoked to re-establish secure communications.

Clear as mud isn't it? Right now the delete message is understood but 
ignored. It probably needs to go ahead and cleanup its SA database. I 
will add this to my todo list.

When a tunnel is disabled ( when the client disconnects from the daemon 
), all SA's ( phase1 and phase2 ) are deleted for this peer.

> 
> I don't need WINS, is there any way to configure shrew so that there is no 
> need to configure WINS manually without using mode cfg?
> 

You are not the first person to request this:) I will make it is 
possible with future release of the client. Thanks for the suggestion.

  > I can do that later, just now I only have company provided keypair 
and company
> policy does not allow me to send decode level logs. But I try to set up 
> testing environment with demo certificates so that I can debug my problems.
> 

Right, I understand completely.

>> I have enabled the lifetime kilobytes options in the VPN Access Manager
>> application so that the parameter will be used ( if not set to 0 )
>> during negotiations ( but not enforced for now ). Could you please
>> provide the requested output with and without this option set to match
>> your vpn gateway config.
> 
> Yes, I saw that and tried it too. I'll try it with logging enabled when I have 
> my testing env up and working. 

I had a hunch that this may have worked around the 'responder quick mode 
hash invalid' messages you were seeing. If so, I know exactly what needs 
to be done to correct this. Please let me know the result when you have 
had a chance to test with and without the option set :)

> 
> Regards
> Kimmo
> 

Thanks again Kimmo and sorry to hear about the passing of your laptop,

-Matthew