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

  • Hi Emile,

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

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