[vpn-help] Shrew VPN Client + Juniper SRX : Autodisconnect

Wed Dec 19 04:45:20 CST 2012

Hello all,

Thanks a lot for the explanation Matthew !

My usage of Shrew is focused on the Linux version so i'll keep on with 
Pulse on Windows for now.

However i've seen a post saying that this should work with nasty settings :

"I got the same problem with Shrew and SRX: disconnects consistently 
after 200 sec.
The workaround is to set Phase1 key life time to 180 sec while keeping 
Phase2 key life time on default 28800. This will force a rekey before 
the SA is deleted from the SRX. Tunnel connectivity is not disrupted and 
the tunnels stays up.
Have been testing the tunnel using icmp for the last hour and get 
occasional spikes of 70ms delay, I guess because of the rekey (min 
latency is 35ms and avg is 40ms).
Tested with SRX210H running Junos 11.4r2.1 and Shrew 2.1.6 on Windows 
and on Linux (Ubuntu). "

http://forums.juniper.net/t5/SRX-Services-Gateway/Can-SRX-series-work-with-Shrew-Soft-VPN-client/td-p/76176

Tried that but didn't work for me (In my case the tunnel stays up less 
than 180s). Any thoughts Matthew ?

Anyway, thanks for trying to fix it in a near future, very much appreciated.

I have a spare SRX240H in my lab, I can copy my production config and 
test the alpha/beta Shrew releases for you if you need debugging. 
Private mail me and I would be happy to assist !

Best regards,
Thanks again,
Greg

Le 19/12/2012 09:30, Jeroen J.A.W. Hermans a écrit :
> Hello Matthew,
>
> Sorry that i wasn't able to provide you with debugging information 
> because it is a live system now. Thank you for figuring this one out! 
> I am good for now (Pulse client) but the Pulse client is rather 
> limited. I'll see if i can set up a "test" dynamic VPN on the SRX so i 
> can test your new software once it is finished in the new year.
> Kind regards,
>
> Jeroen
>
> On 19-12-2012 5:35, Matthew Grooms wrote:
>> Gregory and Jeron,
>>
>> I took a closer look at the logs tonight and compared them against 
>> the Juniper SSG in my lab. It's pretty clear whats going on but it 
>> won't be possible to fix without a rewrite of the modecfg code on the 
>> Shrew Soft VPN client, which is probably needed anyway. So here is 
>> the detail ...
>>
>> Modecfg is a generic way for one side of a connection to send a 
>> REQUEST for which the other side responds with a REPLY. Alternately, 
>> one side can send a SET for which the other side responds with a ACK. 
>> However, Xauth ( extended user authentication ) is built on top of 
>> Modecfg which gets mixed in with  negotiating configuration info like 
>> IP address, netmasks and DNS settings. To make things even more 
>> complicated, there are two ways to negotiate the configuration 
>> settings. These methods are commonly referred to as a PUSH or a PULL, 
>> where the server pushes configuration settings to the client or the 
>> client pulls configuration settings from the server.
>>
>> In any case, the way Juniper used to do things is like this ...
>>
>> SERVER -> CLIENT : REQUEST [ XAUTH USERNAME/PASSWORD ]
>> CLIENT -> SERVER : REPLY [ XAUTH USERNAME/PASSWORD ]
>> SERVER -> CLIENT : SET [ ADDRESS/NETMASK/ETC... ]
>> CLIENT -> SERVER : ACK [ ADDRESS/NETMASK/ETC... ]
>> SERVER -> CLIENT : SET [ XAUTH RESULT ]
>> CLIENT -> SERVER : ACK [ XAUTH RESULT ]
>>
>> Now, I always thought it was strange that they proceeded to configure 
>> the client address/netmask/etc.. before sending the AUTH result. In 
>> fact, when I read the RFC draft, I wrote the server side support in 
>> the Shrew Soft IKE daemon differently for PUSH mode because I thought 
>> that whoever wrote the Juniper version had completely mus-interpreted 
>> the specification ...
>>
>> http://tools.ietf.org/id/draft-ietf-ipsec-isakmp-mode-cfg-05.txt
>>
>> In any case, Juniper has changed it's mind about things and now they 
>> do things like this ...
>>
>> SERVER -> CLIENT : REQUEST [ XAUTH USERNAME/PASSWORD ]
>> CLIENT -> SERVER : REPLY [ XAUTH USERNAME/PASSWORD ]
>> SERVER -> CLIENT : SET [ XAUTH RESULT ]
>> CLIENT -> SERVER : ACK [ XAUTH RESULT ]
>> SERVER -> CLIENT : SET [ ADDRESS/NETMASK/ETC... ]
>> CLIENT -> SERVER : ACK [ ADDRESS/NETMASK/ETC... ]
>>
>> Makes more sense right? :) But unfortunately, the information in the 
>> packet header doesn't denote if it's part of Xauth or if it's part of 
>> another configuration exchange. For example ...
>>
>> SERVER -> CLIENT : SET [ ???? ]
>>
>> ... Is this Modecfg packet related to Xauth or other configuration 
>> data? There are two ways to go about it ...
>>
>> 1) Follow a strict order based on the gateway your dealing with and 
>> process the packet with the expectation that certain attributes will 
>> be present as the Xauth/Config process progresses.
>>
>> 2) Do a generic parse of the packet, look for specific attributes 
>> that are related to some type of config exchange ( XAUTH, Config ) 
>> and then take specific action based on those attributes.
>>
>> When I instrumented the Xauth code in the Shrew Soft client, I chose 
>> option (1). But now that Juniper has changed the order in which they 
>> do things, that has obviously broke our processing. In other words, 
>> this is the outcome ...
>>
>> SERVER -> CLIENT : REQUEST [ XAUTH USERNAME/PASSWORD ]
>> CLIENT -> SERVER : REPLY [ XAUTH USERNAME/PASSWORD ]
>> SERVER -> CLIENT : SET [ XAUTH RESULT ]
>> CLIENT -> SERVER : ACK [ ADDRESS/NETMASK/ETC... ]
>> SERVER -> CLIENT : SET [ ADDRESS/NETMASK/ETC... ]
>> CLIENT -> SERVER : ACK [ XAUTH RESULT ]
>>
>> So, the only way to correct this is to unwind the rather complex code 
>> that handles Xauth/Config and build an even more complicated state 
>> machine that can be more adaptive to unpredicted server behavior. 
>> This will definately not happen for the 2.2.0 release, but I'd like 
>> to put more time into it after the 1st of the year and make the new 
>> code part of the next release.
>>
>> Sorry I can't be more help at the moment. I will get it fixed but it 
>> will take some time.
>>
>> Thanks again for the bug report and related debug output,
>>
>> -Matthew
>>
>> On 12/18/2012 12:54 PM, Matthew Grooms wrote:
>>> Gregory,
>>>
>>> Thanks for sending me the log. Very interesting indeed. There 
>>> appears to
>>> be a logic bug in the client with respect to the SRX modecfg push
>>> exchange sequence. This works fine with my SSG but unfortunately not
>>> with an SRX ( I don't have one of these ). I'll need to examine the
>>> packet exchange more closely later tonight when I have time.
>>>
>>> Thanks,
>>>
>>> -Matthew
>>>
>>
>> _______________________________________________
>> vpn-help mailing list
>> vpn-help at lists.shrew.net
>> http://lists.shrew.net/mailman/listinfo/vpn-help
>
> _______________________________________________
> vpn-help mailing list
> vpn-help at lists.shrew.net
> http://lists.shrew.net/mailman/listinfo/vpn-help