9.202-33: TCP session resumed BY REPLY PACKET after UTM reboot

RE: 9.202-33: TCP session resumed BY REPLY PACKET after UTM reboot

BAlfson — Wed, 11 Jun 2014 10:48:46 GMT

He said that he has strict TCP. I suspect that there's a firewall rule allowing the traffic.

Cheers - Bob

RE: 9.202-33: TCP session resumed BY REPLY PACKET after UTM reboot

BarryG — Tue, 10 Jun 2014 16:45:41 GMT

Hi, would enabling the strict TCP options be a solution or workaround for this?

Barry

RE: 9.202-33: TCP session resumed BY REPLY PACKET after UTM reboot

ondrej.holas — Tue, 10 Jun 2014 11:18:25 GMT

Bob, as far as I know netfilter/iptables, conntrack is involved always, including configuration without NAT/masq. (To be exact: You must explicitly use "notrack" target to exclude packet from connection tracking; however, in UTM there's only one rule using "notrack" for localhost communication.)

There is only one rule in the lab: 192.168.21.2/32 -> 192.168.20.2/32 : 22/tcp

There's no rule in UTM config allowing communication from SSH server to client.

RE: 9.202-33: TCP session resumed BY REPLY PACKET after UTM reboot

BAlfson — Tue, 10 Jun 2014 09:01:22 GMT

With masquerading in place, packet from outside server is replied by RST

Ahhh - conntrack wasn't involved! So, it's not clear that this is a bug. What firewall rules do you have between 192.168.20.0/24 and 192.168.20.1/24?

Cheers - Bob

RE: 9.202-33: TCP session resumed BY REPLY PACKET after UTM reboot

ondrej.holas — Mon, 09 Jun 2014 12:28:37 GMT

Confirmed in lab on test VM with fresh install of UTM 9.202-33 and minimal configuration.

192.168.20.2 = SSH server
192.168.21.2 = client

After UTM reboot:

utm-test:/root # iptables-save -c | grep -E "FORWARD.+confirmed" ; cat /proc/net/ip_conntrack | grep 192.168.20.2
[0:0] -A FORWARD ! -d 224.0.0.0/4 -m confirmed -j ACCEPT

Keepalive packet from SSH server:

19:21:17.107553 IP 192.168.20.2.22 > 192.168.21.2.54617: Flags [.], ack 1579353482, win 1563, options [nop,nop,TS val 926336 ecr 774430], length 0
19:21:17.108358 IP 192.168.21.2.54617 > 192.168.20.2.22: Flags [.], ack 1, win 2389, options [nop,nop,TS val 924444 ecr 776322], length 0

Final state:

utm-test:/root # iptables-save -c | grep -E "FORWARD.+confirmed" ; cat /proc/net/ip_conntrack | grep 192.168.20.2
[2:104] -A FORWARD ! -d 224.0.0.0/4 -m confirmed -j ACCEPT
tcp      6 292 ESTABLISHED src=192.168.20.2 dst=192.168.21.2 sport=22 dport=54617 packets=1 bytes=52 src=192.168.21.2 dst=192.168.20.2 sport=54617 dport=22 packets=1 bytes=52 mark=528384 use=2

UTM must be configured with no NAT/masquerading. With masquerading in place, packet from outside server is replied by RST (expected behavior).

RE: 9.202-33: TCP session resumed BY REPLY PACKET after UTM reboot

ondrej.holas — Mon, 09 Jun 2014 00:58:11 GMT

I have home license only, no paid license.

RE: 9.202-33: TCP session resumed BY REPLY PACKET after UTM reboot

BAlfson — Sun, 08 Jun 2014 17:18:06 GMT

Ondrej, do you have a paid license that will allow you to submit a bug report to Support?

Cheers - Bob

RE: 9.202-33: TCP session resumed BY REPLY PACKET after UTM reboot

ondrej.holas — Sun, 08 Jun 2014 14:51:23 GMT

Bob, the box surely rebooted, as seen in "last".

Where to send that ack: this UTM does not perform any NAT, so it does not need active conntrack entry to forward that reply packet, UTM simply forwards the packet by destination IP address (which is untouched by UTM in this scenario).

My further ivestigation showed iptables rule responsible for accepting the reply packet:

-A FORWARD ! -d 224.0.0.0/4 -m confirmed -j ACCEPT

This can be seen in rule counters, green rules were inserted manually, state just after keepalive ACK/ACK:

[1:40] -A FORWARD -s *SSH_SERVER*/32 -m confirmed

[1:40] -A FORWARD -s *CLIENT*/32 -m confirmed

[2:80] -A FORWARD ! -d 224.0.0.0/4 -m confirmed -j ACCEPT

So the problem seems to be somewhere inside "confirmed" match/"CONFIRMED" target logic.

RE: 9.202-33: TCP session resumed BY REPLY PACKET after UTM reboot

BAlfson — Fri, 06 Jun 2014 16:13:45 GMT

OK, I had misunderstood your explanation. Yeah, that does look like a potential bug. Still, I don't understand how conntrack knew where to send that ack - it's as if there was no reboot of the UTM. Can you confirm from the logs that a reboot took place?

Cheers - Bob

RE: 9.202-33: TCP session resumed BY REPLY PACKET after UTM reboot

ondrej.holas — Fri, 06 Jun 2014 14:59:15 GMT

Bob, there's no such rule. The SSH server is on the internet and it is present only in destination side of some rules. It is neither itself as a source nor matching source side in any wider rule.

And hypothetically, if there were such rule, UTM should not accept that session by ACK packet, if "Strict TCP" is turned on.

RE: 9.202-33: TCP session resumed BY REPLY PACKET after UTM reboot

BAlfson — Fri, 06 Jun 2014 14:16:10 GMT

Ondrej, my guess would be that there's a firewall rule that allows outbound traffic from your internal SSH server.

Cheers - Bob