Link to home
Start Free TrialLog in
Avatar of Dimarc67
Dimarc67Flag for United States of America

asked on

Routing on-premises internet traffic through existing Azure VPN and virtual network

We have established an Azure virtual network with multiple VMs, and a site-to-site VPN tunnel from our on-premises network to our Azure virtual network.  All connectivity and routing between the two is operational.  Azure VMs have internet access through their respective cloud-services' public IP addresses.

We'd like to design a routing solution for select on-premises servers that would route on-premises internet access through the VPN tunnel and Azure public IPs.

How might this be designed and implemented?  Perhaps using a software router running as a VM in our Azure virtual network?  This would, in theory, allow us to set static routes on the servers to send the traffic to the routing VM in Azure.

Thanks for your suggestions.

Dimarc67
Frederick, MD
Avatar of btan
btan

Having the s/w router seems viable but there can be challenges from the Azure side that I foreseen with the use case where you will want all the Azure instances to route thru VPN for on-premise Internet. The Internet gateway on Azure does not have such option available for configuration, to my best knowledge.

Furthermore, with multiple (and growing no. of) VM selection path(s) as static routing on your customised s/w router, the scale up performance and management of the many static routes can be challenging ...

I came across this article which may interest you to further assess possible use case (but can be complex and incurred additional cost) ...use of Forced Tunneling
The current generation Azure VNet has a default route for all public Internet traffic which is out over Azure’s managed Internet infrastructure (it’s just there and you can’t manage it or turn it off). On some other public cloud platforms you can disable public internet traffic by not adding an Internet Gateway – on Azure that option isn’t currently available.

In order to mitigate some challenges around controlling the path public traffic takes from an Azure VNet, Microsoft introduced Forced Tunelling which can be used to force traffic bound for the Internet back over your VPN and into your on-prem environment.

You must plan your subnets appropriately and only apply Forced Tunelling to those where required. This is especially important if you will consume any of Azure’s PaaS offerings other than Web or Worker Roles which can be added to an Azure VNet.
There is the mention of ExpressRoute which I see as dedicated "VPN" route that give you more control but it seems more of an overhaul (if taking this option), just for info
When using ExpressRoute you can use BGP to advertise the default route for all your Azure VNets to be back over your ExpressRoute connection to your on-prem environment. Unlike the VPN connection scenario though, where all Azure PaaS services will route back over your on-prem Internet gateway, with ExpressRoute’s peering you can use the public peer as the shortcut back to Azure.

While this is a better option than you get with VPN it still means you are pushing Azure calls back to your ExpressRoute gateway so you will potentially see a performance hit and will see the data included if you are using an IXP connection.
http://blog.kloud.com.au/2015/04/07/connection-options-when-building-an-azure-hybrid-cloud-solution/

Pardon me, just sharing some thoughts though they may not be fitting in your use case - probably to trigger off discussion on better means.
E.g. using Azure internal load balancer has been in my thoughts but doesn't really serve like a gateway or  forward proxy into public Internet unless it can be a Link balancer instead (which is not what I am aware of)...or using s/w instances of application delivery controller (ADC) to manage such link routing
Avatar of Dimarc67

ASKER

btan,

Thanks very much for the information you provided.  My research had found the same info, including ExpressRoute.  It's interesting how Azure is addressing their customer's challenges around connecting multiple premises networks to a single Azure environment, as well as the limitations of disabling public interfaces to instances.

Unfortunately, I don't think these areas are pertinent to our goal.

We currently run public-facing proxy servers in Azure to which we send browsing traffic over the VPN from our on-premises servers, and this model works well.  However, .NET issues are causing accumulative memory leaks that bring down our services (Microsoft has confirmed the leakage issue is in .NET, but they won't be addressing it anytime soon).  So we thought we might get around the .NET issues by routing all internet traffic through to our Azure vnet and to the internet from there.

Hence, the routing scenario and questions.  Maybe what we need is an Azure instance acting as a NAT firewall?
Looks like workaround to the real root cause, MS has to suggest the means rather than customer faced with this and trying to into options for forced scenario which may not be even sure to work out to resolve this real root cause. I am just afraid the internet routing may create more repercussion.

Regardless, I am thinking of on premise ADC to decide which gateway to take - either Azure instance (via VPN and static routing) that you mentioned as gateway or from on premise Internet gateway. The ADC (F5 LTM or Citrix Netscalar) form the proxy to "load-balance" the apps Internet route based on health of your on premise server .. just some thoughts
ASKER CERTIFIED SOLUTION
Avatar of btan
btan

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I think this may be greatly simplified.  It might be best to use a router (virtual or physical) in our on-premises network as the dedicated gateway for those servers that we want to configure to use Azure's IPs for internet.  If we configure the on-premises gateway router to route traffic to an Azure-hosted virtual NAT firewall, that would effectively provide what we're looking for.

For this I just need to identify suitable virtual router solutions.
None of the proposed solutions could be made functional, mainly due to seemingly strategic limitations in Azure.  Awarding points based on great effort, but we're shelving this idea for a while.