NetScreen
[Top] [All Lists]

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

To: nn@qorbit.net
Subject: [nn] How to reduce MTU for a VPN tunnel?
From: Marc Haber <mh+qorbit-nn@zugschlus.de>
Date: Fri, 23 Mar 2007 19:18:47 +0100
Delivered-to: sp-com-lists@consult.net
Delivered-to: ns-list2@consult.net
Delivered-to: nn@qorbit.net
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>
Sender: nn-bounces@qorbit.net
User-agent: Mutt/1.5.9i
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@qorbit.net
http://qorbit.net/mailman/listinfo/nn

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