How to reduce MTU for a VPN tunnel?

[Marc Haber-6]

Hi,

I am having issues with Windows clients using Microsoft Office
Communicator through an NSR VPN. Client is Windows XP SP2 with NSR
Client 10.3.5 (Build 6). I suspect this is an MTU issue.

When the Client is accessing the Live Communication Server directly,
everything is fine:

18:51:39.770881 IP 10.2.203.101.2247 > 10.1.2.15.5060: S 1182056209:1182056209(0) win 65535 <mss 1380,nop,nop,sackOK>
18:51:39.770990 IP 10.1.2.15.5060 > 10.2.203.101.2247: S 689666419:689666419(0) ack 1182056210 win 16384 <mss 1460,nop,nop,sackOK>
18:51:39.771223 IP 10.2.203.101.2247 > 10.1.2.15.5060: . ack 1 win 65535
18:51:39.774990 IP 10.2.203.101.2247 > 10.1.2.15.5060: P 1:662(661) ack 1 win 65535
18:51:39.775340 IP 10.1.2.15.5060 > 10.2.203.101.2247: P 1:562(561) ack 662 win 64874
18:51:39.834843 IP 10.2.203.101.2247 > 10.1.2.15.5060: . 662:2042(1380) ack 562 win 64974
18:51:39.834956 IP 10.2.203.101.2247 > 10.1.2.15.5060: . 2042:3422(1380) ack 562 win 64974
18:51:39.835055 IP 10.2.203.101.2247 > 10.1.2.15.5060: . 3422:4802(1380) ack 562 win 64974
18:51:39.835123 IP 10.1.2.15.5060 > 10.2.203.101.2247: . ack 3422 win 65535
18:51:39.835243 IP 10.1.2.15.5060 > 10.2.203.101.2247: . ack 4802 win 65535
18:51:39.835501 IP 10.2.203.101.2247 > 10.1.2.15.5060: . 4802:6182(1380) ack 562 win 64974
18:51:39.835547 IP 10.2.203.101.2247 > 10.1.2.15.5060: P 6182:6877(695) ack 562 win 64974

We see the 3-way handshake, then two small packets, and then packets
in the size range of the network MTU.

When the Client is going through the VPN, things go wrong badly:

18:53:44.028012 IP 10.2.90.44.2270 > 10.1.2.15.5060: S 3728511120:3728511120(0) win 16384 <mss 1280,nop,nop,sackOK>
18:53:44.028108 IP 10.1.2.15.5060 > 10.2.90.44.2270: S 2496991569:2496991569(0) ack 3728511121 win 16384 <mss 1460,nop,nop,sackOK>
18:53:44.029649 IP 10.2.90.44.2270 > 10.1.2.15.5060: . ack 1 win 16640
18:53:44.035088 IP 10.2.90.44.2270 > 10.1.2.15.5060: P 1:660(659) ack 1 win 16640
18:53:44.035441 IP 10.1.2.15.5060 > 10.2.90.44.2270: P 1:561(560) ack 660 win 64876
18:53:46.977653 IP 10.1.2.15.5060 > 10.2.90.44.2270: P 1:561(560) ack 660 win 64876
18:53:46.981193 IP 10.2.90.44.2270 > 10.1.2.15.5060: . ack 561 win 16080
18:53:47.119140 IP 10.1.2.11.445 > 10.2.203.101.2231: R 3473789694:3473789694(0) ack 3036828448 win 0

We again see the 3-way handshake, then two small packets, and where
ther "serious" data transfer should start, we run into a timeout.

Path MTU discovery seems to be fairly OK, I can ping with long packets:

