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