On 5/15/2013 9:17 PM, Kevin VPN wrote:
Hi James,
Shrew v2.2.0 supports many more options for negotiating hashes and
transforms for Phase1 and Phase2 connections. Including all the options
in one message makes it larger than the Maximum Transmission Unit
supported by most networks (typically 1500 bytes), so the packet gets
fragmented.
Interestingly, we thought we fixed a problem with fragments just before
the 2.2.0-release version. Is there a chance that you're still using a
a beta/rc version of Shrew 2.2.0?
To avoid the fragmentation problem (i.e. so you can turn block fragments
back on), you can try two things:
1) Manually select the Phase1 and Phase2 options in the Shrew site
configuration (instead of leaving them on auto). That should result in
smaller packets.
2) If you're using the Shrew 2.2.0-release version, you can try to
manually adjust (i.e. reduce) the MTU value for your network adapter
until the fragments disappear.
http://support.microsoft.com/kb/314053
FYI, I'll be traveling for a while, so I won't be active on the list.
Kevin,
As always, thanks for your help and I hope you enjoy your travels :)
James,
If the packet being fragmented is an IKE packet ( during phase1/2
negotiation ), then changing the MTU setting on the virtual adapter
won't have any effect.
As Kevin mentioned, the 2.2.0 version has introduced support for SHA2
HMAC algorithms, which means using 'auto' will produce a larger number
of proposals, and as a result, create larger IKE packets which may be
transmitted as IP fragments. If the gateway is configured to drop
fragmented IP packets, then the phase1/2 settings should be tuned to
remove the use of 'auto'. The way Cisco, Microsoft, ipsec-tools and the
Shrew Soft VPN client works around this is by supporting an IKE
extension called 'IKE Fragmentation'. When in use, a full IKE PDU is
broken up into IKE PDU fragments which are sent individually. The
recipient re-assembles the IKE PDU fragments and processes the message.
Of course, both IKE peers need to support this extension for it to work
but I don't believe Juniper products support this.
Back to the adapter MTU setting: This is for client traffic being sent
from the client to the server after an IPsec SA has been negotiated. If
you take a 1500 byte packet, encrypt it, add headers and then wrap it in
another IP packet, the resulting packet will definitely be larger then
1500 bytes. If you lower the virtual adapter MTU enough, the OS will
naturally create smaller ( inner ) IP packets for client traffic. After
IPsec processing, the resulting packet be small enough to pass without
IP fragmentation.
Hope this helps,
-Matthew
_______________________________________________
vpn-help mailing list
[email protected]
https://lists.shrew.net/mailman/listinfo/vpn-help
