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
[email protected]
http://lists.shrew.net/mailman/listinfo/vpn-help
