Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 3 subscribers
  • Views 12310 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

Dropped packages and Firewall violations even though Allow All rule

AdrianFöder

Hey everyone,

we have an SG 105 on the main branch, network is 192.168.42.x and a RED 15 on a subsidiary branch which is 192.168.9.x

The RED serves fine DHCP on 192.168.9.128 until 254.

Being on the remote subsidiary, I am able to for example ping 192.168.42.65 and 192.168.42.1, I also am able to log in to the main SG 105. Tracert is nicely routed via the RED host.

We now try to get to our telecommunications device which is on 192.168.42.20 but no connection is possible. It is exactly the same way connected as .65 or .1 as mentioned above.

Is it possible that there are additional FW restrictions active? Why? I have an allow from all to all (Hummelbühl 9 is the RED NW):

 

but for example the following log entries:

Why is that? What can I do further?



This thread was automatically locked due to age.
Parents
  • 0

    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

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • 0 in reply to sachingurung

    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

  • 0 in reply to AdrianFöder

    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

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • 0 in reply to sachingurung

    Hi,

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

  • 0 in reply to AdrianFöder

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

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    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?

  • 0 in reply to AdrianFöder

    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!

Reply
  • 0 in reply to AdrianFöder

    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!

Children
No Data
Cookie Information Banner