Thread Info
  • State Verified Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 47 replies
  • Answers 3 answers
  • Subscribers 5 subscribers
  • Views 102286 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

Site-to-Site RED tunnel not working

dowagner

Hi,

I'm having the hardest time setting up a Site-to-Site RED tunnel between two SG230 appliances.

I'm trying to establish a tunnel between our main site (subnet 10.0.0.0/16) and our remote site (subnet 10.3.0.0/16).

I was following the steps from the tutotial located at

https://community.sophos.com/kb/en-us/120157

and was able to get the RED-tunnel up.

However, setting the static routes as described in the howto does not work unfortunately, no traffic seems to pass between both UTMs.

I've defined the reds2 Interface on the main site UTM with the ip adress 192.168.200.1 (We have another RED tunnel to a RED15 appliance at another branch Office, which is why the server Interface is named reds2) and the redc1 Interface on the remote site with the ip adress 192.168.200.2.

At this Point, shouldn't I be able to ping both RED endpoints from either UTM? At the Moment, I'm unable to get any pings across.

Any help would be appreciated!

Dominik



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

    Hi Dominik,

    All the troubleshooting and configuration steps are verified but there seems a different issue. Do you have tunnel compression applied in the RED configuration on the UTM? If yes, remove the tunnel compression option found in the advance tab. 

    Next, look into all the network/IP host objects defined in the (Static routes, FW-rule and RED deployment) configuration if it has the correct values. Check the following as I mention below:

    1. In static route defined on Site 2 verify, BL_RED_GW is not bind to a particular interface and BL_10.10.1.0 has the correct subnet mask. Similarly, on the Site 1, Vikino_6.0 has the correct subnet-network and VikinoRED_c is not bind to a particular interface.

    2. On site1 in the FW-rule, Vitek_Subnet2 has the correct network and subnet; not bind to any interface. Alongside, I don't understand why a separate host definition was configured named RED Semily (Network) instead of using LAN(Network) ? Can you change that to LAN here? Similarly, on site2 make sure Semily_RED subnet is not bind to any interface.

    3. On site1, configure a FW-rule: LAN (network) to  Vitek_Subnet2 and on site2: LAN(Network) to Semily_RED_Subnet.

    Verify the steps and let us know if that helps :)

    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

    Hello,

    to Ad. 1) everything seems to be OK

     

    Ad. 2) all network definitions are set to Interface: Any, no binding to single adapter

    Semily RED subnet is correct, as you can see in my drawing, i want to reach subnet which is behind RED50, not LAN on UTM PRG site.

    I tryied all settings also with UTM PRG LAN network, which i dont need to reach, but result was exactly the same, did not worked.

     

    Ad. 3) FW rule is also correct, as i dont want to reach UTM PRG LAN, but RED50 LAN...

    Therefore there is used as Network object RED50 interface called Semily RED...

     

    Vitek

  • 0 in reply to vikino

    Vitek, has Sophos assigned a case number yet?

    I'm sending you a PM.

    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

    So Bob...as i told you... i did the same scenario from another UTM which is at my parrents home :-)

    RED interfaces got IPs 10.40.1.1 and 10.40.1.2

    And result? Exactly same - nothing... I will do TCP dump and see whats going on there.

     

    Vitek

  • 0 in reply to vikino

    Hi Vikino,

    Sorry I've been out of contact, I've been doing installs since we last spoke all over the place!

    What I'm about to say is in absolutely no way shape or form a resolution and is purely for testing purposes, so anyone who reads this, please take heed of this warning that doing this will completely destroy your security infrastructure if left active for any period of time.

    Firstly, it still looks like your Static Routing looks good so I believe we can potentially rule that out for now.

    Next, this is the bit what the warning above is about:

    Create a firewall rule on both UTMs with Any-Any-Any allow and disabled.

    Once you're ready, enable both firewall rules and begin your tests for pins, telnets on appropriate ports like 3389 RDP, 445 CIFs and any others that you can think of. If your tests are succesful and you get connection then we have a problem with the specific rules. If your tests still fail then we have a routing problem, if we can't fix the routing problem then there may be something more fundamental broken but lets cross that problem when we get to it. Once your test is complete, immediately turn off those rules. It's unlikely you will be hacked in under 5 minutes of testing but these kind of rules should never be left on for any periods.

    There's very few things that can break a RED tunnel like I said in a previous post but what's happening here is quite concerning.

    Emile

Reply
  • 0 in reply to vikino

    Hi Vikino,

    Sorry I've been out of contact, I've been doing installs since we last spoke all over the place!

    What I'm about to say is in absolutely no way shape or form a resolution and is purely for testing purposes, so anyone who reads this, please take heed of this warning that doing this will completely destroy your security infrastructure if left active for any period of time.

    Firstly, it still looks like your Static Routing looks good so I believe we can potentially rule that out for now.

    Next, this is the bit what the warning above is about:

    Create a firewall rule on both UTMs with Any-Any-Any allow and disabled.

    Once you're ready, enable both firewall rules and begin your tests for pins, telnets on appropriate ports like 3389 RDP, 445 CIFs and any others that you can think of. If your tests are succesful and you get connection then we have a problem with the specific rules. If your tests still fail then we have a routing problem, if we can't fix the routing problem then there may be something more fundamental broken but lets cross that problem when we get to it. Once your test is complete, immediately turn off those rules. It's unlikely you will be hacked in under 5 minutes of testing but these kind of rules should never be left on for any periods.

    There's very few things that can break a RED tunnel like I said in a previous post but what's happening here is quite concerning.

    Emile

Children
Unfiltered HTML