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

Wed Dec 19 02:30:05 CST 2012

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