TCP Connection Reopening Bug in 5.xx?

robertpenz · Sat Nov 24, 2012 8:58 pm

Hi!

I believe I found a bug in at least the 5.xx releases (tested with 5.14 and 5.20). Can someone verify my findings please. Following is the setup:

VoIP Phone (h.323) - Switch - Mikrotik Router - Switch - VoIP Gateway

Here the packet flow

1. A call (media is initialized by the Gateway to the phone

Source			Destination		Protocol	Info
Gateway			Phone			TCP		src port 4139, dst port 1720, SYN
Phone			Gateway			TCP 		src port 1720, dst port 4139, SYN, ACK
Gateway			Phone			TCP		src port 4139, dst port 1720, ACK

2. Now they talk a little and than they hang up

Source			Destination		Protocol	Info
Gateway			Phone			TCP		src port 4139, dst port 1720, FIN, ACK
Phone			Gateway			TCP		src port 1720, dst port 4139, FIN, ACK

The mikrotik is at this time in the tcp-time-wait-timeout state (default: 10s) - (from the wiki: maximal amount of time connection tracking entry will survive after having seen connection termination request (FIN) just after connection request (SYN) or having seen another termination request (FIN) from connection release initiator)

3. now we call immediately again, and the gateway uses the same src port ... which leads to the same connection tuple (source IP, source port, destination IP, destination port).

Source			Destination		Protocol	Info
Gateway			Phone			TCP		src port 4139, dst port 1720, SYN
Phone			Gateway			TCP 		src port 1720, dst port 4139, SYN, ACK
Gateway			Phone			TCP		src port 4139, dst port 1720, ACK

But now the Phone is not able to send normal packets to the gateway back until the tcp-time-wait-timeout has run out.

You see following after the initial TCP handshake.

Source			Destination		Protocol	Info
Gateway			Phone			TCP		src port 4139, dst port 1720, h323: setup OpenLogicalChanel
Phone			Gateway			TCP 		src port 1720, dst port 4139, ACK
Phone			Gateway			TCP 		src port 1720, dst port 4139, h323: connect openLogicalChannel (Filtered by Microtik)
Phone			Gateway			TCP 		src port 1720, dst port 4139, resent, h323: connect openLogicalChannel (Filtered by Microtik)
Phone			Gateway			TCP 		src port 1720, dst port 4139, resent, h323: connect openLogicalChannel (Filtered by Microtik)
Phone			Gateway			TCP 		src port 1720, dst port 4139, resent, h323: connect openLogicalChannel

The last resent is after the fin packet time + tcp-time-wait-timeout seconds and reaches the gateway. I'll decreased the tcp-time-wait-timeout to 1 second and the problem went away, as I was not able to dial so fast

. The same was true when deactivating connection tracking.

I searched through the netfilter mailling list and at some time there was an error in it which looks similar, even if to old

.

http://www.mail-archive.com/git-commits ... 23313.html

With your description I could reproduce the bug and actually you were
completely right: the code above is incorrect. Somehow I was able to
misread RFC1122 and mixed the roles :

When a connection is >>closed actively<<, it MUST linger in
TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime).
However, it MAY >>accept<< a new SYN from the remote TCP to
reopen the connection directly from TIME-WAIT state, if it:
[...]

Update: I found following in the RFC1122: http://tools.ietf.org/html/rfc1122

When a connection is closed actively, it MUST linger in
TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime).
However, it MAY accept a new SYN from the remote TCP to
reopen the connection directly from TIME-WAIT state, if it:

(1) assigns its initial sequence number for the new
connection to be larger than the largest sequence
number it used on the previous connection incarnation,
and

(2) returns to TIME-WAIT state if the SYN turns out to be
an old duplicate.

I verified that the initial sequence number of the SYN Packet is larger than the last one from the gateway. And also the sequence number for the SYN,ACK packet is larger then the last from the phone. I deactivated for this the "relative sequence numbers" setting in Wireshark.

I can also provide packet traces, before and behind the router.

Maggiore81 · Mon Nov 26, 2012 12:07 pm

I am having a lot of issues with MT and VOIP SIP .

the phone doesn't even register.

http://forum.mikrotik.com/viewtopic.php?f=2&t=67606

SunBlade0 · Sat Nov 24, 2018 8:19 am

necroing this thread

i run v6.43.4 and i also see this behavior. if the connection is in a wait state ROS blocks all reconnect attempts.

my test config:

# ip on the public interface
:local PubIP 192.168.108.2

# ip on the lan interface
:local PrivIP 192.168.109.1

# ip of the local server
:local ServIP 192.168.109.10

# exaggerating the problem
/ip firewall connection tracking
set enabled=yes tcp-close-wait-timeout=1m tcp-fin-wait-timeout=1m tcp-time-wait-timeout=1m

# don't block anything
/ip firewall filter
add action=accept chain=forward comment="forward all"

# basic internet access
/ip firewall nat
add action=src-nat chain=srcnat out-interface=ether1 to-addresses=$PubIP comment="masquerade LAN"

# port forwarding
add action=dst-nat chain=dstnat dst-address=$PubIP dst-port=80 protocol=tcp to-addresses=$ServIP to-ports=80 comment="http port forward"
add action=src-nat chain=srcnat dst-address=$ServIP dst-port=80 protocol=tcp to-addresses=$PrivIP to-ports=80 comment="http port forward"

as far as i can tell my masquerading rule works as intended.
but port forwarding has those problems. only tcp traffic on dstnat seems to be affected.

edit:
after ages of googling and testing i found the culprit: i did srcnat in both directions.
conntrack seems to mess up when i do that.
after disabling either rule, tcp reconnects work again.

TCP Connection Reopening Bug in 5.xx?

TCP Connection Reopening Bug in 5.xx?

Re: TCP Connection Reopening Bug in 5.xx?

Re: TCP Connection Reopening Bug

Who is online