NetScreen
[Top] [All Lists]

Re: [nn] How to reduce MTU for a VPN tunnel?

To: Netscreen Mailing List <nn@qorbit.net>
Subject: Re: [nn] How to reduce MTU for a VPN tunnel?
From: Marc Haber <mh+qorbit-nn@zugschlus.de>
Date: Tue, 27 Mar 2007 19:21:47 +0200
Delivered-to: sp-com-lists@consult.net
Delivered-to: ns-list2@consult.net
Delivered-to: nn@qorbit.net
In-reply-to: <20070327145339.GA30891@floridonet.com>
List-archive: <http://www.qorbit.net/nn>
List-help: <mailto:nn-request@qorbit.net?subject=help>
List-id: "Netscreen mailing list for netscreen admins." <nn.qorbit.net>
List-post: <mailto:nn@qorbit.net>
List-subscribe: <http://qorbit.net/mailman/listinfo/nn>, <mailto:nn-request@qorbit.net?subject=subscribe>
List-unsubscribe: <http://qorbit.net/mailman/listinfo/nn>, <mailto:nn-request@qorbit.net?subject=unsubscribe>
References: <20070323181847.GA11246@torres.zugschlus.de> <20070327145339.GA30891@floridonet.com>
Sender: nn-bounces@qorbit.net
User-agent: Mutt/1.5.9i
On Tue, Mar 27, 2007 at 06:53:39AM -0800, Matt Florido wrote:
> * Marc Haber <mh+qorbit-nn@zugschlus.de> [03-23-2007 19:18]:
> > (2) How can I for testing purposes reduce the MTU the NSR client uses
> >     for data sent into the VPN tunnel? Setting the appropriate registry
> >     key on the virtual ethernet adapter does not work; the setting is
> >     simply igored (verified by ping with a big request packet)
> 
> Try setting the MTU setting on the network adapter itself instead
> of the virtual adapter for NSR.

This does not help since the Tunnel's MTU is always smaller than the
MTU of the physical network.

> > (3) Why do such MTU issues only surface with one application?
> >     Everything else seems to be just fine.
> 
> You have only found it in one application, but I've found the issue
> manifests itself when applications like using max packet sizes.

Both E-Mail (Exchange, Outlook, *blech*) and network shares work fine
even when data sizes well beyond the network MTU are in use.

> Here's something to try.  Adjust the TCP MSS settings on your NS5GT.
> 
> set flow tcp-mss xxx (1300 is a good number to test with)
> set flow all-tcp-mss xxx (1400)

This seems to work fine:

ns5gt-> get config | include mss
set flow tcp-mss 1100
set flow all-tcp-mss 1200
ns5gt-> exit

19:17:04.306354 IP 10.2.90.51.1299 > 10.1.2.92.10000: S 
1765254697:1765254697(0) win 16384 <mss 1200,nop,nop,sackOK>
19:17:04.306590 IP 10.1.2.92.10000 > 10.2.90.51.1299: S 
3882353262:3882353262(0) ack 1765254698 win 5840 <mss 1460,nop,nop,sackOK>
19:17:04.308102 IP 10.2.90.51.1299 > 10.1.2.92.10000: . ack 1 win 16500
19:17:04.317237 IP 10.2.90.51.1299 > 10.1.2.92.10000: . 1:1101(1100) ack 1 win 
16500
19:17:04.317653 IP 10.1.2.92.10000 > 10.2.90.51.1299: . ack 1101 win 7700
19:17:04.318235 IP 10.2.90.51.1299 > 10.1.2.92.10000: . 1101:2201(1100) ack 1 
win 16500
19:17:04.318651 IP 10.1.2.92.10000 > 10.2.90.51.1299: . ack 2201 win 9900
19:17:04.320681 IP 10.2.90.51.1299 > 10.1.2.92.10000: . 2201:3301(1100) ack 1 
win 16500
19:17:04.321095 IP 10.1.2.92.10000 > 10.2.90.51.1299: . ack 3301 win 12100
19:17:04.323427 IP 10.2.90.51.1299 > 10.1.2.92.10000: . 3301:4401(1100) ack 1 
win 16500
19:17:04.323530 IP 10.2.90.51.1299 > 10.1.2.92.10000: . 4401:5501(1100) ack 1 
win 16500
19:17:04.323628 IP 10.2.90.51.1299 > 10.1.2.92.10000: . 5501:6601(1100) ack 1 
win 16500

(10.2.90.51 is the virtual IP of the client, 10.1.2.92 the address of
the "test server").

However, Microsoft Office Communicator still refuses to work:
19:19:31.693440 IP 10.2.90.51.1324 > 10.1.2.15.5060: S 214820639:214820639(0) 
win 16384 <mss 1200,nop,nop,sackOK>
19:19:31.693576 IP 10.1.2.15.5060 > 10.2.90.51.1324: S 2055039840:2055039840(0) 
ack 214820640 win 16384 <mss 1460,nop,nop,sackOK>
19:19:31.695100 IP 10.2.90.51.1324 > 10.1.2.15.5060: . ack 1 win 16500
19:19:31.695456 IP 10.1.2.15.5060 > 10.2.90.51.1301: R 3947954180:3947954180(0) 
ack 3726277644 win 0
19:19:31.751359 IP 10.2.90.51.1324 > 10.1.2.15.5060: P 1:660(659) ack 1 win 
16500
19:19:31.751748 IP 10.1.2.15.5060 > 10.2.90.51.1324: P 1:561(560) ack 660 win 
64876
19:19:34.706224 IP 10.1.2.15.5060 > 10.2.90.51.1324: P 1:561(560) ack 660 win 
64876
19:19:34.710886 IP 10.2.90.51.1324 > 10.1.2.15.5060: . ack 561 win 15940

(10.1.2.15 is the MOC Server)

When I compare the session setup when the client is not connecting
over the VPN to this, I see that the VPN connect stalls when the
non-VPN connect begins transmitting datagrams of like 1360 bytes in
size.

Any more ideas?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835
_______________________________________________
nn mailing list
nn@qorbit.net
http://qorbit.net/mailman/listinfo/nn

<Prev in Thread] Current Thread [Next in Thread>