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!

  • No...:-(

    Posting screenshots, tryied single FW rules as you mentioned, also combined rule as on screenshot...

    Client (192.168.6.0/24)

     

    Server

    One more thing...Tested from 3 PCs to avoid routing problems in client PC...

  • And there are no drops in the firewall or Intrusion Prevention log?  Are there any other static routes in place that might conflict with these - anything curious in the routing table on either UTM?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Firewall is clear, no drops on those subnets, IPS is disabled on both sides.

    No other static routes, no policy routes, only standard internal routing and BGP routing, in BGP there is no conflicting subnet with any of subnets im using.

    If somebody want, we can do teamviewer session, or should i contact sophos support?

  • "IPS is disabled on both sides." - Sometimes, the problem is with UDP Anti-Flooding activity, and that's in the IPS log.  I don't expect that to be the issue, but it never hurts to look.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Enabled IPS to be able to look into Live log...also nothing... :-(

  • What/where is 192.168.5.251?  It's not on your diagram.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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
Reply
  •      '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
Children
  • 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

  • Yeah, you definitely need to kick yourself for not having tried a reboot of the Master three months ago.  I can't believe none of us thought of doing that.

    Growing up, one of my father's mantras was, "Always try the easy things first" when working on a problem.  When I got to be the age he was when he discovered that, I realized he could have said that, "People make things in such a way that the parts most likely to need fixing are the easiest to fix."

    Anyway, there's a collective facepalm for everyone that looked at this thread and didn't make the obvious suggestion.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I know that it is the easiest thing,but if you have some bigger network with 14 REDs working without problem + IPsec tunnels working and one one thing of all has problem,i wouldnt expect that reboot can help. Uptime was about 20 days sice last update installed, i've seen not patched Astaro running at full load 3 years...

    Anyway, i want to say thank you to all participed in this issue, especially to Bob!

    Maybe next time i can be helpfull for someone else here at community :-)