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

[Matthew Grooms]

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
>