Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 2 subscribers
  • Views 3662 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

Route a different network through the VPN

Paul Nickerson

I've got Sophos UTM 9 on an instance in AWS, and my company would like to have a site-to-site IPSec VPN tunnel going to another company. The other company has its datacenter in Azure, and is using a Microsoft Azure Site-to-Site PolicyBased VPN Gateway. We have gotten the tunnel established successfully, and I'm able to hit a temporary box that the other company's got in the gateway's network (from my own client box). However, the network engineer in the other company would like me to be able to reach a server in a different subnet which he has "peered" with the gateway's subnet.

So, in Azure, the PolicyBased gateway is in 10.69.49.0/24, and the server he wants me to hit is in 10.69.18.0/24. He's got some Azure peer networking thing going that allows him to ping the server from that temporary box he stood up in 10.69.49.0/24. When I set up the VPN on UTM 9, I added both 10.69.49.0/24 and 10.69.18.0/24 as remote networks. But, only the 10.69.49.0/24 SA gets established successfully. I asked him to add 10.69.18.0/24 as an advertised network, but he says that's impossible to do in Azure's PolicyBased gateway.

So, is there any way to tell UTM 9 to route packets destined for 10.69.18.0/24 through this particular VPN tunnel? I've tried creating a static gateway route saying that network 10.69.18.0/24 goes to gateway 10.69.49.1, but that doesn't look like it's worked. Before I try troubleshooting that, can anyone tell me if that's even the right thing to do? I have not confirmed that 10.69.49.1 is actually the gateway in 10.69.49.0/24 which can route to 10.69.18.0/24, but I don't think that actually matters. I just need to get the packets going through that tunnel, I think.

I have checked the automatic firewall rules, and ones got created for both 10.69.49.0/24 and 10.69.18.0/24 as expected. Oh, and to add a wrinkle: I'm using a NAT rule to translate my client boxes all into one IP address that my VPN connection advertises as our local network. I've added both 10.69.49.0/24 and 10.69.18.0/24 to the "Going to:" section of that NAT rule.

Can anyone provide any advice on this?



This thread was automatically locked due to age.
  • 0

    Hi Paul and welcome to the UTM Community!

    Since there are no longer virtual NICs for IPsec connections, this is probably most easily done by having the other network engineer create a DNAT that translates some particular IP in 10.69.49.0/24 to the IP of the server in 10.68.18.0/24.  Any luck with that?

    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

    I did suggest that earlier with them, and got pushback. It's sounding like I'll need to push back on the pushback.

    I was actually going to ask about virtual NIC's for the IPSec tunnels. I wanted to see if I could confirm whether UTM was sending packets down the tunnel, and I was thinking of running a tcpdump for that, but I couldn't determine the interface to target when I was on the SSH shell. No virtual NIC must mean nothing for tcpdump --interface, right?

  • 0 in reply to Paul Nickerson

    You want espdump, Paul.  Find the REF_ of an IPsec Connection named "Data Center" with:

    cc get_object_by_name ipsec_connection site_to_site 'Data Center'|grep \'ref

    Say that gives you REF_IpsSitDataCenter

    espdump -n --conn REF_IpsSitDataCenter -vv

    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

    Cool, thank you. With that espdump running, I can confirm that when I got on one of my client boxes and try to connect to something (nonexistent) inside 10.69.49.0/24, packets are going through the tunnel. But when I try to connect to something inside 10.69.18.0/24, no packets go through the tunnel. So I know my route rule definitely does not work. Probably because of the lack of a virtual NIC, like you said.

Unfiltered HTML