Sophos UTM Web Proxy requests blocked to clients

Hallo,

Normal?  That depends.  Please show us a representative drop line from the full Firewall log file (not the Live Log).

Cheers - Bob

Hello Bob,

thank you for your answer.

this are for example two lines showing this block in detail:

Our Proxy-IP is: 10.46.0.34  on Port: 8080 

On Internal Gateway:

2020:04:09-00:16:03 igw-1 ulogd[8902]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="157" initf="lag1.2101" outitf="lag1.49" srcmac="00:1f:28:33:c2:00" dstmac="00:1a:8c:f0:b1:e8" srcip="10.46.0.34" dstip="10.46.xx.xxx" proto="6" length="40" tos="0x00" prec="0x00" ttl="62" srcport="8080" dstport="64194" tcpflags="RST"

2020:04:09-00:16:03 igw-1 ulogd[8902]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="157" initf="lag1.2101" outitf="lag1.49" srcmac="00:1f:28:33:c2:00" dstmac="00:1a:8c:f0:b1:e8" srcip="10.46.0.34" dstip="10.46.xx.xxx" proto="6" length="40" tos="0x00" prec="0x00" ttl="62" srcport="8080" dstport="64197" tcpflags="RST"

The packages are flagged with RST.

The Firewall Rule #157 is our block rule at the bottom (Any -> Any -> Any | Block & Log ) 

We have defined a firewall rule in the internal firewall gateway allowing traffic from all client networks behind the firewall gateway to the proxy 10.46.0.34 - Port: 8080.

But we don't have a rule back... 10.46.0.34 ---> Dynamic Port Range ---> client networks (network ranges) 

Do we need this rule back? If yes, why? 

It's normal for there to be RST packets dropped - that's just part of the "chattiness" of TCP connections.  The Connection Tracker knows that the related conversation has ended and so doesn't pass the packet.

Because the UTM is a stateful firewall, I don't recommend drop rules like your 157.  If a packet wasn't passed before that, it will be dropped by default.  There is more information in the log when a packet is default dropped than is available in an explicit drop line like the two you show above.  For example, it probably would have had fwrule="60001" indicating a default drop of an inbound packet.

So, no, you don't need a rule allowing response packets back in as the Connection Tracker takes care of that in a stateful firewall.

Cheers - Bob

Hello Bob,

thank your for your answer.

and thank you too for the explanation of the drop rule.

i knew that the we don't need a explicit block rule at the end of the firewall rules. we have used it to filter by number. (#id).

Best regards

Ben

Thank you Bob; that's now got me thinking, too. I had always just assumed that drop rules at the end were a prudent precaution (in fact, not long after I first set UTM up - about 4 years ago - I had somewhere read that they really should be added at the end of UTM's firewall rules) and thus I started with an any-any drop, then revised it to the below two drops (which I've had sitting there ever since, without ever properly questioning their merit)...

...so after reading your comments in the above post, I'll spend some time experimenting these last two toggled on and off (whilst looking at the logs) and hopefully enhance my understanding. There was some thought in that I did look at iptables -n -L when creating the last two (to make them land where I thought I needed them) but it was done without a proper understanding of the differences between the chains (I recall later seeing some block diagrams of the chains on this forum, so high time to go seek them out and attempt a far better understanding of that, too). :-)

Kind regards,

Briain