Deploy Dynamic Routing (BGP) between Azure VPN and Third-Party Firewall (Palo Alto)
Overview This blog explains how to deploy dynamic routing (BGP) between Azure VPN and a third-party firewall. You can refer to this topology and deployment guide in scenarios where you need VPN connectivity between an on-premises third-party VPN device and Azure VPN, or any cloud environment. What is BGP? Border Gateway Protocol (BGP) is a standardized exterior gateway protocol used to exchange routing information across the internet and between different autonomous systems (AS). It is the protocol that makes the internet work by enabling data routing between different networks. Here are some key points about BGP: Routing Between Autonomous Systems: BGP is used for routing between large networks that are under different administrative control, known as autonomous systems (AS). Each AS is assigned a unique number. Path Vector Protocol: BGP is a path vector protocol, meaning it maintains the path information that gets updated dynamically as routes are added or removed. This helps in making routing decisions based on path attributes. Scalability: BGP is designed to handle a large number of routes, making it highly scalable for use on the internet. Policy-Based Routing: BGP allows network administrators to set policies that can influence routing decisions. For example, administrators can prefer certain routes over others based on specific criteria such as path length or AS path. Peering: BGP peers are routers that establish a connection to exchange routing information. Peering can be either internal (within the same AS) or external (between different AS). Route Advertisement: BGP advertises routes along with various attributes such as AS path, next hop, and network prefix. This helps in making informed decisions on the best route to take. Convergence: BGP can take some time to converge, meaning to stabilize its routing tables after a network change. However, it is designed to be very stable once converged. Use in Azure: In Azure, BGP is used to facilitate dynamic routing in scenarios like connecting Azure VNets to on-premises networks via VPN gateways. This dynamic routing allows for more resilient and flexible network designs. Switching from static routing to BGP for your Azure VPN gateway will enable dynamic routing, allowing the Azure network and your on-premises network to exchange routing information automatically, leading to potentially better failover and redundancy. Why BGP? BGP is the standard routing protocol commonly used in the Internet to exchange routing and reachability information between two or more networks. When used in the context of Azure Virtual Networks, BGP enables the Azure VPN gateways and your on-premises VPN devices, called BGP peers or neighbors, to exchange "routes" that will inform both gateways on the availability and reachability for those prefixes to go through the gateways or routers involved. BGP can also enable transit routing among multiple networks by propagating routes a BGP gateway learns from one BGP peer to all other BGP peers. Diagram Pre-Requisite Firewall Network: Firewall with three interfaces (Public, Private, Management). Here, the LAB has configured with VM-series Palo Alto firewall. Azure VPN Network: Test VM, Gateway Subnet Test Network Connected to Firewall Network: Azure VM with UDR pointing to Firewall's Internal Interface. The test network should be peered with firewall network. Configuration Part 1: Configure Azure VPN with BGP enabled Create Virtual Network Gateway from marketplace Provide Name, Gateway type (VPN), VPN SKU, VNet (with dedicated Gateway Subnet), Public IP Enable BGP and provide AS number Create Note: Azure will auto provision a local BGP peer with an IP address from Gateway Subnet. After deployment the configuration will look similar to below. Make a note of Public IP and BGP Peer IP generated, we need this while configuring VPN at remote end. Create Local Network Gateway Local Network Gateway represents the firewall VPN network Configuration where you should provide remote configuration parameters. Provide Name, Remote peer Public IP In the Address space specify remote BGP peer IP (/32) (Router ID in case of Palo Alto). Please note that if you are configuring static route instead of dynamic you should advertise entire remote network ranges which you want to communicate through VPN. Here BGP making this process much simpler. In Advanced tab enable BGP and provide remote ASN Number and BGP peer IP create Create Connections with default crypto profile Once the VPN Gateway and Local Network Gateway has provisioned you can build connection which represents IPsec and IKE configurations. Go to VPN GW and under Settings, Add Connection Provide Name, VPN Gateway, Local Network Gateway, Pre-Shared Key Enable BGP If Required, Modify IPsec and IKE Crypto setting, else leave it as default Create Completed the Azure end configuration, now we can move to firewall side. Part 2: Configure Palo Alto Firewall VPN with BGP enabled Create IKE Gateway with default IKE Crypto profile Provide IKE Version, Local VPN Interface, Peer IP, Pre-shared key Create IPSec Tunnel with default IPsec Crypto profile Create Tunnel Interface Create IPsec Tunnel: Provide tunnel Interface, IPsec Crypto profile, IKE Gateway Since we are configuring route-based VPN, tunnel interface is very necessary to route traffic which needed to be encrypted. By this configuration your tunnel should be UP Now finish the remaining BGP Configurations Configure a Loopback interface to represent BGP virtual router, we have provided 10.0.17.5 IP for the interface, which is a free IP from public subnet. Configure virtual router Redistribution Profile Configure Redistribution Profile as below, this configuration ensures what kind of routers needed to be redistributed to BGP peer routers Enable BGP and configure local BGP and peer BGP parameters Provide Router ID, AS number Make sure to enable Install Route Option Configure EBGP Peer Group and Peer with Local BGP Peer IP, Remote (Azure)BGP Peer IP and Remote (Azure) BGP ASN Number. Also Specify Redistribution profile, make sure to enable Allow Redistribute Default Route, if you need to propagate default route to BGP peer router Create Static route for Azure BGP peer, 10.0.1.254/32 Commit changes Test Results Now we can test the connectivity, we have already configured necessary NAT and default route in Firewall. You can see the propagated route in both azure VPN gateway and Palo Alto firewall. FW NAT Name Src Zone Dst Zone Destination Interface Destination Address Service NAT Action nattovm1 any Untrust any untrust_inteface_pub_ip 3389 DNAT to VM1 IP nattovm2 any Untrust any untrust_interface_pub_ip 3000 DNAT to VM2 IP natto internet any Untrust ethernet1/1 default 0.0.0.0/0 SNAT to Eth1/1 Stattic Route configured: Azure VPN GW Connection Status and Propagated routes Azure Test VM1 (10.0.0.4) Effective routes Palo Alto BGP Summary Palo Alto BGP connection status Palo Alto BGP Received Route Palo Alto BGP Propagated Route Final Forwarding table Ping and trace result from Test VM1 to test VM2 Conclusion: BGP simplifies the route advertisement process. There are many more configuration options that we can try in BGP to achieve smooth functioning of routing. BGP also enables automatic redundancy and high availability. Hence, it is always recommended to configure BGP when it comes to production-grade complex networking.
Resolving private-link resource internal ip from VPN
Using a Point-To-Site VPN to connect my PC to an Azure VNET (e.g. 10.99.0.0/16), and then Private Link to publish my PaaS services as end-points into a subnet in this VNET (e.g. 10.99.2.0/24), I'm trying to understand how I resolve the internal IP of the PaaS resource from my PC. My configuration: VNET: 10.99.0.0/24 subnetVM: 10.99.1.0/24 subnetPaaS: 10.99.2.0/24 SubnetVPN: 10.99.99.0/24 VPN client adress pool: 172.20.20.0/24 If I create a VM in this VNET (e.g. 10.99.1.4), I get 168.63.129.16 as the DNS server and using: nslookup paasServicePublicDns or: nslookup paasServicePublicDns 168.63.129.16 will correctly give me the internal IP for the PaaS service (i.e. 10.99.2.4) But from my PC (connected via VPN to 10.99.99.0/24), using: nslookup paasServicePublicDns 168.63.129.16 will only give me the external/public IP for the PaaS service ok, the 168.63.129.16 adress might not be routed to the VPN VNET, so I also added this route to my PC: route add 168.63.129.16 MASK 255.255.255.255 172.20.20.4 (172.20.20.4 is my VPN endpoint on my PC) route print -4 | FIND "172.20.20.4": ---> Active Routes: Network Destination Netmask Gateway Interface Metric 10.99.0.0 255.255.0.0 On-link 172.20.20.4 43 10.99.255.255 255.255.255.255 On-link 172.20.20.4 281 168.63.129.16 255.255.255.255 On-link 172.20.20.4 26 172.20.20.0 255.255.255.0 On-link 172.20.20.4 43 172.20.20.4 255.255.255.255 On-link 172.20.20.4 281 172.20.20.255 255.255.255.255 On-link 172.20.20.4 281 224.0.0.0 240.0.0.0 On-link 172.20.20.4 281 255.255.255.255 255.255.255.255 On-link 172.20.20.4 281 <--- And to make sure the VPN connection has a DNS server defined I also added 168.63.129.16 as the DNS server for the VPN connection: ---> PPP adapter VNET-VPN: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : VNET-VPN Physical Address. . . . . . . . . : DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 172.20.20.4(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.255 Default Gateway . . . . . . . . . : DNS Servers . . . . . . . . . . . : 168.63.129.16 NetBIOS over Tcpip. . . . . . . . : Enabled <--- But still I can't get and IP adress resolved. Any ideas why this is not working?
active-active S2S VPN connections with Azure VPN Gateway Issue
I have a situation where I need to setup active-active mode on a VPN Gateway and need to create a primary and secondary failover to 1x on-premises site with 2x public IPs. On my Virtual Gateway, I have Primary and Secondary PIP's and I have 2 local gateways for on-premises. When I create the connection I do not have the option to select the secondary public IP of my Azure VPN Gateway as the failover/secondary IP for my on-prem. Detail: 1x Azure VPN Gateway(active-active mode) with 2x PIP 2x On-prem VPN Devices with 1 x PIP each We are looking to setup up High Availability, please advise how the setup works onAzure VPN Connection
Greetings - I don't know if this is possible in Azure, but I figured I would try as all the classes I have taken don't have an answer. I am new to Azure networking so what I want to do may not be possible. I have created an Azure VPN to our client. We have a SQL server there we pull data from there for reporting. I am trying to create an endpoint in Azure Data Factory to connect automatically over that VPN to run the reports. I have tried private links and PL Service but it looks like it can only be done in internal networks and not the gateway that the VPN is on. Any help would be appreciated. Thank you.Azure VMware Solution - Design Networking
Hello the community I would like your opinion and your help on the network implementation of the AVS solution Design picture I deployed a Vpn Gateway connection to interconnect the on-premise connection to Azure. (VpnGw Routed-Based 2e generation) I deployed Azure Route Server, Azure Bastion and Azure VMware Solution. To connect AVS to my Hub, I wanted to deploy another ExpressRoute Gateway in my hub. (purple, connection 2) Unfortunately, this doesn't seem possible. The peering (connection 4) doesn’t work, but I’m not really surprised. When I deployed AVS, an 'Azure vNet connect' option allowed me to create a new vNet, only in the same resource group (ResourceGroup_01_AVS). In this vNet, the vNet Gateway (ExR Gateway) is connected. I added a new subnet to connect the Jumpbox and manage AVS. It's not possible for me to create a new connection (connection 3) to AVS with a new ExpressRoute key. And to use ExpressRoute Global Reach, I need an existing ExpressRoute. (no available items) And for now, I only have one vpn. Since I’m at a dead end, I take any hypothesis of resolution. To complete the discussion, two diagrams I could find in Microsoft sessions that can complement our exchange. Use case 01 - AVS and NVA, VPN over ExR Use case 02- AVS and NVA, 2 Vnet Thank you in advance for your time and help.
Best Practices for Remote Desktop Access of Windows 10 Virtual Machine
Dear Experts, I want to use a Win10 VM on Azure as virtual desktop. For RDP, I will have to open port 3389. I want to know what are best practices for securely using RDP? I saw on Azure that VPN is an option. If I connect from a regular laptop/desktop to VM via Azure VPN, will it be free or there will be charges? Finally, if I make an inbound rule and open all connections on 3389 for a brief time to RDP to VM and then immediately block all inbound connection to Azure, will it be a very secure practice? Looking for your insight. Much appreciate your help. Thanks
Unable to access AKS services via S2S VPN
Hi, we establish S2S VPN connection between our environment in Azure and on-premises with our customer. On Azure we create a new vnet with address space 10.10.0.0/16. That network has: - GatewaySubnet (10.10.0.0/27) - environmentSubnet (10.10.8.0/21 > 10.10.8.1-10.10.15.254) Then we have Azure Kubernetes cluster (2 nodes) and internal loadbalancer (with static IP) for services inside k8s cluster. So each service has its own IP address from subnet environmentSubnet (10.10.8.0/24). For example: - kubernetesService01: 10.10.15.5 (port 8080) - kubernetesService03: 10.10.15.6 (port 8080) - kubernetesService04: 10.10.15.7 (port 8080) We can access all on-prmeises services from Azure - through VPN tunnel. The problem is in the opposite direction. From the on-premises to the Azure they can ping all the Kubernetes endpoints of service, they can ping Kubernetes infrastructure (both scale-sets/nodes), testing VM (which is in the same network like Kubernetes cluster) etc. But they can't reach our services inside Kubernetes, for example kubernetesService01/kubernetesService02/kubernetesService03 by specific port. So if they run telnet/curl on 10.10.15.5:8080, they dont get any response. We also configured NSG for Virtual machine scale set with rule - allow everything from everywhere. We tested connection between testing VM (which is in the same subnet like Kubernetes services, with IP 10.10.8.105) and Kubernetes services and telnet/curl works fine. I suppose that this means that the connection between vnet and Kubernetes services works? Routing form the VM to the service and then to the Kubernete endpoint must work fine. But for the difference of the Kubernetes services, they can telnet testing VM (telnet 10.10.8.105 22) from on-premises through VPN tunnel. Any idea what we can check or how we can monitor the traffic coming from the VPN tunnel? How to find out why they can ping pods within Kubernetes but can't access Kubernetes services on specific ports? Thank you!Issue with Azure VM Conditional Access for Office 365 and Dynamic Public IP Detection
Hi all, I have a VM in Azure where I need to allow an account with MFA to bypass the requirement on this specific server when using Office 365. I've tried to achieve this using Conditional Access by excluding locations, specifically the IP range of my Azure environment. Although I’ve disconnected any public IPs from this server, the Conditional Access policy still isn’t working as intended. The issue seems to be that it continues to detect a public IP, which changes frequently, making it impossible to exclude. What am I doing wrong?Routing traffic via Azure Firewall
Hey everyone, Quick question... I'm testing a new proxy provider and need to route all internet traffic over a VPN. As it stands some server Internet-bound traffic is routed directly out via Azure Firewall. Is it possible to forward this traffic from Azure firewall to VPN Gateway etc? I don't really want to remove the Azure Firewall, id like to configure the connection like this if possible: - Server > Azure Firewall > VPN > Proxy provider Thanks for reading!
