Dropped packages and Firewall violations even though Allow All rule

Hi,

Did you mean, you can communicate with 192.168.42.65 and 192.168.42.1 from 192.168.9.x network? RED is deployed in which mode? Which is the RED device and what is the configuration for RED in UTM?

Please post the required details with screenshots.

Thanks

Hi,

exactly what you've said: .42.65 and .42.1 (for example) is possible, while .42.20 is not, FROM RED's 192.168.9.x location. Just to exclude potential mistakes: yes, both are ping'able etc. from the immediate network.

RED is deployed in.. Standard/Unified? The one where *all* traffic, even Internet, is routet through the "mother" UTM.

See the following screenshots:

Thank you very much for your assistance,

Adrian

Hi Adrian,

Please confirm if the Host/Network definition for 192.168.42.20 is not bound to a specific interface. Always leave all definitions with 'Interface: <<Any>>'.

Thanks

Hi,

yep I think I can confirm this... shall I provide any screenshots for this? Can you say from what tab then?

Post a few, relevant lines from a search for 192.168.42.20 in yesterday's Firewall log.

Cheers - Bob

Post a few, relevant lines from a search for 192.168.42.20 in yesterday's Firewall log.

Cheers - Bob

Hi Bob,

there is absolutely nothing to find in the Firewall logs regarding the .42.20! Mabye it's worth to mention that in the log, I only can find PACKAGE DROPs.

I just made a tracert from the RED location (.9.x) in question to show the problem:

So, maybe the thread title is a bit misleading: I am currently not sure whether it's an actual DROP or whatever. Seems the routing doesn't work as intended?

Oh boy, I've solved it: the device in question 192.168.42.20 had an incorrect subnet mask of 255.255.0.0. Setting it to /24 (255.255.255.0) did it...

I was mislead by the fact that it worked fine in the internal network while it didn't via the routed one...

Thanks for your support guys, I've learned a lot already!

have a nice evening!