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

[Matthew Grooms]

All,

I have had a few off-list messages recently regarding improved Juniper 
SRX and Watchguard support. We now have a new Watchguard XTM-25 in our 
lab and a Juniper SRX on the way. I will also be taking a look at DHCP 
over IPsec with Fortigate. We will be making progress in these areas 
soon and will be the primary focus of the 2.3.x release series.

Thanks,

-Matthew

On 12/18/2012 10:35 PM, 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