We'd love to hear about it! Click here to go to the product suggestion community
Hi All,I have a strange behaviour in the UTM packet filter.We have an incoming connection which we have allowed as usual with this rule.FW Rule:Src: 172.24.nnn.nnn/16DST: 10.0.bbb.bbb/24TCP: 443Incoming connections work, but the reply from 10.0.bbb.bbb:443 seems be to a new connection, as without allowing the 10.0.bbb.bbb:443 > 172.nnn.nnn.nnn:50243 the UTM blocks the reply.08:07:03.081547 IP 172.nnn.nnn.nnn.50243 > 10.0.bbb.bbb.443: Flags [.], ack 28151, win 255, length 008:07:03.082191 IP 172.nnn.nnn.nnn.50243 > 10.0.bbb.bbb.443: Flags [P.], seq 61065:61356, ack 28151, win 255, length 29108:07:03.082239 IP 172.nnn.nnn.nnn.50243 > 10.0.bbb.bbb.5080: Flags [P.], seq 61356:61719, ack 28151, win 255, length 36308:07:03.082255 IP 10.0.bbb.bbb.5080 > 172.nnn.nnn.nnn.50243: Flags [.], ack 61719, win 1452, length 008:07:03.082597 IP 10.0.bbb.bbb.5080 > 172.nnn.nnn.nnn.50243: Flags [P.], seq 28151:28408, ack 61719, win 1452, length 25708:07:03.082653 IP 10.0.bbb.bbb.5080 > 172.nnn.nnn.nnn.50243: Flags [P.], seq 28408:28415, ack 61719, win 1452, length 7 Default DROP TCP 10.0.bbb.bbb : 443 → 172.nnn.nnn.nnn : 50243 [RST] len=40 ttl=63 tos=0x00 srcmac=7c:cccccccccc dstmac=00 Default DROP TCP 10.0.bbb.bbb : 443 → 172.nnn.nnn.nnn : 50243 [RST] len=40 ttl=63 tos=0x00 srcmac=7c:cccccccc dstmac=00Any Hint what’s going on there?Greetings
Would you please share the screenshot of the DNAT rule? or the Firewall rule you've configured?
Do you see any problems with the connection?The dropped packet is a "RST" Packet. This means "TCP session reset".This packet often is send some time after session is timed out ... If server and client don't close the TCP session properly.Normally everything works ... with these packets within FW-log.
without a network diagram it's difficult, my guess asymmetric routing between the peers?
Herzlich willkommen hier in der Community !
(Sorry, my German-speaking brain isn't creating thoughts at the moment. )
Alone among the logs, the Firewall Live Log presents abbreviated information in a format easier to read quickly. Usually, you can't troubleshoot without looking at the corresponding line from the full Firewall log file. Please post one line corresponding to those above. If you prefer, obfuscate IPs like 84.XX.YY.121, 10.X.Y.100, 192.168.X.200 and 172.2X.Y.51. That lets us see immediately which IPs are local and which are identical.
Unless you experience a true lack of response, you normally can ignore drops of RST packets.
MfG - Bob (Bitte auf Deutsch weiterhin.)