Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 17 replies
  • Subscribers 2 subscribers
  • Views 34738 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

Can't access device behind RED

dhd
Hi I have a site setup with the following setup

Internal>ASG120Cluster->WAN->Router serving DHCP>RED10>Cisco>Client PC's

My RED is in standard unified mode and has an interface 172.16.250.1/29 serving DHCP on 172.16.250.4-6
The RED is 172.16.250.1 the Cisco WAN side is 172.16.250.2 

The Cisco can ping external addresses on my ASG Cluster as can client PC's

however I can't ping the Cisco or client pc's from the ASG or anything inside it.  I can ping my RED address however.

Firewall rules are Trusted networks(internal etc)>any>any and RED network and client networks>ports they require(https etc)>external address of virtual webserver (server load balancing)

Any ideas?


This thread was automatically locked due to age.
  • 0
    Please [Go Advanced] and attach pictures of Edits of the RED definition and the related Interface definition.

    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

    See below




    Cheers
  • 0
    That all looks great.  Are we certain that the 172.16.x.1/29 subnet doesn't overlap with any other subnet defined on any interface?  Is 'Firewall forwards Pings' selected on the 'ICMP' tab of 'Firewall'?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Hi Bob

    Yes there are no overlaps and I've enabled "firewall forwards pings" and "firewall forwards tracert"
  • 0
    Think I may have solved it, added a SNAT to traffic going to the Cisco and the networks beyond with the source translation as the RED address.
  • 0
    Hi dhd,
    are the routes shurely set korrekt in any of the Networks?
    If you need an SNAT maybe the way back to the sender is not consistent.
  • 0
    Think I may have solved it, added a SNAT to traffic going to the Cisco and the networks beyond with the source translation as the RED address. 

    Hmmmm... that makes me suspect that the Host definition in WebAdmin for the Cisco runs afoul of what I call Rule #3:

    Never create a Host/Network definition bound to a specific interface.
    Always leave all definitions with 'Interface: >'.


    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 BAlfson,
    why did you wrote this:

    Hmmmm... that makes me suspect that the Host definition in WebAdmin for the Cisco runs afoul of what I call Rule #3:

    Never create a Host/Network definition bound to a specific interface.
    Always leave all definitions with 'Interface: >'.


    Cheers - Bob



    if you have build your Network right, its never a Problem, if it makes a Problem you have to search on Layer1 to solve it.

    Firebear
  • 0
    build your Network right, its never a Problem

    The reason for this "rule" is that binding definitions to an interface can cause WebAdmin to create routes you don't expect, disrupting VPN and NATted traffic.

    Any necessary definitions with a bound interface can be created by adding an Additional Address to an interface and using the "(Address)" object created by WebAdmin.

    At least, that's how I understand it.

    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 Balfson,

    binding an network object to an interface is not the same than using an Additional-Address on an Interface. 
    But you are right with VPN, the interface where you have to bind Objects wich are behind an VPN is an virtual interface and thats not there to bind anything.
    If you shure that an defined object is behind an specific Interface - so what - Packets have to go in and out this Interface and none else.

    Greets firebear