Any idea why this packet is being dropped?

asked 2021-11-22 15:22:15 +0000

updated 2021-11-22 16:45:23 +0000

Having difficulty with a clock on one of our sites, connecting to head office over VPN. The clock software on the HQ Server is sending the initial packet to the Branch clock (Packet 1), which reaches the clock. The clock, which has an MTU of 1500, then sends a response (Packets 2 and 3). These packets reach our firewall but are dropped. The router shows nothing in the logs relating to this packet. I've switched off the firewall, created firewall rules to specifically allow all traffic for this IP address. But nothing I do get the packet back to the HQ Server.

Sorry about the text of the packets but it wouldn't let me include a picture cos I don't have enough pints.

edit retag flag offensive close merge delete

Comments

No Time Source Destination IPID Proto Frame Len Info
1 0.0000 192.168.1.1 192.168.16.55 0x64a5 UDP 48 2 62227 --> 6767 Len =2
2 0.0622 192.168.16.55 192.168.1.1 0xa2cf UDP 1518 1472 6767 --> 62227 Len = 2204
3 0.0622 192.168.16.55 192.168.1.1 0xa2cf IPv4 770 7 32 Fragmented IP Protocol (proto=UDP 17, off=1480, ID=a2cf)

Jonathan Stone ( 2021-11-22 16:44:48 +0000 )edit

add a comment

answered 2021-11-22 18:07:20 +0000

SYN-bit

18528 ●9 ●339 ●255 https://SYN-b.it

IP fragments being blocked by the firewall in a zone policy or anti-DDoS profile?

Did you make a trace on both sides (clock and HQ clock software)? If so, which packets did you see and which packets didn't you see?

edit flag offensive delete link

Comments

Hi there, thanks for your response.

Those packets are captured at the LAN interface of the firewall on the clock side. So the packet reaches the clock, the clock replies and the reply (which is the fragmented packet) never makes it off the clock network. I've tried turning off every security feature on the firewall at the clock side, but nothing makes any difference. My plan is next to swop out the firewall for another device with a bit more granular configuration, and hopefully be able to find a reason why the packet is dropped.

The manufacturers of the clock said that they set the MTU of the clock to 1500 Bytes, but it is obviously not adhering to that. Yet still the company is washing their hands of having to do anything on their side to resolve this. Every other device on the network works fine, so we ...(more)

Jonathan Stone ( 2021-11-23 08:33:53 +0000 )edit

From the wireshark output I can confirm that they set their MTU to 1500. The 2204 byte UDP packet is fragmented into a 1500 byte IP datagram (as can be seen from the 1480 offset of the second fragment) and a fragment with the rest of the UDP payload.

What brand/type of Firewall are you currently using? Have you contacted their support to check whether forwarding of IP fragments can be enabled?

SYN-bit ( 2021-11-25 12:21:42 +0000 )edit

Hi all, I know this post has been a while but I am having the same issue on a VPN on a Palo Alto.The 2 comments above were spot on, it is my Palo Alto Zone Protection Policy, and if I turn on ALLOW FRAGMENTED PACKETS, the VPN comes up. My question is, how can such small packets keep getting fragmented, when once I allow, the packets are only like 100 bytes. When their being dropped, I see that the unfragmented packet is 1514 bytes, and the reassembled packet is only like 100 bytes, for the ISAKMP INITIATE packets. Why is this even an issue when the actual packet is only 100 bytes? Any ideas?

funny-games-99 ( 2023-11-29 21:52:57 +0000 )edit

Are you sure it is a single 100 byte packet and not a reassembled packet where the last fragment (the current packet) is 100 bytes?

SYN-bit ( 2023-11-30 14:28:44 +0000 )edit

Sorry for late response, was on vacation. They are VPN ISAKMP packets. Me to the Peer, I can initiate the tunnel. But when the VPN is down, they cannot initiate the tunnel. I did a packet capture and found fragmented frames. So it is my Firewall IPS dropping these inbound initiation packets. I verified by allowing fragmented frames, and the VPN comes UP when they initiate.

The frame/packets come as this:

packet 1 YYY length 1514, info - Fragmented IP Protocol ( proto + UDP 17, off+0 ) then says Reassembled in XXX then in frame/packet XXX packet 2 XXX all the length's are 100 and IKE-SA_INIT MID=00 Initiator Request.

I did a packet capture of a normal VPN that is working and all the ISAKMP packets are small, like 100-140 bytes. So not sure why these frames are being fragmented and where the fragmentation starts.

Unfortunately, the Peer ...(more)

funny-games-99 ( 2023-12-05 17:15:51 +0000 )edit

see more comments

Any idea why this packet is being dropped?

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Any idea why this packet is being dropped? edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Any idea why this packet is being dropped?