Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 27 subscribers
  • Views 2348 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

vNet Peering with XG in Azure

Dan Williams

Hi

We want to establish a hub and spoke configuration for vNETs in Azure and place our Sophos XG virtual appliance in the Hub vNET. The Hub vNET will then be the default gateway for internet access and a S2S IPSEC to an on-premise Cisco ASA. All "spoke" vNETs will gateway via the HUB. Currently this is setup and working with an Azure virtual network gateway to connect to on-premise via IPSEC VPN.

If we replace the virtual network gateway service with a Sophos XG VA, what I cant seem to find is how to route traffic back to the peered vNETs behind the Hub vNET on the XG. Do I need a "route inside" that returns the traffic to the peered vNETs?  if I do then what IP would I send the route inside to as there is no "core router"?

10.100.0.0./16 Production vNET

Subnet 10.100.1.0/24 - frontend subnet with virtual machines attached

Peered to HUB vNet using remote gateway

  

10.250.0.0/16 HUB vNet

10.250.1.0/24- frontend subnet

Peered to Production vNET allowing gateway transit

The plan is to replace the current virtual network gateway with an XG v18 appliacen

XG VA set as 10.250.1.1

routing table configured in the HUB vNet for 0.0.0.0 via 10.250.1.1 for outbound internet access

this should work OK for all devices in the HUB vNET

how does the XG know how to route traffic back to 10.100.0.0/16 ?

Any help much appreciated.



This thread was automatically locked due to age.
  • +1

    Hi Dan,

    Did you add a route on the XG for 10.100.0.0/16 via PortA; GW IP 10.250.1.1?  The XG would be 10.250.1.4 and the default GW in the hub vNet will be 0.0.0.0/0 via 10.250.1.4.

    Thanks,

    John

  • 0 in reply to axsom1

    Hi. Thanks for the feedback. Yes I found that the .1 address in every vNET is the router address, and so by adding a return route for the vNET via .1 on the XG this resolved the issue. I also had to add the routing table to every vNET so that 0.0.0.0/0 returned back via the LAN side IP of the XG device. Any NSGs assigned to the WAN interface on the XG also had to be reviewed to prevent the vNETs from accessing external services..

    Dan

Unfiltered HTML