18:55:48.857712 IP 10.2.90.44 > 10.1.2.15: icmp 1296: echo request seq 1024
18:55:48.857720 IP 10.2.90.44 > 10.1.2.15: icmp
18:55:48.857982 IP 10.1.2.15 > 10.2.90.44: icmp 1480: echo reply seq 1024
18:55:48.857993 IP 10.1.2.15 > 10.2.90.44: icmp
18:55:49.865428 IP 10.2.90.44 > 10.1.2.15: icmp 1296: echo request seq 1280
18:55:49.865434 IP 10.2.90.44 > 10.1.2.15: icmp
18:55:49.865685 IP 10.1.2.15 > 10.2.90.44: icmp 1480: echo reply seq 1280
18:55:49.865698 IP 10.1.2.15 > 10.2.90.44: icmp
18:55:50.866921 IP 10.2.90.44 > 10.1.2.15: icmp 1296: echo request seq 1536
18:55:50.866928 IP 10.2.90.44 > 10.1.2.15: icmp
18:55:50.867183 IP 10.1.2.15 > 10.2.90.44: icmp 1480: echo reply seq 1536
18:55:50.867193 IP 10.1.2.15 > 10.2.90.44: icmp
18:55:51.868360 IP 10.2.90.44 > 10.1.2.15: icmp 1296: echo request seq 1792
18:55:51.868367 IP 10.2.90.44 > 10.1.2.15: icmp
18:55:51.868608 IP 10.1.2.15 > 10.2.90.44: icmp 1480: echo reply seq 1792
18:55:51.868620 IP 10.1.2.15 > 10.2.90.44: icmp

