Guest User!

You are not Sophos Staff.

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

RED Site to Site Routing

I am trying to get a RED Site to Site connection between a UTM (server) and an XG (client) to work. Here is what I have done so far:

 

1. RED Zone

I defined a RED zone with similar characteristics to the LAN zone.

2. RED Interface in XG

Defined RED interface, provided provisioning file from UTM and assigned zone as RED. Works like a charm!

3. Firewall Rule

Added two simple zone rules. RED to LAN and LAN to RED.

4. Static Routing

This is where I am struggling. In the UTM we defined our rule as gateway under static routing, but I can't seem to find the same in XG. I am guessing that I need to setup a Unicast Route with the desired network on the UTM as the destination and the interface pointing to the RED interface defined above. But what is the gateway? On the UTM the gateway IP points to an interface, but how does this work on the XG?

 

Thank you for your feedback!

Cheers,

Jens



This thread was automatically locked due to age.
Parents
  • Hi Jens,

    You're right it will be a unicast route and you'd set the source as the net behind the XG and the destination gateway to the RED interface IP of the UTM. On the UTM you'd create a gateway route for the net behind the UTM with the target as the XGs RED interface IP address :)

    Other than that, what you've said about the rest of your config looks good!

    Hope that helps you,

    Emile

  • I am still having trouble with this.

    Here is what I have:

    UTM network is 10.10.a.0/24 and XG network is 192.168.b.0/24.

    UTM RED adapter is set to 192.168.c.1 and XG RED adapter is set to 192.168.c.2.

    UTM Static Route is using gateway route type, network is set to 192.168.b.0/24 and the gateway is set to 192.168.c.2.

    XG Unicast Route network is set to 10.10.a.0/24, gateway is set to 192.168.c.1 and the interface is set to RED adapter 192.168.c.2.

     

    No ping is possible and the network cannot be accessed in both directions. RED is showing as connected on both devices.

    What am I missing?

  • Jens,

    If you use the Red to red connection, you only need to create the red configuration (as server) on one end, save the configuration and upload the configuration inside the red client.

    With v16 Red to red is possible between XG and UTM.

  • Hi Jen,

    Just a quick test to see if there is packet flow across the RED tunnel, from client at either end of the tunnel, try ping the opposite devices RED interface IP address. I.e. from UTM network try pinging the XGs RED interface IP. Make sure pings will respond from both sides in your settings first. If that succeeds that means the XG and UTM are fully talking to each other.

    A couple of checks I would do next (you will probably have done some of these already, just going over again):

    • Logs in the firewalls for either end showing blocked packets?
    • A firewall rule that allows 10.10.a.x to 192.168.b.x and another in reverse for any service on both devices (you didn't mention firewall rules for UTM)?
    • On the XG, what zone have you given the RED interface, make sure your firewall rules are referencing the correct zone?

    Looking forward to your replies,

    Emile

  • Hi Emile,

    I don't see any related issues in either firewall.

    On the UTM, there is a firewall rules that allows any service in both directions between the two subnets.

    On the XG, I have assigned the RED interface to a newly created RED zone which is a copy of the LAN zone at the moment. I also have two rules to allow RED -> LAN and LAN -> RED traffic for all services.

    I can also ping the RED interface on the local network.

    Luk, the RED interface is already working. It is hanging on actually reaching the other network. Basically, I just want to have access to the remote subnet on my local network. So, if the remote network is 10.10.a.0/24, I want to be able to ping and connect to that network using my local network at 192.168.b.0/24. Since the existing UTM configuration worked fine when the RED client was a UTM, I am assuming that I am missing some configuration on the XG.

    Thanks,

    Jens

  • Jens,

    a tcpdump output will help us. Also what is the output of traceroute command?

    Thanks

  • Hi Luk,

    tracrt from XG times out.

    Tracing route to server.domain.com [10.10.a.8]
    over a maximum of 30 hops:

      1     2 ms     2 ms     1 ms  vpn.domain2.com [192.168.b.1]
      2     *        *        *     Request timed out.
      3     *        *        *     Request timed out.
      4     *        *        *     Request timed out.
      5     *        *        *     Request timed out.
      6     *        *        *     Request timed out.

    ...

     

    I haven't used tcpdump before. I can look into it, but I would have to install it first.

    Cheers,

    Jens

  • Jens,

    tcpdump is already installed on both product. Have a look at this KB: https://sophserv.sophos.com/repo_kb/115343/file/308674.pdf

    Something is missing on your configuration.

  • Hi Jens,

    To do a TCPDump on the XG we will need to use Shell and I will detail what you need to do below :)

    Firstly we need to make sure SSH access is allowed by going to Administration > Device Access > Enable shell for the zone your device is going to be connecting to it from (i.e. LAN)

    Next we need an SSH tool like Putty which you can download from here: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html (you only need putty.exe)

    Once it's downloaded and SSH is enabled on the XG we will connect to it by running putty and entering the IP of the XG and making sure the XG button is selected. After it is connected you may receive a cert error which you can click yes to and ignore then you will be asked to login. This will be the "admin" (without quotes) login and password when prompted.

    We will now need to go to advanced shell which is option 5 then option 3.

    Now we need to do a TCPDump of the communications coming from the UTM network (10.10.a.x) so we can either do it by host IP or grapeshot it with the entire network and I will detail these below which you will need to type in (correcting my missing digits due to obfuscation):

    tcpdump -veni any host <ipaddress of device you're testing from>

    tcpdump -veni any net 10.10.a.0/24

    The first will focus the filter only on the host IP of either the destination/source stream of your test (angle brackets are also removed) and in the second command, once you've replaced a with your missing octet, will filter out and show any packets coming from that network.

    The results of this will be either:

    • Packets are arriving from the host/network and the XG has a bad firewall rule setup
    • Packets aren't arriving from the host/network and there is a problem with the UTMs firewall rules or the tunnel itself

    Hopefully it's the first because that's easier to diagnose :)

    Looking forward to your response!

    Emile

  • Jens,

    can you share your policy rules from XG side?

    Thanks

Reply Children
  • Hi Luk,

    Here is what I got.

     

    Based on your feedback I have made some changes to both rules and this has improved things. In specific, I unmarked matched users. I was assuming that Any means that it would work with any user, but I guess any means any authorized user. Thank you again for your help on finding that problem!

    Unfortunately, there are still more issues. While I can ping everything just fine, I can't connect to anything. IMAP, SMTP and web server all don't work. It seems that my zone role above doesn't allow all traffic or I am still missing another setting somewhere...

    Any suggestions?

    Thanks,

    Jens

  • This reply was deleted.
  • It turns out that the XG doesn't support tunnel compression. So, once I turned that off, it started working. :)

    Now, I just need to figure out why the WAN interface cannot do the DHCP renewal...

    A big thank you to Luk for all his help on this one!

    Cheers,

    Jens