Forum Widgets
Latest Discussions
What would be the expected behavior for an NSP?
I'm using a network security perimeter in Azure. In the perimeter there are two resources assigned: A storage Account and An Azure SQL Databse. I'm using the BULK INSERT dbo.YourTable FROM 'sample_data.csv' getting data from the storage account. The NSP is enforced for both resources, so the public connectivity is denied for resources outside the perimeter I have experienced this behavior: the azure SQL CANNOT access the storage account when I run the command. I resolved using: I need to add an outbound rule in the NSP to reach the storage fqdn I need to add an inbound rule in the NSP to allow the public IP of the SQL Azure When I do 1 and 2, azure SQL is able to pump data from the storage. IMHO this is not the expected behavior for two resources in the NSP. I expect that, as they are in the same NSP, they can communicate to each other. I have experienced a different behavior when using keyvault in the same NSP. I'm using the keyvault to get the keys for encryption for the same storage. For the key vault, i didn't have to create any rule to make it able to communicate to the storage, as they are in the same NSP. I know, Azure SQL is in preview for the NSP and the keyvault in GA, but I want to ask if the experienced behavior (the SQL CANNOT connect to the storage even if in the same NSP) is due to a unstable or unimplemented feature, or I'm missing something? What is the expected behavior? Thank you community!!
Alert rule for SLB metrics at scale
For one single SLB, we can create alert rule to monitor SLB metrics like data path availability, health probe status. But when creating alert for SLB from resource group or subscription level, SLB metrics like data path availability and health probe status are not available. If there're hundreds of SLB needing alert rule to monitor SLB metrics, current situation will make maintenance more complicated. Please considering to support creating alert rule for SLB metrics at scale.
Traffic processing BGP Azure VPN gateway A/A
Hello, Can someone explain how Azure processes the traffic with implemented a VPN gateway in Active Active mode?. Azure firewall premium is also configured. BGP is without preferences. The user route definition is set up to the next hop Azure firewall . Is it possible in this scenario occurs the asymmetric routing with traffic drop by azure firewall ? In my understand is that, if we need to configure User route definition on Gateway subnet to inspect traffic to peering subnet, so the firewall don't see traffic passing through VPN gateway. Traffic going through ipsec tunnels can go different paths and firewall do not interfere because everything is routed to it by user route definition.
Azure ExpressRoute - Cisco Meraki MX or directly into LAN?
We are in the process of deploying Azure ExpressRoute across multiple sites via a provider Layer 2 VPLS circuit and are evaluating our CPE options. Our provider is delivering a Layer 2 handoff to each site, meaning we are responsible for all Layer 3 BGP configuration on the customer edge. We currently run a full Cisco Meraki environment — Meraki MX appliances as our edge firewalls and Meraki MS switches on the LAN side — and are wondering if anyone has successfully terminated an ExpressRoute BGP session directly on a Meraki MX, or alternatively terminated it directly into the LAN without a dedicated edge router in between. Terminating ExpressRoute BGP directly on a Meraki MX appliance — is this even possible given Meraki's limited BGP support? Connecting the Layer 2 provider handoff (dot1Q or QinQ) directly into a Meraki MS LAN switch and routing from there — has anyone made this work, and what were the caveats? Running a dedicated CPE router in front of the Meraki MX — and if so, how did you handle the integration between the CPE router and the Meraki SD-WAN fabric, particularly around route advertisement and traffic steering? Our provider model uses QinQ VLAN tagging with a provider-assigned S-tag and customer-defined C-tags for private and Microsoft peering. Since the provider is only delivering Layer 2, all BGP session establishment, prefix advertisement, and routing policy must be handled entirely on our CPE. Our understanding is that Meraki MX does not support QinQ subinterfaces or the level of BGP policy control needed for ExpressRoute, but we wanted to see if anyone has found a creative workaround before we commit to dedicated CPE hardware at each site. Device recommendations welcome: If a dedicated CPE router is the only viable path, we'd also love to hear what devices others have used successfully for this use case. Our circuit is 1Gbps, so we need something that can handle that throughput comfortably with BGP active — but we're a mid-size enterprise and are looking for cost-effective options rather than carrier-grade platforms. What has worked well for you without breaking the budget? Any real-world experience, gotchas, or recommended architectures would be greatly appreciated, especially from anyone running a Meraki-only environment who has tackled this!Azure VM Persistent Route Setup
Hi I hope to get some advice on a routing issue from Azure to an on-premises system. A little background first, please bear with me: We have an on-premises VM that connects to an isolated Thirdparty network via an On-Prem Cisco ASA FW specifically for this purpose. ------------------------------------------------------------------------------- OnPrem VM's IP: 10.100.10.23/24 OnPrem dedicated FW - Local Inside Interface IP: 10.100.10.190 -------------------------------------------------------------------------------- OnPrem dedicated FW - 3rdParty Interface IP: 10.110.255.137 Thirdparty router IP: 10.110.255.138 - This routes to aditional devices on 10.10.227.10 and 20.10.227.10. -------------------------------------------------------------------------------- There are static routes configured for 3rd party FW interface using: 3rdParty Interface - 10.10.227.10 255.255.255.255 - 10.110.255.138 (Gateway IP) 3rdParty Interface - 20.10.227.10 255.255.255.255 - 10.110.255.138 (Gateway IP) -------------------------------------------------------------------------------- The on-premises VM (10.100.10.23) has persistent routes added to allow connectivity: Network Address Netmask Gateway Address Metric 10.10.227.10 255.255.255.255 10.100.10.190 1 20.10.227.10 255.255.255.255 10.100.10.190 1 10.110.255.136 255.255.255.252 10.100.10.190 1 --------------------------------------------------------------------------------- The above works fine on-prem but I now need to migrate the On-Prem VM service into Azure. Azure Side I have created a test Azure VM with a static IP in an isolated subnet (no other devices using it) in the Production subscription of our LZ (Hub and Spoke topology). We have a site-to-site VPN connected to our on-premises FW using a VPN Gateway configured in the Connectivity subscription of our LZ (as expected). We have defined subnets for on-premises address spaces in the Local Network Gateway: 10.100.10.0/24, 10.100.11.0/24, 10.100.13.0/24, 10.100.14.0/24 (Local Subnets) and 172.16.50.0 (VPN client Subnet) --------------------------------------------------------------------------------------- Main Problem that I'm requesting advice for: When I add the defined persistent routes on the Azure VM (IP address: 10.150.1.10/24) as is on the On-Prem VM Network Address Netmask Gateway Address Metric 10.10.227.10 255.255.255.255 10.100.10.190 1 20.10.227.10 255.255.255.255 10.100.10.190 1 10.110.255.136 255.255.255.252 10.100.10.190 1 I'm unable to ping the 10.10.227.10 and 20.10.227.10 addresses, even though the routes have been added by the 3rd party on their network side. All Network Objects, static routes, groups and rules are duplicated on the ASA FW for the Azure VM as is for the On-Prem VM and I can access/ping the ASA FW inside interface no problem . Is there a specific way I need to route the persistent routes from Azure side, have I missed something in the configuration above to get the connectivity I require? Please all advice is welcomed! Thank you Nitrox
Help ! - Hub Spoke Architecture and Routing via NVA
I have a classic example of routing. I want to force all traffic via Fortigate firewalls. EastWest and NorthSouth. However when large Supernet of Azure Vnet is used to route and force the traffic via UDR at gateway subnet, its not working. Because Routes learned at Hub Vnet via Vnet peering is taking precedence. To isolate, i have created multiple small subnet routes for Gateway subnet. Each pointing to spoke vnet and next hop as Fortigate firewall. However this is working, i want to make solution solid. Means if someone creates new vnet in future and peer with Hub, it should not get direct traffic. Is that possible? Or this is typical shortcoming of Azure where routing works with preference to vnet peeering.? Below is architecture -Help! - How is VNet traffic reaching vWAN/on‑prem when the VNet isn’t connected to the vWAN hub
Hello, I needed some clarity on how the following is working: Attached is a network diagram of our current setup. The function apps (in VNet-1) initiate a connection(s) to a specific IP:Port or FQDN:Port in the on-premises network(s). A Private DNS zone ensures that any FQDN is resolved to the correct internal IP address of the on-prem endpoint. In our setup, both the function app and the external firewall reside in the same VNet. This firewall is described as “Unattached” because it is not the built-in firewall of a secured vWAN hub, but rather an independent Azure Firewall deployed in that VNet. The VNet has a user-defined default route (0.0.0.0/0) directing all outbound traffic to the firewall’s IP. The firewall then filters the traffic, allowing only traffic destined to whitelisted on-premises IP: Port or FQDN: Port combinations (using IP Groups), and blocking everything else. The critical question and the part that I am unable to figure out is: Once the firewall permits a packet, how does Azure know to route it to the vWAN hub and on to the site-to-site VPN? Because VNet-1 truly has no connection at all to the vWAN hub (no direct attachment, no peering, no VPN from the NVA). But the traffic is still reaching the on-prem sites. Unable to figure out how this is happening. Am I missing something obvious? Any help on this would be appreciated. Thank you!
Trying to configure 3rd Party VPN from CloudGenix ION device
Hi all, I am trying to get my VPN from my CloudGenix ION connected to an Azure instance through a traditional IPSec VPN. I have everything configured but my device requires me to add an Inner Tunnel IP Address but the MSP for the customer doesn't see this setting in their Azure VPN configuration. Does anyone know how to, or where to add this in Azure's VPN settings?
I can no longer connect to some of the nodes over pfSense IPSec running in Azure
This used to work flawlessly and I didn't change anything in the configuration, so this may have happened after upgrading to pfSense 2.5.2, or after some Azure changes. Specifically, I can no longer connect to the Azure VMs which use the same subnet as my Azure pfSense instance. I can, however, connect to other VMs that reside in a Peered address space. My infrastructure is: One Internet-facing pfSense instance in Azure, running IPSec (let's call it PF) Clients connecting to PF over IPSec Several VMs using the same subnet as the PF (let's call them VMA) Some other VMs using another peered subnet (VMB) PF is configured to pass all IPSec traffic (Local Network set to https://0.0.0.0/0) I have since enabled the following, to no avail: IP forwarding on the LAN-facing PF NIC Azure UDR rule for https://0.0.0.0/0, making the next hop at PF appliance and associated it with the LAN subnet which all VMA use What I have found out so far is that: the traffic originating from an IPSec client to VMA shows up in tcpdump on both enc0 and LAN interfaces in PF, and: one-way traffic shows up in tcpdump on VMA *only* after enabling IP forwarding, but the VM is sending ARP request for the IP address and doesn't seem to be using the routing table: 15:19:00.578098 IP 10.1.1.1.52074 > 10.1.0.6.22: Flags [S], seq 2814773395, win 65535, options [mss 1198,nop,wscale 6,nop,nop,TS val 442515869 ecr 0,sackOK,eol], length 0 15:19:00.578191 ARP, Request who-has 10.1.1.1 tell 10.1.0.6, length 28 Tracerouting on VMA to any of the IPSec clients also confirms that VMA is unaware of the table rule I added. there are no firewall rules blocking it in PF the traffic originating from an IPSec client to VMB shows up in tcpdump on both enc0 and LAN interfaces in PF, and: two-way traffic does show up in tcpdump on VMB I can ping/connect to any of the VMs running on Azure or IPSec clients directly from my PF instance. I have run out of the ideas on how to proceed here. So far it looks like everything is fine on pfSense end. It does seem like routing issue, even though it used to work just fine up until recently. EDIT1: I just checked the Effective Routes on one of the VM's NIC, and am seeing the Default Active 10.1.0.0/23 Virtual network route, which is listed first, while my UDR is last. The 10.1.0.0/23 is my LAN subnet, which includes the IPSec clients. What does one do in this case? EDIT2: I can see that the communication with VMB works fine because of the effective rule that handles that: Default Active 10.2.0.0/24 VNet peering EDIT3: I added a UDR targeting my IPSec clients specifically, which according to https://aidanfinn.com/?p=21480 should take precedence over the default rules, but still to no avail 😕 EDIT4: the Next Hop in Azure correctly shows PF as as a next hop from VMA.
VPN Gateway - BGP AS PATH - Steer which VPN tunnel traffic will flow form Azure to OnPrem
Can anyone confirm whether in the topology that Microsoft calls "Active-active VPN gateways" we can steer which VPN tunnel is utilized using AS PATH? Or is it by definition active/active, meaning we can't avoid utilizing both tunnels simultaneously and probably we have to deal with asymetric routing? MS article about different topologies: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-highlyavailable#activeactiveonprem My findings: Because the Azure gateway instances are in active-active configuration, the traffic from your Azure virtual network to your on-premises network will be routed through both tunnels simultaneously, even if your on-premises VPN device might favor one tunnel over the other. However, according to the Microsoft FAQ about BGP: Yes, Azure VPN gateway honors AS Path prepending to help make routing decisions when BGP is enabled. A shorter AS Path is preferred in BGP path selection.
