• February 24, 2025, 10:20:42 AM
  • Welcome, Guest
Please login or register.

Login with username, password and session length
Advanced search  

News:

This Forum Beta is ONLY for registered owners of D-Link products in the USA for which we have created boards at this time.

Author Topic: NAT and TCPSequenceNumbers problem  (Read 6223 times)

psoftware

  • Level 1 Member
  • *
  • Posts: 1
NAT and TCPSequenceNumbers problem
« on: May 04, 2010, 12:15:17 AM »

Hi,

we've encounterd a problem regarding nat-rules and sequenznumbers being too low.
An according Log entry looks like this:

May  4 07:57:49 10.25.1.254 [2010-05-04 09:29:17] FW: TCP_FLAG: prio=0 id=03300016 rev=2 event=tcp_seqno_too_low action=drop seqno=3447886080 accstart=3447886081 accend=3447891925 rule=TCPSequenceNumbers connipproto=TCP connrecvif=lan1 connsrcip=192.168.57.203 connsrcport=49920 conndestif=dmz conndestip=172.16.221.120 conndestport=80 origsent=96 termsent=48 recvif=lan1 srcip=172.16.221.123 destip=172.16.221.120 ipproto=TCP ipdatalen=28 srcport=35490 destport=80 tcphdrlen=28 syn=1

To me it looks like only natted connections are affected and unfortunatly the problem occurs randomly from 20 to 1000 times a day.
The Problem occurs on both FW 2.26.00.06-12652 and 2.20.03.08-8259 older FW haven't been checked.
Firewall DFL 2500 with WAN1 and DMZ running in transparent mode.
Regarding the version history theis or a similar problem is fixed since 2.20.03.
Does anyone has similar problems and knows why this happen?
As switching the rule to ignore or accept is not an option help is much appreciated.

regards,
psoftware

« Last Edit: May 04, 2010, 12:21:17 AM by psoftware »
Logged

Fatman

  • Level 9 Member
  • ****
  • Posts: 1675
Re: NAT and TCPSequenceNumbers problem
« Reply #1 on: May 04, 2010, 08:21:22 AM »

The log makes it look like the computer is the one setting the sequence number one too low.

If the PC really is setting the wrong sequence number it isn't a DFL issue.

The band aid fix is to go to System->Advanced Settings->TCP Settings->TCP Sequence Numbers and set that to Ignore.  I do believe that should cause the drops to stop.

The best diagnostic thing you can do is to take a capture from a PC that has this problem (and hopefully is less utilized than the rest) until you get a log indicating an error on that PC so that you can see the entire TCP conversation.  You could also take logs from the DFLs interfaces directly as of 2.26, but the buffers are fairly small so you would need to ensure you stop the interface capture as soon as the relevant traffic is captured.
Logged
non progredi est regredi