Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 2 subscribers
  • Views 3672 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Traffic being dropped

AlanI
Hey,

I setup a new UTM 9 box the other week for the first time, but I'm having trouble understanding how it's applying some firewall rules.

To start off things really easy, I simply wanted to permit all traffic going out from my Internal network to the Internet, and basically any incoming TCP established connections.

To do this, I've created the rule:

Source: Internal (Network)
Services: Any
Destination: Any
Action: Allow

Whilst this is perhaps a tad broad for a gateway firewall, I wanted to make sure it was working correctly before I started restricting things further.

The result of this rule is that it mostly works, in that from a device I can browse the Internet okay, but I am seeing some weird network behavior which I'm trying to determine is a result of UTM, or some unrelated problem.

Taking a look at the UTM firewall log, I'm seeing a lot of stuff like this: 

01:11:02	Default DROP	TCP	 74.125.28.95:443 → 192.168.0.18:45165 [RST] len=40	ttl=64	tos=0x00	srcmac=x:xx:xx:x:xx:xx


In this case, the destination is an Android mobile phone, and the source is a Google IP address.  I'm fairly confident this is okay traffic, but I'm confused why it's being blocked. It's presumably from an established TCP connection so I would have thought should be allowed.

For the purposes of troubleshooting (and I know, this shouldn't be done in prod), I created the following rule:

Source: Any
Services: Any
Destination: Any
Action: Allow

After turning on that rule for about 60 seconds, I continued to get drop lines in the firewall log: 

01:18:27	Default DROP	TCP	 17.135.64.4:443 → 192.168.0.19:58240  [RST]	len=40	ttl=64	tos=0x00	srcmac=0:15:5d:0:c4:34


How is that possible that the 'Default Drop' rule is being hit if there's clearly a rule in there which permits traffic from anywhere, to anywhere.

Am I missing something as to how the firewall interprets these rules?


This thread was automatically locked due to age.
Parents
  • 0
    While this is a rather ages thread, I see the same "issue" on our firewalls and I'd like to have this a bit more detailed. We see LOTS of dropped packets in the fashion as described above, all being response packets within connections that have been permitted by the firewall (packets going from "server" to "client"). 

    It seems as if the kind of packets might match the theory of packets being out of scope of the connection tracker, but this does also affect connections between internal systems, which makes this a bit unlikely. Also, not only RST packets are dropped, but also e.g. SYN/ACK. Strangely, I haven't seen any packets carrying payload data being dropped by this phenomenon yet.

    I can't say yet if those drops cause any problems (which I believe, as also packets from TCP connection setups are being dropped) as they occur on a heavily irregular base, but all those drops at least clutter the logs heavily. Is there any way to configure the connection tracking module or debug the connection tracker to see why connections are being dropped (or if the connection tracker is the cause for packet drops in the first way)?
Reply
  • 0
    While this is a rather ages thread, I see the same "issue" on our firewalls and I'd like to have this a bit more detailed. We see LOTS of dropped packets in the fashion as described above, all being response packets within connections that have been permitted by the firewall (packets going from "server" to "client"). 

    It seems as if the kind of packets might match the theory of packets being out of scope of the connection tracker, but this does also affect connections between internal systems, which makes this a bit unlikely. Also, not only RST packets are dropped, but also e.g. SYN/ACK. Strangely, I haven't seen any packets carrying payload data being dropped by this phenomenon yet.

    I can't say yet if those drops cause any problems (which I believe, as also packets from TCP connection setups are being dropped) as they occur on a heavily irregular base, but all those drops at least clutter the logs heavily. Is there any way to configure the connection tracking module or debug the connection tracker to see why connections are being dropped (or if the connection tracker is the cause for packet drops in the first way)?
Children
No Data