Can' t ping oversized icmp traffic

[#1]

Hi We have 2 subnet with 2 fortigate bridged with VPN ipsec. When I try to ping oversized packet between the 2 subnet that don' t work. But standard ping work. ping 192.168.5.5 -l 2048 I need this to troubleshoot a network problem. (http://www.eggheadcafe.com/microsoft/Windows-Group-Policy/31759765/userenv-event-id-1054--userenvlog-dsgetdcname-failed-with-59.aspx) Thank

[ede_pfau]

Hi, and welcome to the forums. Look at this from my FGT:

 
 E:\>ping  192.168.40.3 -l 3072
 
 Pinging 192.168.40.3 with 3072 bytes of data:
 
 Reply from 192.168.40.3: bytes=3072 time=133ms TTL=126
 Reply from 192.168.40.3: bytes=3072 time=134ms TTL=126
 Reply from 192.168.40.3: bytes=3072 time=133ms TTL=126
 Reply from 192.168.40.3: bytes=3072 time=133ms TTL=126
 
 Ping statistics for 192.168.40.3:
     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
 Approximate round trip times in milli-seconds:
     Minimum = 133ms, Maximum =  134ms, Average =  133ms

This is a plain vanilla IPSec VPN tunnel to a FGT in a different city. I tested with tunnel initially down or up, same result.

[emnoc]

Do you have the DF bit set or not in the L3 header? You could tcpdump this to determine the condition. On linux or most unixes, you can set the DF ( don' t frag bit). I bet this is a DF bit issus, causing the packets to drop and I bet it starts around 1472bytes if I had to guess e.g ping -M do -s 1480 " target-host-on-the-far-side.addr" ping -M donot -s 1480 " target-host-on-the-far-side.addr" Good luck

[#4]

Where can I found the DF bit in the shell of fortigate?

[#5]

The biger packet I can send is 1410 byte

[rwpatterson]

The missing bits are the tunnel encapsulation information. Some device along the path will not permit fragmentation of the packets.

[emnoc]

The biger packet I can send is 1410 byte

So that should be the payload size. What' s your internet access line ? DSL? To answer the other information, the DF status would be capture with a tcpdump or tshark/wireshark tool. Not sure if the diagnose sniffer would display this. The packets are probably being dropped during the tunnel encapsulation. I' m not sure or never heard of tunnel information handling anything with regards to DF bits or anything within the IPnIP encapsulation that IPSEC has. Do determine if the access-line is the culprit, have you tried oversize pings from outside the tunnel to something else on the internet? And with and without DF set? This would give you an ideal of the path MTU size. e.g ( 2 different pings from my wire to www google with the Don' t frag set using the unix ping on openbsd ) $ ping -D -s 1470 -c 4 www.google.com PING www.l.google.com (74.125.71.104): 1470 data bytes 72 bytes from 74.125.71.104: icmp_seq=0 ttl=52 time=155.182 ms (TRUNC!) 72 bytes from 74.125.71.104: icmp_seq=1 ttl=52 time=155.999 ms (TRUNC!) 72 bytes from 74.125.71.104: icmp_seq=2 ttl=52 time=155.236 ms (TRUNC!) 72 bytes from 74.125.71.104: icmp_seq=3 ttl=52 time=155.824 ms (TRUNC!) --- www.l.google.com ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 155.182/155.560/155.999/0.453 ms $ ping -D -s 1479 -c 4 www.google.com PING www.l.google.com (74.125.71.103): 1479 data bytes ping: sendto: Message too long ping: wrote www.l.google.com 1507 chars, ret=-1 ping: sendto: Message too long ping: wrote www.l.google.com 1507 chars, ret=-1 ping: sendto: Message too long ping: wrote www.l.google.com 1507 chars, ret=-1 ping: sendto: Message too long ping: wrote www.l.google.com 1507 chars, ret=-1

[#8]

One side of the VPN is DSL and the other one is Fiber. I ping www.google.com via the DSL and the bigger packet was 1472 byte same with the fiber.

[emnoc]

have you inspected the source(s) and if the DF bit is set of not? tcpdump -vvv src host " insert host" or tshark -V src host " insert host" and dst host " xxx.yyy.zzz.aaaa" and monitor the packet DF bit setting. If the Df bit are toggled high, the traffic could be dropped pre-tunnel encapsulation. Path MTU is probably broken due to the VPN/ipsec and the hosts are not even aware of the VPN Tunnel.

[rwpatterson]

Try bringing the ' tcp-mss' size down to 1400. That would leave 100 bits for encapsulation and other header information. 1500 should still be max packet size. Configure that on the interface.

 config system interface
     edit " port1" 
         set vdom " root" 
         set ip 192.168.2.1 255.255.255.0
         set allowaccess ping https ssh snmp telnet
         set type physical
         set tcp-mss 1400
         set description " Inside (gateway) interface" 
         set alias " LAN" 
     next
 end