Can only remote into azure vm from DC
Hi all, I have set up a site to site connection from on prem to azure and I can remote in via the main dc on prem but not any other server or ping from any other server to the azure. Why can I only remote into the azure VM from the server that has Routing and remote access? Any ideas on how I can fix this?Azure Networking Portfolio Consolidation
Overview Over the past decade, Azure Networking has expanded rapidly, bringing incredible tools and capabilities to help customers build, connect, and secure their cloud infrastructure. But we've also heard strong feedback: with over 40 different products, it hasn't always been easy to navigate and find the right solution. The complexity often led to confusion, slower onboarding, and missed capabilities. That's why we're excited to introduce a more focused, streamlined, and intuitive experience across Azure.com, the Azure portal, and our documentation pivoting around four core networking scenarios: Network foundations: Network foundations provide the core connectivity for your resources, using Virtual Network, Private Link, and DNS to build the foundation for your Azure network. Try it with this link: Network foundations Hybrid connectivity: Hybrid connectivity securely connects on-premises, private, and public cloud environments, enabling seamless integration, global availability, and end-to-end visibility, presenting major opportunities as organizations advance their cloud transformation. Try it with this link: Hybrid connectivity Load balancing and content delivery: Load balancing and content delivery helps you choose the right option to ensure your applications are fast, reliable, and tailored to your business needs. Try it with this link: Load balancing and content delivery Network security: Securing your environment is just as essential as building and connecting it. The Network Security hub brings together Azure Firewall, DDoS Protection, and Web Application Firewall (WAF) to provide a centralized, unified approach to cloud protection. With unified controls, it helps you manage security more efficiently and strengthen your security posture. Try it with this link: Network security This new structure makes it easier to discover the right networking services and get started with just a few clicks so you can focus more on building, and less on searching. What you’ll notice: Clearer starting points: Azure Networking is now organized around four core scenarios and twelve essential services, reflecting the most common customer needs. Additional services are presented within the context of these scenarios, helping you stay focused and find the right solution without feeling overwhelmed. Simplified choices: We’ve merged overlapping or closely related services to reduce redundancy. That means fewer, more meaningful options that are easier to evaluate and act on. Sunsetting outdated services: To reduce clutter and improve clarity, we’re sunsetting underused offerings such as white-label CDN services and China CDN. These capabilities have been rolled into newer, more robust services, so you can focus on what’s current and supported. What this means for you Faster decision-making: With clearer guidance and fewer overlapping products, it's easier to discover what you need and move forward confidently. More productive sales conversations: With this simplified approach, you’ll get more focused recommendations and less confusion among sellers. Better product experience: This update makes the Azure Networking portfolio more cohesive and consistent, helping you get started quickly, stay aligned with best practices, and unlock more value from day one. The portfolio consolidation initiative is a strategic effort to simplify and enhance the Azure Networking portfolio, ensuring better alignment with customer needs and industry best practices. By focusing on top-line services, combining related products, and retiring outdated offerings, Azure Networking aims to provide a more cohesive and efficient product experience. Azure.com Before: Our original Solution page on Azure.com was disorganized and static, displaying a small portion of services in no discernable order. After: The revised solution page is now dynamic, allowing customers to click deeper into each networking and network security category, displaying the top line services, simplifying the customer experience. Azure Portal Before: With over 40 networking services available, we know it can feel overwhelming to figure out what’s right for you and where to get started. After: To make it easier, we've introduced four streamlined networking hubs each built around a specific scenario to help you quickly identify the services that match your needs. Each offers an overview to set the stage, key services to help you get started, guidance to support decision-making, and a streamlined left-hand navigation for easy access to all services and features. Documentation For documentation, we looked at our current assets as well as created new assets that aligned with the changes in the portal experience. Like Azure.com, we found the old experiences were disorganized and not well aligned. We updated our assets to focus on our top-line networking services, and to call out the pillars. Our belief is these changes will allow our customers to more easily find the relevant and important information they need for their Azure infrastructure. Azure Network Hub Before the updates, we had a hub page organized around different categories and not well laid out. In the updated hub page, we provided relevant links for top-line services within all of the Azure networking scenarios, as well as a section linking to each scenario's hub page. Scenario Hub pages We added scenario hub pages for each of the scenarios. This provides our customers with a central hub for information about the top-line services for each scenario and how to get started. Also, we included common scenarios and use cases for each scenario, along with references for deeper learning across the Azure Architecture Center, Well Architected Framework, and Cloud Adoption Framework libraries. Scenario Overview articles We created new overview articles for each scenario. These articles were designed to provide customers with an introduction to the services included in each scenario, guidance on choosing the right solutions, and an introduction to the new portal experience. Here's the Load balancing and content delivery overview: Documentation links Azure Networking hub page: Azure networking documentation | Microsoft Learn Scenario Hub pages: Azure load balancing and content delivery | Microsoft Learn Azure network foundation documentation | Microsoft Learn Azure hybrid connectivity documentation | Microsoft Learn Azure network security documentation | Microsoft Learn Scenario Overview pages What is load balancing and content delivery? | Microsoft Learn Azure Network Foundation Services Overview | Microsoft Learn What is hybrid connectivity? | Microsoft Learn What is Azure network security? | Microsoft Lea Improving user experience is a journey and in coming months we plan to do more on this. Watch out for more blogs over the next few months for further improvements.
WordPress App how to restrict access to specific pages on the site
Hello all, I have a WordPress App hosted on Azure and I am struggling with how I can secure specific pages from public access. For example: http://www.mysite.com/wp-admin http://www.mysite.com/info.php I'd like it so that only specific IP addresses or Microsoft user accounts can access some, such as admin pages and for some pages I'd like no access at all, to where it just blocks any sort of visit. I've viewed the documentation for Front Door and some networking restrictions but that seems to be just IP addresses and I'm confused about how I can set those rule for specific pages within the App. I know WordPress offer plugins which have this sort of functionality but I'd like to take advantage of Azure's security features rather than plugins from WordPress. Any help is very appreciated. Thank you
Accelerate designing, troubleshooting & securing your network with Gen-AI powered tools, now GA.
We are thrilled to announce the general availability of Azure Networking skills in Copilot, an extension of Copilot in Azure and Security Copilot designed to enhance cloud networking experience. Azure Networking Copilot is set to transform how organizations design, operate, and optimize their Azure Network by providing contextualized responses tailored to networking-specific scenarios and using your network topology.
Azure Front Door rules engine scenarios and configurations
*This post is a continuation of Azure Front Door's earlier blog on the topic. If you haven’t read it yet, you can find it: Revolutionizing hyperscale application delivery and security: The New Azure Front Door edge platform | Microsoft Community Hub The Azure Front Door rules engine allows users to easily customize processing and routing logic at the Front Door edge by configuring match condition and action pairs. You can define various rule actions based on combination of various supported match conditions from incoming requests. These rules allow you to: Manage cache policy dynamically Forward requests to different origins or versions Modify request or response headers to hide sensitive information or passthrough important information through headers. For example, implementing security headers to prevent browser-based vulnerabilities like: HTTP strict-transport-security (HSTS) X-XSS-protection Content-security-policy X-frame-options Access-Control-Allow-Origin headers for cross-origin resource sharing (CORS) scenarios. Security-based attributes can also be defined with cookies. Rewrite URL paths or redirect requests to new destinations Enable complex scenarios using regex and server variables: capture dynamic values from incoming requests or responses and combine them with static strings or other variables. This article covers common use cases supported by the rules engine, and how to configure these rules to meet your needs via Azure portal. You can find out Azure Resource Manager (ARM) template examples to help automate deployment of these capabilities in Azure Front Door rules engine scenarios. Scenario 1: Redirect using query string, URL path segments, or incoming hostname captures Managing redirects is critical for search engine optimization (SEO), user experience, and the proper functioning of a website. Azure Front Door's rules engine and server variables allow you to efficiently manage batch redirects based on various parameters. Redirect based on query string parameters You can redirect requests using query fields of the incoming URL by capturing the value of a specific query string key in the format {http_req_arg_<key>}. This approach enables dynamic redirects without having to create a separate rule for each cdpb value, significantly reducing the number of rules required. For example, extract the value of cdpb query key from an incoming URL: https://example.mydomain.com/testcontainer/123.zip?sig=fffff&cdpb=teststorageaccount and use it to configure the “destination host” into outgoing URL: https://teststorageaccount.blob.core.windows.net/testcontainer/123.zip?sig=fffff&cdpb=teststorageaccount. Redirect based on fixed-length URL path segments You can redirect requests to different origins based on fixed-length URL path segment by capturing the URL segments using {variable:offset:length}. For more information, see Server variable format. For example, consider a scenario where the tenant ID is embedded in the URL segment and is always six characters long, such as: https://api.contoso.com/{tenantId}/xyz. To extract {tenantId} from the URL and decide the correct redirect to use in the format of tenantId.backend.com/xyz. This approach eliminates the need to create a separate rule for each tenant ID, allowing you to handle dynamic routing with fewer rules. Redirect based on dynamic-length URL path segments When the URL path segment has a dynamic length, you can extract it using the {url_path:seg#}. For more information, see Server variable format. For example, if a tenant ID or location is embedded in the URL segment, such as: https://api.contoso.com/{tenantId}/xyz, you can extract {tenantId} from the URL and decide the correct redirect in the format of tenantId.backend.com/xyz with server variable {url_path:seg0}.backend.com in the redirect destination host. This method avoids creating separate rules for each tenant ID, enabling more efficient configuration. This can be configured via command line tools. Learn about how to configure for this rule via Azure Resource Manager (ARM) template in Azure Front Door rules engine scenarios. Redirect based on part of the incoming hostname You can redirect requests to different origins by extracting part of the incoming hostname. For example, you can capture tenantName from https://[tenantName].poc.contoso.com/GB to redirect the request to s1.example.com/Buyer/Main?realm=[tenantName]&examplename=example1 using the offset and length in server variable in the format of {hostname:0:-16}. For more information, see Server variable format. Scenario 2: Populate or modify a response header based on a request header value In some scenarios, you might need to populate or modify a response header based on a request header value. For example, you can add CORS header where needed to serve scripts on multiple origins from the same CDN domain, and response must contain the same FQDN in Access-Control-Allow-Origin header as the request origin header, rather than a wildcard allowing all domains (*) to enhance security. You can achieve it by using the {http_req_header_Origin} server variable to set the response header. Scenario 3: Rename a response header to a brand-specific one You can rename a response header generated by a cloud provider by adding a new custom response header and deleting the original. For example, you can replace the response header X-Azure-Backend-ID with a brand-specific header X-Contoso-Scale-ID. Scenario 4: A/B testing (experimentation) Splitting incoming traffic into two origin groups can be is useful in A/B testing, rolling deployments, or load balancing without complex backend logic. For example, you can split incoming traffic based on the client port number. A rule can match client ports that end in 1, 3, 5, 7, or 9 and forward those requests to an experiment-origin-group. All other traffic continues to the default origin group per route settings. The previous regex is just an example. You can explore and test your own expressions using tools like regex101. Note Since client ports are random, this method typically results in an approximate 50/50 traffic split. However, the presence of any proxies or load balancers between clients and the Front Door might affect this assumption due to factors like connection reuse or source port rewriting. Use logs or metrics to validate the actual behavior in your environment. Scenario 5: Redirect with URL path modification and preserve capability In some scenarios, you might need to add new segments or remove some segments while preserving the rest of the URL path. For example, if you want to redirect https://domain.com/seg0/seg1/seg2/seg3 to https://example.com/seg0/insert/seg2/seg3. In this scenario, you replace URL path’s {seg1} with /insert/ while preserving the rest of the URL path. Azure Front Door achieves the desired redirect by combining values extracted from server variables (URL segments) and combining static string segment /insert/. You can use Int32.Max (2147483647) for URL segment’s length field to keep all segments from seg2 to segn. For more information, see Server variable format. Note Similar configuration can be done for URL rewrite action by inputting source pattern as / and destination as /{url_path:seg0}/insert/{url_path:seg2:2147483647} for redirect action as shown in the following portal example. Scenario 6: Redirect by removing fixed parts of a URL path You can remove fixed segments of known size from a URL path, such as country codes (us) or locales (en-us), while preserving the rest of the URL path. For example, if you want to redirect https://domain.com/us/seg1/seg2/seg3/ to https://example.com/seg1/seg2/seg3/, you need to remove the country code /us/ and keep the rest of the URL path unchanged. To achieve this, use {variable:offset} , which includes the server variable after a specific offset, until the end of the variable. For more information, see Server variable format. Note Similar configuration can be done for URL rewrite action by inputting source pattern as / and destination as /“{url_path:3} for redirect action as shown in the following portal example. Scenario 7: URL rewrite by removing one or more segments of URL path You can remove one or more segments from a URL path, such as country codes (us) or locales (en-us), while preserving the rest of the URL path. For example, if you want to rewrite https://domain.com/us/seg1/seg2/seg3/ to https://origin.com/seg2/seg3/, you need to remove both the country code and an additional segment /us/seg1/ while keeping the rest of the URL path intact. To achieve this, use the {url_path:seg#:length} server variable format to capture specific URL segments starting from a particular segment number. In this example, use {url_path:seg2:2147483647} to capture all segments starting from seg2 to the end. The value 2147483647 (Int32.Max) ensures all remaining segments are included. For more information, see Server variable format. Note When using server variables like {url_path} in the Destination field, the Preserve unmatched path setting becomes less relevant because server variables give you explicit control over which parts of the URL path to include. Scenario 8: Use regex to reduce the number of rule conditions and avoid hitting limits Using regex in rule conditions can significantly reduce the number of rules required, which helps avoid rule limits that can be a blocker for customers who need conditions or actions for hundreds of clients. For example, if a customer wants to identify their clients with a specific ID pattern to allow access to a resource behind Azure Front Door, clients send a header like x-client-id: SN1234-ABCD56. This header follows a specific format: x-client-id: <SN + 4 digits + - + 4 uppercase letters + 2 digits>. Instead of creating individual rules for each possible client ID, you can use a single regex pattern ^SN[0-9]{4}-[A-Z]{4}[0-9]{2}$ to match all valid client IDs in one rule, for example, SN1234-ABCD56, SN0001-ZYXW99, SN2025-QWER12, SN9876-MNOP34, SN3141-TEST42, etc. This approach allows you to handle hundreds of different client IDs with a single rule configuration. Scenario 9: Modify origin redirects using response header captures You can make action fields dynamic by using response header values as server variables. This is useful when origin servers issue redirects that reference their own domain names. The problem: Origin servers like Azure App Service commonly issue redirect URLs that reference their own domain name (for example, contoso.azurewebsites.net). If these URLs reach the client unmodified, the next request bypasses Azure Front Door, which disrupts the user's navigation experience. The solution: Capture the origin's Location header and rewrite just the host portion so it always reflects the hostname that the client originally used. For example, if the frontend client's host header to Azure Front Door is contoso.com and the origin is contoso.azurewebsites.net, when the origin issues an absolute redirect URL like Location: https://contoso.azurewebsites.net/login/, you can modify the location header back to use the original hostname Location: https://contoso.com/login/ This is achieved using the server variable format: https://{hostname}{http_resp_header_location:33}, where: {hostname} represents the original client hostname (contoso.com) {http_resp_header_location:33} captures the Location header content starting from offset 33 (the /login/ part) For more information, see Preserve the original HTTP host name between a reverse proxy and its back-end web application. Note This rule can be used when rule condition is based on request parameters or when invoked unconditionally. For consistent offset calculation, all origin servers in the origin group should have domain names of the same length, for example, all 33 characters like https://contoso.azurewebsites.net. Ideally, there should be just one origin server, but multiple origins are acceptable if their names have identical lengths. You can apply the same server variable capture technique to extract and reuse request query string parameters in different rule actions. Scenario 10: If-elseif-else rules The Azure Front Door rules engine doesn't natively support traditional conditional logic with "if-elseif-else" structures. By default, all rules are independently evaluated as "if condition1 then action1", "if condition2 then action2", and so forth. When multiple conditions are met simultaneously, multiple corresponding actions are executed. However, you can emulate "if-elseif-else" logic by using the Stop evaluating remaining rules feature to create conditional branching that resembles: If condition1 is satisfied, execute action1 and stop Else if condition2 is satisfied (but condition1 is not), execute action2 and stop Else if condition3 is satisfied (but condition1 and condition2 are not), execute action3 and stop Else, execute a default action How it works: When multiple conditions would normally be satisfied simultaneously, only the first matching rule executes because rule evaluation stops after the first match. This effectively simulates traditional conditional branching. Configuration steps: Create a new ruleset (for example, "IfElseifElseRuleset") Create rules in priority order, with the most specific conditions first For each rule, check the Stop evaluating remaining rules option Important This if-elseif-else paradigm only works if the ruleset is attached as the final ruleset for that route. Scenario 11: Removing query strings from incoming URLs using URL redirects You can remove query strings from incoming URLs by implementing a 3xx URL redirect that guides users back to the Azure Front Door endpoint with the query strings removed. The following example demonstrates how to remove the entire query string from incoming URLs. If you need to strip part of it, you can adjust the offset/length as desired. For more information, see Server variable format. Note Users will notice the change of the request URL with this operation. Scenario 12: Append SAS token in query string to authenticate Azure Front Door to Azure Storage You can protect files in your storage account by changing the access to your storage containers from public to private and using Shared Access Signatures (SAS) to grant restricted access rights to your Azure Storage resources from Azure Front Door without exposing your account key. You can also accomplish this using Managed Identity. For more information, see Use managed identities to authenticate to origins. How SAS token injection works: Capture the incoming URL path and append the SAS token to the query string using redirect or rewrite rules. Since URL rewrite only acts on the path, use redirect rules when you need to modify query strings. For example, if you want to append a SAS token to the incoming URL: https://www.contoso.com/dccp/grammars/0.1.0-59/en-US/grammars/IVR/ssn0100_CollectTIN_QA_dtmf.grxml?version=1.0_1719342835399, the rewrite URL will be: https://www.contoso.com/grammars/0.1.0-59/en-US/grammars/IVR/ssn0100_CollectTIN_QA_dtmf.grxml?version=1.0_1719342835399&<SASTOKEN> In this example, the incoming URL already has query parameters, and you want to preserve the existing query string while appending the SAS token by configuring URL redirect using /{url_path:seg1:20}?{query_string}&<SASToken>. The rule configuration redirects all HTTPS requests that don't already contain the SAS token (identified by the absence of sp=rl in the query string). Important Update your route configuration to ensure routes for /grammars/* are properly configured after the redirect Replace the SAS token with the proper token. In the example, the SAS token starts with sp=rl, and you want to redirect all requests to apply this rule which doesn’t contain the sp=rl Scenario 13: Add security headers with rules engine You can use the Azure Front Door rules engine to add security headers that help prevent browser-based vulnerabilities, such as HTTP Strict-Transport-Security (HSTS), X-XSS-Protection, Content-Security-Policy, and X-Frame-Options. See details in Tutorial: Add security headers with Rules Engine - Azure Front Door | Microsoft Learn. Conclusion In this blog, we explored common scenarios where you can leverage the AFD rules engine to streamline and customize your workflows. We're enhancing the engine to be more flexible and scalable—supporting advanced routing, origin selection, and edge-side processing. More updates are on the way, so stay tuned. In the meantime, we’d love your input: what scenarios are you trying to unblock? Whether you're optimizing for performance, reliability, or custom workflows, drop your thoughts in the comments—we're listening and excited to see what you’ll build.
Get ClientIp in backend service (behind FrontDoor and APIM)
Context: Azure Front Door connects to APIM (external mode) that forwards the requests to services inside AKS. Services are monitored with Application Insights. The target is to be able to retrieve client IP in our backend service thanks to an Header. Situation: We have tested multiple ways to do so: - via the header X-Forwarded-For - via the header X-Azure-ClientIP - via a policy in APIM with the following field: "<value>@(context.Request.IpAddress)</value>" None of these methods works to retrieve the clientIP, we get Microsoft datacenters IPs instead. Do you have an idea to be able to get this clientIP in backend service? Thank you for any tips!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?Revolutionizing hyperscale application delivery and security: The New Azure Front Door edge platform
In this introductory blog to the new Azure Front Door next generation platform, we will go over the motivations, design choices and learnings from this undertaking which helped us successfully achieve massive gains in scalability, security and resiliency.Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft (classic)
Azure Front Door and Azure CDN Standard from Microsoft (classic) are postponing the domain fronting blocking enforcement to January 22, 2024, and will add two log fields to help you check if your resources display domain fronting behavior by December 25, 2023.Confuse in Azure WAF behavior with different browsers
Hello, I have an Azure Application gateway (WAF) that prevention mode is enabled and the OWASP 3 and the Microsoft Bot rule are activate. I checked my web application with chrome and refresh and sent many requests with Chrome. Now I received 403 Forbidden. I checked the logs the reason is: requestUri_s: /auth/login requestUri_s: /favicon.ico Message: SQL Comment Sequence Detected. But when I open my web application with Edge, it's work well. (Same system and same IP) 1. What's the reason? 2. How to fix? If I disable this role, there are risks. If I trust my IP, I couldn't check and QA my web app.
