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

Reply
  • 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

Children
  • 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

  • 0 in reply to vikino

    OK, it's time for packet captures...

    First, see if there's traffic either or both ways in the RED tunnel.

    On the RED server UTM:

    tcpdump -ni reds4 icmp

    On the RED client UTM:

    tcpdump -ni redc4 icmp

    If a ping from inside 192.168.3.0/24 leaves redc4 and arrives at reds4, that let's us eliminate some possibilities.  Now, let's look at the traffic between the device behind the RED 50 and the RED server UTM.

    Assuming the device is at 10.10.1.54 and the virtual NIC for the RED 50 is reds1:

    tcpdump -ni reds1 host 10.1.1.54 and icmp

    Please share the results of your tests.

    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,

    im testing it from the other UTM, because there is a server running on that LAN :-) What is different is only LAN subnet 192.168.5.0/24 and RED id 15

    Results are little more helpfull, i tested to host 10.10.1.62 where is almost no traffic to avoid mess in TCP dump.

    Client UTM:

    home:/home/login # tcpdump -ni redc15 icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on redc15, link-type EN10MB (Ethernet), capture size 65535 bytes
    08:36:58.720221 IP 192.168.5.251 > 10.10.1.62: ICMP echo request, id 1, seq 876, length 40
    08:37:03.491448 IP 192.168.5.251 > 10.10.1.62: ICMP echo request, id 1, seq 877, length 40
    08:37:08.490846 IP 192.168.5.251 > 10.10.1.62: ICMP echo request, id 1, seq 878, length 40
    ^C
    3 packets captured
    3 packets received by filter
    0 packets dropped by kernel

     

    Server UTM:

     utm:/home/login # tcpdump -ni reds15 icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on reds15, link-type EN10MB (Ethernet), capture size 65535 bytes
    08:36:58.732797 IP 192.168.5.251 > 10.10.1.62: ICMP echo request, id 1, seq 876, length 40
    08:37:03.501047 IP 192.168.5.251 > 10.10.1.62: ICMP echo request, id 1, seq 877, length 40
    08:37:08.500967 IP 192.168.5.251 > 10.10.1.62: ICMP echo request, id 1, seq 878, length 40
    ^C
    3 packets captured
    3 packets received by filter
    0 packets dropped by kernel

     

    Server UTM RED50 interface, host 10.10.1.62

    utm:/home/login # tcpdump -ni reds6 host 10.10.1.62 and icmp
    tcpdump: WARNING: reds6: no IPv4 address assigned
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on reds6, link-type EN10MB (Ethernet), capture size 65535 bytes
    08:36:58.740918 IP 10.10.1.62 > 192.168.5.251: ICMP echo reply, id 1, seq 876, length 40
    08:37:03.509048 IP 10.10.1.62 > 192.168.5.251: ICMP echo reply, id 1, seq 877, length 40
    08:37:08.508853 IP 10.10.1.62 > 192.168.5.251: ICMP echo reply, id 1, seq 878, length 40

     

    It seems that the problem can be on VLAN... That RED50 has no ethernet adress, but only Ethernet VLAN like this:  See EDIT

    It needs to be tagged, because as i told you switch mode does not allow me on RED50 to have untagged traffic + Tagged VLAN. on RED15 it works fine.

    There is also VLAN 9 and VLAN 2 interface binded to reds6.

     

    EDIT: Tryied to assign Ethernet IP to native interface, not VLAN...still no result...

     

    Vitek

  • 0 in reply to Emile Belcourt

    Hi Emile,

    rule any-any-any was allready tested, no result...

Unfiltered HTML