Users claim that the issue with the Office Communicator started when
the Netscren 5 GT which terminates the VPN tunnel (and has an "allow
all" policy in place) was updated to ScreenOS 5.3.0r6.0 from some 5.0
or 5.1 version a few weeks ago.

Now my questions

(1) Are there any known MTU issues in ScreenOS 5.3.0r6.0 for the 5GT?
(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)
(3) Why do such MTU issues only surface with one application?
    Everything else seems to be just fine.
(4) Which debugging steps would you guys take?

Any hints wil be appreciated.

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@...
http://qorbit.net/mailman/listinfo/nn

[Matt Florido]

* Marc Haber <mh+qorbit-nn@...> [03-23-2007 19:18]:

> Hi,
>
> Now my questions
>
> (1) Are there any known MTU issues in ScreenOS 5.3.0r6.0 for the 5GT?

Nothing major listed in the release notes.

> (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.

> (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.

> (4) Which debugging steps would you guys take?
>
> Any hints wil be appreciated.
>
> Greetings
> Marc
>

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)

--
Regards,
Matt Florido
_______________________________________________
nn mailing list
nn@...
http://qorbit.net/mailman/listinfo/nn

[Marc Haber-6]

On Tue, Mar 27, 2007 at 06:53:39AM -0800, Matt Florido wrote:
> * Marc Haber <mh+qorbit-nn@...> [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@...
http://qorbit.net/mailman/listinfo/nn

[Tim E]

Marc,

The MTU setting is a system wide configuration. To view this use the "get envar" command.

netscreen(M)-> get envar
>                    redirect output show resource variable
|                    match output

       
netscreen(M)-> get envar
default_image=ns5000.5.0.0
run_image=default (ns5000.5.0.0)
loader_version=1.0.0
last_reset=2006-11-11 13:44:12 by netscreen
max-frame-size=9830

The example above is a jumbo configuration. Normally the max-frame size should be 1514. To adjust the MTU you use the following command:

set envar max-frame-size=1514

That would change this to 1514. If you want to go smaller..that is how you would do it.

Good luck!

Tim Eberhard

On 3/27/07, Marc Haber <mh+qorbit-nn@...> wrote:

On Tue, Mar 27, 2007 at 06:53:39AM -0800, Matt Florido wrote:
> * Marc Haber < mh+qorbit-nn@...> [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@...
http://qorbit.net/mailman/listinfo/nn

_______________________________________________
nn mailing list
nn@...
http://qorbit.net/mailman/listinfo/nn

[Joekim13]

Which hardware are you using? if its an asic based such as ISG2k or NS5200 and your using Vsys or vlans try 5.4r3.

Also you can try adjusting MSS values.

set flow tcp mss 1400(default) try lowering to 1200.
and
set flow max-frag-pkt-size (60 bytes less than mss)


Joe

Marc Haber-6 wrote:

Hi,

I am having issues with Windows clients using Microsoft Office
Communicator through an NSR VPN. Client is Windows XP SP2 with NSR
Client 10.3.5 (Build 6). I suspect this is an MTU issue.

When the Client is accessing the Live Communication Server directly,
everything is fine:

18:51:39.770881 IP 10.2.203.101.2247 > 10.1.2.15.5060: S 1182056209:1182056209(0) win 65535 <mss 1380,nop,nop,sackOK>
18:51:39.770990 IP 10.1.2.15.5060 > 10.2.203.101.2247: S 689666419:689666419(0) ack 1182056210 win 16384 <mss 1460,nop,nop,sackOK>
18:51:39.771223 IP 10.2.203.101.2247 > 10.1.2.15.5060: . ack 1 win 65535
18:51:39.774990 IP 10.2.203.101.2247 > 10.1.2.15.5060: P 1:662(661) ack 1 win 65535
18:51:39.775340 IP 10.1.2.15.5060 > 10.2.203.101.2247: P 1:562(561) ack 662 win 64874
18:51:39.834843 IP 10.2.203.101.2247 > 10.1.2.15.5060: . 662:2042(1380) ack 562 win 64974
18:51:39.834956 IP 10.2.203.101.2247 > 10.1.2.15.5060: . 2042:3422(1380) ack 562 win 64974
18:51:39.835055 IP 10.2.203.101.2247 > 10.1.2.15.5060: . 3422:4802(1380) ack 562 win 64974
18:51:39.835123 IP 10.1.2.15.5060 > 10.2.203.101.2247: . ack 3422 win 65535
18:51:39.835243 IP 10.1.2.15.5060 > 10.2.203.101.2247: . ack 4802 win 65535
18:51:39.835501 IP 10.2.203.101.2247 > 10.1.2.15.5060: . 4802:6182(1380) ack 562 win 64974
18:51:39.835547 IP 10.2.203.101.2247 > 10.1.2.15.5060: P 6182:6877(695) ack 562 win 64974

We see the 3-way handshake, then two small packets, and then packets
in the size range of the network MTU.

When the Client is going through the VPN, things go wrong badly:

18:53:44.028012 IP 10.2.90.44.2270 > 10.1.2.15.5060: S 3728511120:3728511120(0) win 16384 <mss 1280,nop,nop,sackOK>
18:53:44.028108 IP 10.1.2.15.5060 > 10.2.90.44.2270: S 2496991569:2496991569(0) ack 3728511121 win 16384 <mss 1460,nop,nop,sackOK>
18:53:44.029649 IP 10.2.90.44.2270 > 10.1.2.15.5060: . ack 1 win 16640
18:53:44.035088 IP 10.2.90.44.2270 > 10.1.2.15.5060: P 1:660(659) ack 1 win 16640
18:53:44.035441 IP 10.1.2.15.5060 > 10.2.90.44.2270: P 1:561(560) ack 660 win 64876
18:53:46.977653 IP 10.1.2.15.5060 > 10.2.90.44.2270: P 1:561(560) ack 660 win 64876
18:53:46.981193 IP 10.2.90.44.2270 > 10.1.2.15.5060: . ack 561 win 16080
18:53:47.119140 IP 10.1.2.11.445 > 10.2.203.101.2231: R 3473789694:3473789694(0) ack 3036828448 win 0

We again see the 3-way handshake, then two small packets, and where
ther "serious" data transfer should start, we run into a timeout.

Path MTU discovery seems to be fairly OK, I can ping with long packets:

18:55:48.857712 IP 10.2.90.44 > 10.1.2.15: icmp 1296: echo request seq 1024
18:55:48.857720 IP 10.2.90.44 > 10.1.2.15: icmp
18:55:48.857982 IP 10.1.2.15 > 10.2.90.44: icmp 1480: echo reply seq 1024
18:55:48.857993 IP 10.1.2.15 > 10.2.90.44: icmp
18:55:49.865428 IP 10.2.90.44 > 10.1.2.15: icmp 1296: echo request seq 1280
18:55:49.865434 IP 10.2.90.44 > 10.1.2.15: icmp
18:55:49.865685 IP 10.1.2.15 > 10.2.90.44: icmp 1480: echo reply seq 1280
18:55:49.865698 IP 10.1.2.15 > 10.2.90.44: icmp
18:55:50.866921 IP 10.2.90.44 > 10.1.2.15: icmp 1296: echo request seq 1536
18:55:50.866928 IP 10.2.90.44 > 10.1.2.15: icmp
18:55:50.867183 IP 10.1.2.15 > 10.2.90.44: icmp 1480: echo reply seq 1536
18:55:50.867193 IP 10.1.2.15 > 10.2.90.44: icmp
18:55:51.868360 IP 10.2.90.44 > 10.1.2.15: icmp 1296: echo request seq 1792
18:55:51.868367 IP 10.2.90.44 > 10.1.2.15: icmp
18:55:51.868608 IP 10.1.2.15 > 10.2.90.44: icmp 1480: echo reply seq 1792
18:55:51.868620 IP 10.1.2.15 > 10.2.90.44: icmp

Users claim that the issue with the Office Communicator started when
the Netscren 5 GT which terminates the VPN tunnel (and has an "allow
all" policy in place) was updated to ScreenOS 5.3.0r6.0 from some 5.0
or 5.1 version a few weeks ago.

Now my questions

(1) Are there any known MTU issues in ScreenOS 5.3.0r6.0 for the 5GT?
(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)
(3) Why do such MTU issues only surface with one application?
    Everything else seems to be just fine.
(4) Which debugging steps would you guys take?

Any hints wil be appreciated.

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
[e-mail]
http://qorbit.net/mailman/listinfo/nn

[Joekim13]

I didn't see you already tried adjusting MSS.

Try upgrading to 5.4r3. I've had something similar.

Joe

Which hardware are you using? if its an asic based such as ISG2k or NS5200 and your using Vsys or vlans try 5.4r3.

Also you can try adjusting MSS values.

set flow tcp mss 1400(default) try lowering to 1200.
and
set flow max-frag-pkt-size (60 bytes less than mss)


Joe

Marc Haber-6 wrote:

Hi,

I am having issues with Windows clients using Microsoft Office
Communicator through an NSR VPN. Client is Windows XP SP2 with NSR
Client 10.3.5 (Build 6). I suspect this is an MTU issue.

When the Client is accessing the Live Communication Server directly,
everything is fine:

18:51:39.770881 IP 10.2.203.101.2247 > 10.1.2.15.5060: S 1182056209:1182056209(0) win 65535 <mss 1380,nop,nop,sackOK>
18:51:39.770990 IP 10.1.2.15.5060 > 10.2.203.101.2247: S 689666419:689666419(0) ack 1182056210 win 16384 <mss 1460,nop,nop,sackOK>
18:51:39.771223 IP 10.2.203.101.2247 > 10.1.2.15.5060: . ack 1 win 65535
18:51:39.774990 IP 10.2.203.101.2247 > 10.1.2.15.5060: P 1:662(661) ack 1 win 65535
18:51:39.775340 IP 10.1.2.15.5060 > 10.2.203.101.2247: P 1:562(561) ack 662 win 64874
18:51:39.834843 IP 10.2.203.101.2247 > 10.1.2.15.5060: . 662:2042(1380) ack 562 win 64974
18:51:39.834956 IP 10.2.203.101.2247 > 10.1.2.15.5060: . 2042:3422(1380) ack 562 win 64974
18:51:39.835055 IP 10.2.203.101.2247 > 10.1.2.15.5060: . 3422:4802(1380) ack 562 win 64974
18:51:39.835123 IP 10.1.2.15.5060 > 10.2.203.101.2247: . ack 3422 win 65535
18:51:39.835243 IP 10.1.2.15.5060 > 10.2.203.101.2247: . ack 4802 win 65535
18:51:39.835501 IP 10.2.203.101.2247 > 10.1.2.15.5060: . 4802:6182(1380) ack 562 win 64974
18:51:39.835547 IP 10.2.203.101.2247 > 10.1.2.15.5060: P 6182:6877(695) ack 562 win 64974

We see the 3-way handshake, then two small packets, and then packets
in the size range of the network MTU.

When the Client is going through the VPN, things go wrong badly:

18:53:44.028012 IP 10.2.90.44.2270 > 10.1.2.15.5060: S 3728511120:3728511120(0) win 16384 <mss 1280,nop,nop,sackOK>
18:53:44.028108 IP 10.1.2.15.5060 > 10.2.90.44.2270: S 2496991569:2496991569(0) ack 3728511121 win 16384 <mss 1460,nop,nop,sackOK>
18:53:44.029649 IP 10.2.90.44.2270 > 10.1.2.15.5060: . ack 1 win 16640
18:53:44.035088 IP 10.2.90.44.2270 > 10.1.2.15.5060: P 1:660(659) ack 1 win 16640
18:53:44.035441 IP 10.1.2.15.5060 > 10.2.90.44.2270: P 1:561(560) ack 660 win 64876
18:53:46.977653 IP 10.1.2.15.5060 > 10.2.90.44.2270: P 1:561(560) ack 660 win 64876
18:53:46.981193 IP 10.2.90.44.2270 > 10.1.2.15.5060: . ack 561 win 16080
18:53:47.119140 IP 10.1.2.11.445 > 10.2.203.101.2231: R 3473789694:3473789694(0) ack 3036828448 win 0

We again see the 3-way handshake, then two small packets, and where
ther "serious" data transfer should start, we run into a timeout.

Path MTU discovery seems to be fairly OK, I can ping with long packets:

18:55:48.857712 IP 10.2.90.44 > 10.1.2.15: icmp 1296: echo request seq 1024
18:55:48.857720 IP 10.2.90.44 > 10.1.2.15: icmp
18:55:48.857982 IP 10.1.2.15 > 10.2.90.44: icmp 1480: echo reply seq 1024
18:55:48.857993 IP 10.1.2.15 > 10.2.90.44: icmp
18:55:49.865428 IP 10.2.90.44 > 10.1.2.15: icmp 1296: echo request seq 1280
18:55:49.865434 IP 10.2.90.44 > 10.1.2.15: icmp
18:55:49.865685 IP 10.1.2.15 > 10.2.90.44: icmp 1480: echo reply seq 1280
18:55:49.865698 IP 10.1.2.15 > 10.2.90.44: icmp
18:55:50.866921 IP 10.2.90.44 > 10.1.2.15: icmp 1296: echo request seq 1536
18:55:50.866928 IP 10.2.90.44 > 10.1.2.15: icmp
18:55:50.867183 IP 10.1.2.15 > 10.2.90.44: icmp 1480: echo reply seq 1536
18:55:50.867193 IP 10.1.2.15 > 10.2.90.44: icmp
18:55:51.868360 IP 10.2.90.44 > 10.1.2.15: icmp 1296: echo request seq 1792
18:55:51.868367 IP 10.2.90.44 > 10.1.2.15: icmp
18:55:51.868608 IP 10.1.2.15 > 10.2.90.44: icmp 1480: echo reply seq 1792
18:55:51.868620 IP 10.1.2.15 > 10.2.90.44: icmp

Users claim that the issue with the Office Communicator started when
the Netscren 5 GT which terminates the VPN tunnel (and has an "allow
all" policy in place) was updated to ScreenOS 5.3.0r6.0 from some 5.0
or 5.1 version a few weeks ago.

Now my questions

(1) Are there any known MTU issues in ScreenOS 5.3.0r6.0 for the 5GT?
(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)
(3) Why do such MTU issues only surface with one application?
    Everything else seems to be just fine.
(4) Which debugging steps would you guys take?

Any hints wil be appreciated.

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
[e-mail]
http://qorbit.net/mailman/listinfo/nn

[STEVE KNAPP]

Does anyone know if there is a different command on an ISG-2000?  When I run 'get envar' the MTU size is not returned.

 

spefwfi100(M)-> get envar
default_image=nsISG2000.5.0.0r8.2
run_image=default (nsISG2000.5.0.0r8.2)
loader_version=1.1.5
last_reset=2006-12-20 21:46:47 by admin
.hash-seg=11 (507713657)
sme=

 

 

 

Steve Knapp
Sr. Data Network Engineer
Sallie Mae
11100 USA Parkway
Fishers, IN 46038
Tel:  [phone]
Cell: 317-847-9221
Fax: [phone]


>>> "Tim Eberhard" <xmin0s@...> 3/27/2007 2:58 PM >>>
Marc,

The MTU setting is a system wide configuration. To view this use the "get envar" command.

netscreen(M)-> get envar
>                    redirect output show resource variable
|                    match output

       
netscreen(M)-> get envar
default_image=ns5000.5.0.0
run_image=default (ns5000.5.0.0)
loader_version=1.0.0
last_reset=2006-11-11 13:44:12 by netscreen
max-frame-size=9830

The example above is a jumbo configuration. Normally the max-frame size should be 1514. To adjust the MTU you use the following command:

set envar max-frame-size=1514

That would change this to 1514. If you want to go smaller..that is how you would do it.

Good luck!

Tim Eberhard

On 3/27/07, Marc Haber <mh+qorbit-nn@...> wrote:

On Tue, Mar 27, 2007 at 06:53:39AM -0800, Matt Florido wrote:
> * Marc Haber < mh+qorbit-nn@...> [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@...
http://qorbit.net/mailman/listinfo/nn

This E-Mail has been scanned for viruses.

_______________________________________________
nn mailing list
nn@...
http://qorbit.net/mailman/listinfo/nn

[Tim E]

Some parts of this message have been removed. Learn more about Nabble's security policy.

In the event of the MTU setting not showing up, that means it's set for the default setting 1514. Sometimes it shows up when it's set for default, sometimes it doesn't. It varies from code to code and on different platforms.

On 3/28/07, STEVE KNAPP <SKNAPP@...> wrote:

Does anyone know if there is a different command on an ISG-2000?  When I run 'get envar' the MTU size is not returned.

 

spefwfi100(M)-> get envar
default_image=nsISG2000.5.0.0r8.2
run_image=default (nsISG2000.5.0.0r8.2)
loader_version=1.1.5
last_reset=2006-12-20 21:46:47 by admin
.hash-seg=11 (507713657)
sme=

 

 

 

Steve Knapp
Sr. Data Network Engineer
Sallie Mae
11100 USA Parkway
Fishers, IN 46038
Tel:  [phone]
Cell: 317-847-9221
Fax: [phone]


>>> "Tim Eberhard" < xmin0s@...> 3/27/2007 2:58 PM >>>

Marc,

The MTU setting is a system wide configuration. To view this use the "get envar" command.

netscreen(M)-> get envar
>                    redirect output show resource variable
|                    match output

       
netscreen(M)-> get envar
default_image=ns5000.5.0.0
run_image=default (ns5000.5.0.0)
loader_version=1.0.0
last_reset=2006-11-11 13:44:12 by netscreen
max-frame-size=9830

The example above is a jumbo configuration. Normally the max-frame size should be 1514. To adjust the MTU you use the following command:

set envar max-frame-size=1514

That would change this to 1514. If you want to go smaller..that is how you would do it.

Good luck!

Tim Eberhard

On 3/27/07, Marc Haber <mh+qorbit-nn@...> wrote:

On Tue, Mar 27, 2007 at 06:53:39AM -0800, Matt Florido wrote:
> * Marc Haber < mh+qorbit-nn@...> [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@...
http://qorbit.net/mailman/listinfo/nn

This E-Mail has been scanned for viruses.

_______________________________________________
nn mailing list
nn@...
http://qorbit.net/mailman/listinfo/nn

_______________________________________________
nn mailing list
nn@...
http://qorbit.net/mailman/listinfo/nn

[Marc Haber-6]

On Tue, Mar 27, 2007 at 01:58:43PM -0500, Tim Eberhard wrote:
> The MTU setting is a system wide configuration. To view this use the "get
> envar" command.

I am not sure whether reducing the system-wide MTU of the netscreen
device is going to help here. The MTU of an IPSEC tunnel is always
going to be smaller than that, and in the current case, the client
does not feel like sending a large packet over the tunnel.

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@...
http://qorbit.net/mailman/listinfo/nn