What is the best way to handle networking during a long-running cloud migration?
Hi everyone, I'd like to get some opinions from people who have worked on large-scale cloud migrations. Consider a migration where workloads are gradually moved from AWS to Azure over several weeks or months rather than being migrated in a single cutover. During the migration period, both environments need to remain operational. A simplified architecture could look like: AWS workloads | | Existing connectivity | AWS Network | | Inter-cloud connectivity | Azure Network | | Azure workloads The challenge is that applications may temporarily become distributed across both clouds. For example: • Application servers may still be running in AWS. • New application components may already be deployed in Azure. • Databases or shared services may remain in AWS temporarily. • DNS and routing may need to support both environments. • Migration tools may require connectivity to source and target environments. • Some workloads may be migrated much earlier than their dependent services. For a long-running migration like this, what architecture would you recommend? Some options I have been considering are: 1. Site-to-site VPN between AWS and Azure 2. Dedicated connectivity such as AWS Direct Connect + Azure ExpressRoute 3. A combination of dedicated connectivity and VPN for backup 4. A hub-and-spoke architecture in Azure with controlled connectivity back to AWS 5. Application-level connectivity rather than relying heavily on network-level connectivity Another question is how you would handle routing. Would you prefer to: • Keep AWS and Azure routing domains mostly independent? • Use a centralized hub for cross-cloud traffic? • Advertise routes dynamically using BGP? • Restrict cross-cloud communication to only the application dependencies that require it? For a migration lasting several months, what approach have you found to be the most reliable and easiest to operate? I'm particularly interested in lessons learned around: • Routing • DNS • Security • Latency • Failover • Monitoring • Avoiding unexpected cross-cloud traffic costs Would appreciate experiences from anyone who has handled a production AWS-to-Azure or Azure-to-AWS migration.
AOVPN / Reasoncode 16
We have an always on vpn configuration. This worked fine till few months ago, users can't get connected anymore. After reboot of NPS server, all works fine for some time (random, sometimes 1 day, 2 days, 1 week), till the users can't get connected again. Reboot of nps server solves it. When users can't connect, I see an event on NPS server with reason code 16 Network Policy Server denied access to a user. Contact the Network Policy Server administrator for more information. User: Security ID: xxx Account Name:xxx Account Domain: xxx Fully Qualified Account Name: xx Client Machine: Security ID: NULL SID Account Name: - Fully Qualified Account Name: - Called Station Identifier: x.x.x.x Calling Station Identifier: x.x.x.x NAS: NAS IPv4 Address: x.x.x.x NAS IPv6 Address: - NAS Identifier: server-VPN01 NAS Port-Type: Virtual NAS Port: 14 RADIUS Client: Client Friendly Name: server-VPN01 Client IP Address: x.x.x.x Authentication Details: Connection Request Policy Name: Virtual Private Network (VPN) Connections Network Policy Name: Virtual Private Network (VPN) Connections Authentication Provider: Windows Authentication Server: server-NPS01 Authentication Type: PEAP EAP Type: Microsoft: Smart Card or other certificate (EAP-TLS) Account Session Identifier: 33373834 Logging Results: Accounting information was written to the local log file. Reason Code: 16 Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect. As said, reboot of nps solves issues temporary. Already installed new nps server but same issue. Any suggestions where to check ?There needs to be a policy to enable Edge Secure Network
As soon a single policy is set for Microsoft Edge, either through group policy or registry, the Edge Secure Network becomes unavailable. There needs to be a policy to enable it again. Using a registry key or local policy to control Edge doesn't mean it's controlled by an organization or personal Microsoft accounts are not used.OPNsense Firewall as Network Virtual Appliance (NVA) in Azure
This blog is available as a video on YouTube: youtube.com/watch?v=JtnIFiB7jkE Introduction to OPNsense In today’s cloud-driven world, securing your infrastructure is more critical than ever. One powerful solution is OPNsense. OPNsense is a powerful open-source firewall that can be used to secure your virtual networks. Originally forked from pfSense, which itself evolved from m0n0wall. OPNsense could run on Windows, MacOS, Linux including OpenBSD and FreeBSD. It provides a user-friendly web interface for configuration and management. What makes OPNsense Firewall stand out is its rich feature set: VPN Support for point-to-site and site-to-site connections using technologies like WireGuard and OpenVPN. DNS Management with options such as OpenDNS and Unbound DNS. Multi-network handling enabling you to manage different LANs seamlessly. Advanced security features including intrusion detection and forward proxy integration. Plugin ecosystem supporting official and community extensions for third-party integrations. In this guide, you’ll learn how to install and configure OPNsense Firewall on an Azure Virtual Machine, leveraging its capabilities to secure your cloud resources effectively. We'll have three demonstrations: Installing OPNsense on an Azure virtual machine Setting up point-to-site VPN using WireGuard Here is the architecture we want to achieve in this blog, except the Hb and Spoke configuration which is planned for the second part coming soon. 1. Installing OPNsense on an Azure Virtual Machine There are three ways to have OPNsense in a virtual machine. Create a VM from scratch and install OPNsense. Install using the pre-packaged ISO image created by Deciso the company that maintains OPNsense. Use a pre-built VM image from the Azure Marketplace. In this demo, we will use the first approach to have more control over the installation and configuration. We will create an Azure VM with FreeBSD OS and then install OPNsense using a shell script through the Custom Script Extension. All the required files are in this repository: github.com/HoussemDellai/azure-network-course/205_nva_opnsense. The shell script configureopnsense.sh will install OPNsense and apply a predefined configuration file config.xml to set up the firewall rules, VPN, and DNS settings. It will take 4 parameters: GitHub path where the script and config file are hosted, in our case it is /scripts/. OPNsense version to install, currently set to 25.7. Gateway IP address for the trusted subnet. Public IP address of the untrusted subnet. This shell script is executed after the VM creation using the Custom Script Extension in Terraform represented in the file vm_extension_install_opnsense.tf. OPNsense is intended to be used an NVA so it would be good to apply some of the good practices. One of these practices is to have two network interfaces: Trusted Interface: Connected to the internal network (spokes). Untrusted Interface: Connected to the internet (WAN). This setup allows OPNsense to effectively manage and secure traffic between the internal network and the internet. Second good practice is to start with a predefined configuration file config.xml that includes the basic settings for the firewall, VPN, and DNS. This approach saves time and ensures consistency across deployments. It is recommended to start with closed firewall rules and then open them as needed based on your security requirements. But for demo purposes, we will allow all traffic. Third good practice is to use multiple instances of OPNsense in a high-availability setup to ensure redundancy and failover capabilities. However, for simplicity, we will use a single instance in this demo. Let's take a look at the resources that will be created by Terraform using the AzureRM provider: Resource Group Virtual Network (VNET) named vnet-hub with two subnets: Trusted Subnet: Internal traffic between spokes. Untrusted Subnet: Exposes the firewall to the internet. Network Security Group (NSG): attached to the untrusted subnet, with rules allowing traffic to the VPN, OPNsense website and to the internet. Virtual Machine: with the following configuration: FreeBSD OS image using version 14.1. VM size: Standard_D4ads_v6 with NVMe disk for better performance. Admin credentials: feel free to change the username and password with more security. Two NICs (trusted and untrusted) with IP forwarding enabled to allow traffic to pass through the firewall. NAT Gateway: attached to the untrusted subnet for outbound internet connectivity. Apply Terraform configuration To deploy the resources, run the following commands in your terminal from within the 205_nva_opnsense directory: terraform init terraform apply -auto-approve Terraform provisions the infrastructure and outputs resource details. In the Azure portal you should see the newly created resources. Accessing the OPNsense dashboard To access the OPNsense dashboard: Get the VM’s public IP from the Azure portal or from Terraform output. Paste it into your browser. Accept the TLS warning (TLS is not configured yet). Log in with Username: root and Password: opnsense you can change it later in the dashboard. You now have access to the OPNsense dashboard where you can: Monitor traffic and reports. Configure firewall rules for LAN, WAN, and VPN. Set up VPNs (WireGuard, OpenVPN, IPsec). Configure DNS services (OpenDNS, UnboundDNS). Now that the OPNsense firewall is up and running, let's move to the next steps to explore some of its features like VPN. 2. Setting up Point-to-Site VPN using WireGuard We’ll demonstrate how to establish a WireGuard VPN connection to OPNsense firewall. The configuration file config.xml used during installation already includes the necessary settings for WireGuard VPN. For more details on how to set up WireGuard on OPNsense, refer to the official documentation. We will generate a Wireguard peer configuration using the OPNsense dashboard. Navigate to VPN > WireGuard > Peer generator then add a name for the peer, fill in the IP address for the OPNsense which is the public IP of the VM in Azure, use the same IP if you want to use the pre-configured UnboundDNS. Then copy the generated configuration and click on Store and generate next and Apply. Next we'll use that configuration to set up WireGuard on a Windows client. Here you can either use your current machine as a client or create a new Windows VM in Azure. We'll go with this second option for better isolation. We'll deploy the client VM using Terraform file vpn_client_vm_win11.tf. Make sur it is deployed using command terraform apply -auto-approve. Once the VM is ready, connect to it using RDP, download and install WireGuard. Alternatively, you can install WireGuard using the following Winget command: winget install -e --id WireGuard.WireGuard --accept-package-agreements --accept-source-agreements Launch WireGuard application, click on Add Tunnel > Add empty tunnel..., then paste the peer configuration generated from OPNsense and save it. Then click on Activate to start the VPN connection. We should see the data transfer starting. We'll verify the VPN connection by pinging the VM, checking the outbound traffic passes through the Nat Gateway's IPs and also checking the DNS resolution using UnboundDNS configured in OPNsense. ping 10.0.1.4 # this is the trusted IP of OPNsense in Azure # Pinging 10.0.1.4 with 32 bytes of data: # Reply from 10.0.1.4: bytes=32 time=48ms TTL=64 # ... curl ifconfig.me/ip # should display the public IP of the Nat Gateway in Azure # 74.241.132.239 nslookup microsoft.com # should resolve using UnboundDNS configured in OPNsense # Server: UnKnown # Address: 135.225.126.162 # Non-authoritative answer: # Name: microsoft.com # Addresses: 2603:1030:b:3::152 # 13.107.246.53 # 13.107.213.53 # ... The service endpoint ifconfig.me is used to get the public IP address of the client. You can use any other similar service. What's next ? Now that you have OPNsense firewall set up as an NVA in Azure and have successfully established a WireGuard VPN connection, we can explore additional features and configurations such as integrating OPNsense into a Hub and Spoke network topology. That will be covered in the next part of this blog. Special thanks to 'behind the scene' contributors I would like to thank my colleagues Stephan Dechoux thanks to whom I discovered OPNsense and Daniel Mauser who provided a good lab for setting up OPNsense in Azure available here https://github.com/dmauser/opnazure. Disclaimer The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
Azure VPN issues - RasMan service - Unknown state
Azure VPN Client stopped working after KB5065813 update – RasMan service Unknown state Environment details: Azure VPN Client version: 4.0.4.0 (Microsoft Store) Windows version: Windows 11 Pro, 23H2 (fully updated) Issue Summary: The Azure VPN Client worked fine from Friday (14 November 2025) until Sunday (16 November 2025). On Sunday, Windows installed updates, and starting Monday morning (17 November 2025), Azure VPN stopped working. When I run the Prerequisites Test in Azure VPN Client, everything passes except: Rasman Windows Service Status Result: Unknown state. Please make sure Rasman windows service is in a running state. However, sRasMan service it's running Registry keys for RasMan exist, and Svchost\netsvcs includes RasMan What changed: I noticed that the update KB5065813 seems to be causing the issue. This KB is installed on my machine, but my colleagues have KB5041655 instead. As part of troubleshooting, I even changed my laptop to a brand-new device with a fresh OS install, and the issue persists after KB5065813 is applied. What I’ve tried: Restarted RasAuto and dependencies Reinstalled Azure VPN Client Installed older versions of Azure VPN Changed my laptop with a brand new one and a fresh OS install Questions: Is KB5065813 confirmed to break Azure VPN Client functionality? Is this related to the October 2025 RasMan vulnerability patch (CVE-2025-59230)? Any official Microsoft steps or scripts to fix this? Screenshots attached for reference.
What's the Best VPN in 2025?
Hey, I am a newbie! I am looking for the best VPN providers and am interested to know what is the best VPN of 2025 according to Microsoft MVPs. I have tried lots of different free VPNs but they are not of so worth. So, I have decided to purchase a paid VPN. So, I am here to explore more about VPNs and get some reviews from you guys. I have made up a list of a few VPNs in which I am interested. But I am not sure which one would be the best VPN of 2025. Here's a few list of best VPNs that I have came across: 1. NordVPN: A VPN for which I have heard that there are lots of servers across the globe and offers fast speed for streaming. 2. ExpressVPN: Another remarkable VPN that is known for privacy protection to keep your data secure and have a pretty transparent setup. 3. PIA VPN: It is well known for its server network and offers multiple devices connection to keep your devices connected. 4. Surfshark: This VPN gets more attention and allows you to connect multiple devices and have a buzz that works well for users. 5. ProtonVPN: It is more known for its privacy and security. Thus, this VPN offers a free trial as well but the paid plan has more advanced features. I'd love to know your thoughts on the best VPN of 2025 as well.
Win 10 : VPN disconnecting then redeploying during Intune Sync
We have a IKEv2 user tunnel deployed using an Intune VPN Configuration profile. Every time Intune syncs, The VPN profile gets disconnected. If you obverse Network Connections in Control Panel while Intune Syncs, you can see that the VPN Profile gets removed then re-added in a span of a few seconds. Looking online at similar issues it seems that this used to be an issue on Windows 11 devices but was fixed some time ago. Our fleet is on Windows 10 and I couldn't find any examples of this issue on Win 10 online. is anyone else experiencing this issue? Any fix or workaround?Introducing Microsoft Edge Secure Network
Today, we're excited to share that we have kicked off experiments for Microsoft Edge Secure Network in the Canary channel of Microsoft Edge. We are opening this preview to a small audience to get initial feedback and recommendations so we can offer the best in-browser Secure Network experience. What does Secure Network do? With Edge Secure Network, you can connect to public Wi-Fi at coffee shops, airports, restaurants, hotels, & other venues, complete transactions, and shop online, all with the improved privacy and security that gives you the peace of mind you deserve. Secure Network helps you protect your information by masking your device's IP address, encrypting your data, and routing it through a secure network (powered by Cloudflare) to a server that is geographically co-located so it’s harder for malicious actors to see your true location and what you’re doing. It also prevents your internet service provider from collecting your browsing data, like details about which websites you visit, and helps prevent online entities from using your IP address for profiling and sending you targeted ads. As part of our first experiment, we’re giving everyone who tries this out a small amount of free Secure Network bandwidth to use however they see fit. For some activities like streaming videos, this allotment may be used significantly quicker than other activities like shopping and browsing the web. We encourage you to use the built-in controls to enable and disable the Secure Network and use this data however it best suits your needs and send us feedback about how Secure Network works for you. See our support page for more details. We will be diligently reviewing feedback as we over the coming weeks, so keep an eye out for Edge Secure Network and help us create the best experience possible! How it Works Whenever Secure Network is connected, your browsing traffic will be encrypted and routed through our service’s servers and then to its final destination. This helps ensure that your personal data will be more secure no matter what complicated route your browsing data takes or how many parties are involved in providing the content inside your favorite web page. Geo Location and Regions A lot of web technology relies on trying to intelligently provide results based on where you are located. We want to ensure that the web still works as you expect it to so when you search for a nearby restaurant or local movie showtimes, you can still get relevant results. We also want to help protect you as an individual, so you’re not personally associated with those results just by browsing the web. We’ve partnered with Cloudflare to help ensure that if VPNs are allowed in your region, wherever you connect to the Secure Network service, you will connect to a local data center and the IP address your browsing data flows through will be geographically similar to your actual region. However, websites will not see your individual network address, keeping your browsing disassociated from you while still allowing the internet to ‘just work’ as you expect. Microsoft Account and Data Collection During this preview phase Secure Network requires users to be signed into the browser with their Microsoft account. Sign-in is used solely to authenticate to the service and ensure you’re to receive more free data during the current period. No data about your user identity or account is sent over the Secure Network connection as part of this service. Additionally, limited diagnostic data may be ephemerally present on our partner’s servers for no more than 25 hours to help troubleshoot connection and performance issues, but is not persisted or directly associated with any given user. See our privacy promise and Cloudflare privacy notice for even more details. Send Us Feedback Be on the lookout for Secure Network as we expand our testing. We look forward to discovering how you would like to use Secure Network to protect your data, what works well, and what we can improve. Let us know on the shield icon flyout by giving us a quick thumbs up or down or use the in-browser feedback icon to send us more detailed feedback. Alt + Shift + I – Shortcut to send feedback As always, thanks for being a part of this journey towards a more private and secure web! Brandon Maslen, Principal Software Engineer Kelda Anderson, Product Manager
