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

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
  • Hi Dominik,

    To my knowledge, once a tunnel is setup, traffic between two UTMs becomes purely a matter of routing and firewall rules. Can you verify that you configured RED (Network) in the Gateway route definition instead of RED (Address).

    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.

  • Hi,

    thanks for answering!

    I'm pretty sure it had something to do with routing, but I couldn't get it to work.

    I decided to scratch the RED setup and instead, went ahead and established a SSL-VPN Site-to-Site tunnel...lo and behold, everything worked right from the get-go.

    So I couldn't solve the original problem, but since Sohps UTM is crazy flexible you usually find a solution that works [:)]

    Thanks anyway!

  • Hi Bob,

    at the beginning i wrote that i tested it from another UTM where i made same RED tunnel and 192.168.5.251 is Windows 2012 server running behind my second UTM :-)

    Because behind UTM with 192.168.6.0/24 i have during work day no running server or client from which i can do test :-)

  • OK Vitek,

    It looks like the UTM with the reds6 interface is receiving the responses from the device being pinged, but it isn't forwarding the replies back through the red*15 tunnel.  If there are no drops in the firewall log at that time, then the issue should be visible in the routing table.  What do you get from the following on the UTM with the reds6 interface?

    cc support_tools routing_table|grep 192.168.5

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • This:

    utm:/home/login # cc support_tools routing_table|grep 192.168.5
              '192.168.5.0/24 dev eth1  proto ipsec  scope link  src 10.20.1.1
              '192.168.5.0/24 via 10.40.1.2 dev reds15  proto static  metric 5
              '192.168.50.0/24 via 10.237.5.27 dev eth2  proto zebra
              '192.168.51.0/24 via 10.237.5.27 dev eth2  proto zebra
              '192.168.53.0/24 via 10.237.5.27 dev eth2  proto zebra
              '192.168.56.0/24 via 10.237.5.27 dev eth2  proto zebra

     

    subnet 50,51,53,56 via 10.237.5.27 are subnets in MPLS, 10.237.5.27 is BGP Neighbour, so they have nothing to do with that...

     

    The first one 192.168.5.0 dev eth1 was IPsec tunnel to VoIP subnet, it is disabled now and not present anymore...

     

    Vitek

  •      '192.168.5.0/24 via 10.40.1.2 dev reds15  proto static  metric 5

    Is that 40 correct for redc15?  It seems it would be based on the first tcpdumps.

    "The first one 192.168.5.0 dev eth1 was IPsec tunnel to VoIP subnet, it is disabled now and not present anymore..." - So, was that the solution to the problem?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Yes, subnet 192.168.5.0/24 is the second home ed. at my parrents and there is 10.40.1.2

     

    Right now im again at 192.168.6.0/24 with 10.30.1.2.

     

    Ill try to do tcpdump also from here.

     

    IPsec tunnel was not the problem, still same result :-(

  • Last thing i did...

    Restarted client UTMs, still same...

    Restarted Server UTM...RED tunnels are working, WTF?

  • Whoopee!  Glad you got it!

    Three months and no one here mentioned that?  We all have egg on our faces here!

    Cheers - Bob

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

    The more I think about it, the more strongly I feel that you should be running the central UTM with a Hot-Standby.  Maybe the other site(s), too.  You should discuss this with your reseller.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • It is HA...

     

    This drives me crazy...Why it needed reboot...? week of time spent on this crap...

  • Well I'm feeling very sheepish, my mantra is normally if nothing makes sense is to reboot it!

    Really glad it's working now Vikino!

    I've seen this sometimes happen when something in the backend develops a bad case of blackhole syndrome and sucks itself up it's own behind.

    God damn it's always the simple things!

    Emile

Reply
  • Well I'm feeling very sheepish, my mantra is normally if nothing makes sense is to reboot it!

    Really glad it's working now Vikino!

    I've seen this sometimes happen when something in the backend develops a bad case of blackhole syndrome and sucks itself up it's own behind.

    God damn it's always the simple things!

    Emile

Children
No Data