Introduction

If you’ve ever tried to configure Azure Firewall or third-party Network Virtual Appliance (NVA) like Palo Alto VM-Series in an Azure Virtual WAN (vWAN) topology, you’ll know the documentation can be confusing, contradictory, and spread across dozens of pages and videos with snips of information. After weeks of hands-on lab testing and production deployments, I’ve compiled this guide to give you the definitive answer to one question:

What routing and security combinations actually work in Azure vWAN — and which ones don’t?

This post covers six common design scenarios, explains exactly why each one does or doesn’t work, and finishes with a master comparison table so you can make an informed architectural decision.

Key Concepts You Need to Understand First

Before diving into the scenarios, let’s establish some fundamentals.

What Is Routing Intent?

Routing Intent is a declarative feature in Azure vWAN that allows you to configure Internet Traffic and Private Traffic routing policies on a virtual hub. When enabled, it automatically:

• Takes over management of the defaultRouteTable and all connection associations/propagations
• Injects RFC1918 aggregate routes (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) for private traffic
• Injects a 0.0.0.0/0 default route for internet traffic
• Forces all connections to associate with and propagate to the defaultRouteTable

You lose the ability to use custom route tables or manually control association/propagation. The platform manages everything.

What Is a Secured Virtual Hub?

A secured virtual hub is a vWAN hub with a security solution deployed inside it. Valid security solutions are:

• Azure Firewall (deployed in the hub)
• Integrated NVA partner (e.g., Fortinet, Barracuda — deployed in the hub via Firewall Manager)
• Palo Alto Cloud NGFW (SaaS resource deployed in the hub)

A Palo Alto VM-Series deployed as IaaS in a spoke VNet is NOT a hub-integrated security solution and cannot be used as a Routing Intent next hop.

Direct Spokes vs Indirect Spokes

• Direct spoke: A VNet connected directly to the vHub via a hub virtual network connection
• Indirect spoke: A VNet peered to another spoke (typically an NVA transit VNet) that is connected to the vHub. The indirect spoke has no direct connection to the hub.

The Golden Rule of vWAN Static Routes

There are two mutually exclusive ways to steer traffic to Azure Firewall in a vHub:

1. Routing Intent (declarative, platform-managed)
2. Static routes in hub route tables (manual, operator-managed)

You cannot mix these two approaches. Enabling Routing Intent on a hub that has manually configured static routes will cause conflicts, and the platform will not reconcile them automatically.

Scenario 1: Full Routing Intent (Both Policies)

The Design

Azure Firewall deployed in a secured vHub with Routing Intent enabled for both Internet and Private traffic. All spokes connected directly to the hub. No third-party NVA.

          Spoke 4              Spoke 5
        (direct conn)        (direct conn)
              \                  /
               \                /
         ┌──────────────────────────┐
         │   Secured vHub           │
         │   Azure Firewall         │
         │   Routing Intent:        │
         │   Internet → AzFW        │
         │   Private  → AzFW        │
         └──────────────────────────┘
                    │
               ExpressRoute / VPN
                    │
                On-Premises

Traffic Flows

Source → Destination	Path	Inspected?
Spoke Spoke	Via Azure Firewall	Azure Firewall
Spoke Branch	Via Azure Firewall	Azure Firewall
Spoke → Internet	Via Azure Firewall	Azure Firewall
Branch → Internet	Via Azure Firewall	Azure Firewall
Inter-hub (if multi-hub)	Via Azure Firewall (both hubs)	Azure Firewall

Configuration

Routing Intent:

VNet Connections (managed by platform):

Prerequisites

• Only defaultRouteTable and noneRouteTable can exist — delete all custom route tables
• No static routes with next hop type = VNet connection
• Azure Firewall must be deployed in the hub (not in a spoke VNet)
• If non-RFC1918 private address space is used, add it as “Private Traffic Prefixes”

Critical Lesson Learnt

If the hub previously had static routes, custom next hops, or custom route tables before Routing Intent was enabled, simply deleting those routes while intent is active is not sufficient. The correct procedure is:

1. Fully remove Routing Intent
2. Delete all static routes, custom next hops, and custom route tables
3. Verify only defaultRouteTable and noneRouteTable remain
4. Re-enable Routing Intent

This forces the platform to rebuild the routing state from scratch.

Verdict: Fully Supported

Scenario 2: PA Cloud NGFW (Internet) + Azure Firewall (Private) with Routing Intent

The Design

Split the security duties using Routing Intent with two different in-hub security solutions: Palo Alto Cloud NGFW (a SaaS offering deployed inside the vHub) for internet traffic, and Azure Firewall for private/east-west traffic.

          Spoke 4              Spoke 5
        (direct conn)        (direct conn)
              \                  /
               \                /
         ┌──────────────────────────┐
         │   Secured vHub           │
         │                          │
         │   Azure Firewall         │
         │   (private traffic)      │
         │                          │
         │   PA Cloud NGFW (SaaS)   │
         │   (internet traffic)     │
         │                          │
         │   Routing Intent:        │
         │   Internet → PA NGFW     │
         │   Private  → AzFW        │
         └──────────────────────────┘

Traffic Flows

Source → Destination	Path	Inspected by
Spoke Spoke	Via Azure Firewall	Azure Firewall
Spoke Branch	Via Azure Firewall	Azure Firewall
Spoke → Internet	Via PA Cloud NGFW	Palo Alto
Branch → Internet	Via PA Cloud NGFW	Palo Alto

Why This Works

PA Cloud NGFW is a SaaS resource deployed inside the vHub — it’s a first-class Routing Intent next hop, just like Azure Firewall. You can point each routing policy at a different in-hub resource.

Trade-offs

• Cleanest split architecture — fully declarative, single-hop
• Fully supported by Microsoft and Palo Alto
• PA Cloud NGFW integrates with Panorama / Strata Cloud Manager
• Requires PA Cloud NGFW licensing (consumption-based SaaS) — not existing VM-Series licensing
• Feature set differ from VM-Series

Verdict: Fully Supported

Scenario 3: Routing Intent with Private-Only Policy + PA VM-Series (Spoke) for Internet

The Design

Enable Routing Intent for only Private Traffic (pointing at Azure Firewall), then use a static route on the PA transit VNet connection to steer internet traffic (0.0.0.0/0) to the Palo Alto VM-Series in a spoke VNet.

          Spoke 4              Spoke 5       PA Transit VNet
        (direct conn)        (direct conn)   (direct conn +
              \                  /            static 0/0 → PA)
               \                /                 │
         ┌──────────────────────────┐             │
         │   Secured vHub           │─────────────┘
         │   Azure Firewall         │
         │   Routing Intent:        │
         │   Private  → AzFW        │
         │   Internet → ???         │
         └──────────────────────────┘

Why This DOESN’T Work

When Routing Intent is enabled — even with only the Private Traffic policy — the platform takes over management of the defaultRouteTable and all connection associations/propagations. You cannot layer a static route (0.0.0.0/0 → PA ILB) on a VNet connection on top of an active Routing Intent configuration.

The static route pattern documented by Microsoft for Routing Intent is specifically for reaching indirect spokes behind an NVA — not for routing internet traffic to an NVA in a spoke bypassing the hub security solution.

Routing Intent next hops must be a resource deployed in or integrated with the vHub:

Valid Next Hop	Type
Azure Firewall	Deployed in hub
Integrated NVA partner	Deployed in hub
PA Cloud NGFW	SaaS in hub
PA VM-Series in a spoke VNet	Not valid

Verdict: Not Supported — Tested and Confirmed

Scenario 4: Service Chaining Azure Firewall (Hub) → PA VM-Series (Spoke) for Internet

The Design

Use Routing Intent for both policies pointing at Azure Firewall, then have Azure Firewall “forward” internet-bound traffic to the PA VM-Series in a spoke VNet for deep inspection before egress.

          Spoke 4
        (direct conn)
              │
              ▼
         Azure Firewall (hub)
              │
              ▼  ← "forward internet to PA"
         PA Transit VNet (spoke)
              │
              ▼
           Internet

Why This DOESN’T Work

There is no mechanism to get traffic from Azure Firewall inside the hub to an NVA in a spoke:

Azure Firewall in a vHub is a walled garden. There is no data-plane path from Azure Firewall to say “after inspection, send this to the PA ILB in a spoke VNet.”

Microsoft does document a “Forced Tunnel” mode, but the valid sources of a 0.0.0.0/0 for forced tunnel are limited to: on-premises (via BGP), an NVA deployed in the hub, or a SaaS solution in the hub — not an NVA in a spoke VNet.

Verdict: Not Supported — No Mechanism Exists

Scenario 5: Static Routes Only — PA VM-Series (Internet), east\west not supported

The Design

Manually configure static routes in the defaultRouteTable to steer 0.0.0.0/0 to the PA VM-Series transit VNet connection for internet access. RFC1918 traffic to PA VM-Series NOT supported

                    ┌──────────────────────────────┐
                    │  vHub (Secured - NO Routing   │
                    │  Intent enabled)              │
                    │  Azure Firewall deployed      │
                    │                               │
                    │  defaultRouteTable:           │
                    │  ┌──────────────────────────┐ │
                    │  │ 10.0.0.0/8    → NA       │ │
                    │  │ 172.16.0.0/12 → NA       │ │
                    │  │ 192.168.0.0/16→ NA       │ │
                    │  │ 0.0.0.0/0     → PA conn  │ │
                    │  └──────────────────────────┘ │
                    └──┬────────┬────────┬──────────┘
                       │        │        │
                  Spoke 4   Spoke 5   PA Transit VNet

Traffic Flows

Source → Destination	Path	Inspected by
Spoke Spoke	Via Azure Firewall	Palo Alto
Spoke Branch	Via Azure Firewall	Palo Alto
Spoke → Internet	Via PA transit VNet → PA	Palo Alto
Branch → Internet	Via PA transit VNet → PA	Palo Alto
Inter-hub	Not inspected	Direct via vWAN backbone
Branch Branch	Not inspected	Direct via vHub

Configuration

defaultRouteTable Static Routes:

Spoke VNet Connections (Spoke 4, Spoke 5, etc.):

Critical: Spokes must propagate to noneRouteTable, not defaultRouteTable. If spokes propagated their specific prefixes (e.g., 10.20.20.0/24), these would be more specific than the RFC1918 aggregates (10.0.0.0/8) and traffic would bypass Azure Firewall via longest-prefix match.

PA Transit VNet Connection:

Setting	Value
Associated route table	defaultRouteTable
Propagated route tables	noneRouteTable
Static route	0.0.0.0/0 → PA ILB VIP
enableInternetSecurity	false

Critical: If enableInternetSecurity is true on the PA connection, the 0.0.0.0/0 route gets advertised back to the PA VNet, creating a routing loop. The PA must use its own external interface for internet egress.

Limitations

• Inter-hub traffic is not inspected — traffic between hubs bypasses Palo Alto (inter-hub inspection requires Routing Intent)
• Branch-to-branch traffic is not inspected — ExpressRoute VPN bypasses not inspected
• Cannot enable Routing Intent — the two approaches are mutually exclusive
• Manual route management — static routes must be maintained across all hubs

Verdict: Fully Supported for Internet Access only

Scenario 6: Transit NVA vNet – PA VM-Series for Everything — Indirect Spoke Pattern (No Azure Firewall)

The Design

No Azure Firewall, no Routing Intent. Standard vHub with all spokes peered to a regional PA transit VNet. The PA handles all inspection — internet and east-west. UDRs on every spoke subnet point 0.0.0.0/0 at the PA internal load balancer VIP.

     Spoke 4              Spoke 5
   (VNet peer)          (VNet peer)
        \                  /
         \                /
      PA Transit VNet (NVA)
      (PA VM-Series Active/Active
       behind Standard ILB)
              │
         Hub VNet Connection
         (static routes for spoke
          prefixes → PA ILB VIP)
              │
         ┌──────────────────────┐
         │  vHub (Standard)     │
         │  No Azure Firewall   │
         │  No Routing Intent   │
         └──────────────────────┘
                  │
             ExpressRoute / VPN
                  │
              On-Premises

Traffic Flows

Source → Destination	Path	Inspected by
Spoke Spoke	Via PA (UDR → PA ILB)	Palo Alto
Spoke Branch	Via PA → vHub → Branch	Palo Alto
Spoke → Internet	Via PA (SNAT) → Internet	Palo Alto
Branch → Spoke	Via vHub → PA transit → PA → Spoke	Palo Alto
Inter-hub (remote spokes)	Via vHub → remote hub → PA → Spoke	Palo Alto (at source)

Configuration

Spoke Subnets — UDR:

UDRs must be applied to every subnet in every spoke VNet.

PA Transit VNet Connection to vHub:

defaultRouteTable:

Advantages

• Single inspection point — PA handles everything
• Uses existing PA VM-Series licensing and Panorama
• No Azure Firewall cost
• Full PA feature set (App-ID, Threat Prevention, URL Filtering, SSL Decryption, WildFire)
• Proven pattern for enterprises with existing Palo Alto investment

Limitations

• More complex operational management (UDRs on every subnet, static routes per spoke)
• No Routing Intent simplicity
• Spoke onboarding requires UDR creation and VNet peering
• PA becomes a single point of inspection (capacity planning critical)

Verdict: Fully Supported — Production Proven

Master Comparison Table

	Scenario 1	Scenario 2	Scenario 3	Scenario 4	Scenario 5	Scenario 6
Name	Full Routing Intent	Cloud NGFW + AzFW Routing Intent	Private Intent + PA Spoke	Service Chain AzFW → PA	Static Routes	Transit NVA Network
Supported?	Yes	Yes	No	No	Yes	Yes
Routing Intent	Both policies	Both policies	Partial	Both policies	None	None
Internet inspection	Azure Firewall	PA Cloud NGFW	—	—	Palo Alto VM-Series	Palo Alto VM-Series
East-west inspection	Azure Firewall	Azure Firewall	—	—	No, Direct vHub	Palo Alto VM-Series
Inter-hub inspection	Yes	Yes	—	—	No	Via PA at source
Branch-to-branch inspection	Yes	Yes	—	—	No	Via PA
Uses PA VM-Series IaaS			—	—
Uses PA Cloud NGFW			—	—
Uses Azure Firewall			—	—	yes, instead of Palo Alto
Custom route tables	Not allowed	Not allowed	—	—	Supported	Supported
UDRs on spoke subnets	Not required	Not required	—	—	Not required	Required (every subnet)
Operational complexity	Low	Low	—	—	Medium	Medium-High
Routing management	Platform-managed	Platform-managed	—	—	Manual static routes or BGP	Manual UDRs + static routes or BGP
Spoke onboarding effort	Low (connect to hub)	Low (connect to hub)	—	—	Low (connect to hub)	High (peer + UDR per subnet)
Azure Firewall cost	Yes	Yes	—	—	None	None
PA licensing model	N/A	Cloud NGFW SaaS	—	—	VM-Series IaaS	VM-Series IaaS

Decision Flowchart

Do you need a third-party NVA (e.g., Palo Alto) for ANY traffic?
│
├─ NO → Scenario 1 (Azure Firewall + Full Routing Intent)
│
└─ YES → Is it PA Cloud NGFW (SaaS) or PA VM-Series (IaaS)?
         │
         ├─ Cloud NGFW → Scenario 2 (Cloud NGFW Internet + AzFW Private)
         │
         └─ VM-Series IaaS → Do you need Azure Firewall for east-west?
                              │
                              ├─ YES → Scenario 5 (Static Routes Split)
                              │        ⚠ No inter-hub or branch-to-branch inspection, traffic is direct via vWAN\vHubs
                              │
                              └─ NO → Scenario 6 (Transit NVA vNet)
                                       ✅ Full inspection coverage

Conclusion

The Azure vWAN routing landscape is powerful but opinionated. The platform gives you clean, declarative routing through Routing Intent — but only if your security solutions are deployed inside the hub. The moment you introduce an IaaS NVA in a spoke VNet, you’re working outside the Routing Intent model and must use manual static routes and UDRs.

The two approaches — Routing Intent and static routes — are mutually exclusive. Understanding this single constraint will save you hours of troubleshooting.

Key takeaways:

1. Routing Intent next hops must be in-hub resources — Azure Firewall, integrated NVA, or Cloud NGFW SaaS
2. PA VM-Series IaaS in a spoke is NOT a valid Routing Intent next hop — no matter how you configure it
3. You cannot service-chain from Azure Firewall in a hub to an NVA in a spoke — there’s no mechanism
4. You CAN split Azure Firewall (east-west) and PA VM-Series (internet) using static routes — but you must NOT enable Routing Intent
5. If the hub had pre-existing static routes before Routing Intent was enabled, you must fully remove intent, clean up all routes, and re-enable — the platform doesn’t auto-reconcile

Choose the scenario that matches your security requirements, licensing investment, and operational maturity. There’s no single “right” answer — but there are several combinations that simply don’t work, and now you know which ones they are.

Tested and validated in lab and production environments, May 2026. Based on Microsoft Learn documentation and hands-on deployment experience.

That’s the full blog post ready to copy. Want me to also generate a featured image / header graphic for it, or export it as a Word document?

The post Azure Virtual WAN: What’s Actually Supported — A Practical Guide to Routing Intent, Azure Firewall, and NVA Integration appeared first on TSLS - Luke Smith.

Hopefully this article helps to resolve that mystery, or gives you something more to think about as the answer will depend on your situation.

First of all lets look at the recovery options already available. The table below highlights the key backup and recovery features.

Note: If the user (with the correct level of permissions) enters the recycle bin and selects permanently delete item then the asset/item will be removed and can’t be recovered

What have we learnt. Backups are retained for 28-days after a project or organisation is deleted. Asset recovery is available by using the recycle-bin and is kept for 30-days or your source code can be reverted or rolled back. Therefore your business will need to answer the following questions.

1. Is it important to be able to restore accidently deleted DevOps Projects and Organisations beyond the 28-day window
2. Do you need to be able to restore Pipelines and Board Assets/Items beyond the 30-day recycle Bin
3. Do you need the ability to granularly restore Test Plans?
   1. Note: Although these will be in a deleted Organisation and Project Backup – Granular asset restores are not part of the built in service. so, once a test is deleted it can’t be recovered
4. For Repos are you looking for a recycle bin restore? rather than using the built in Git capabilities

If you answer yes to any of the questions from points 1-4 then you will need a third-party backup solution from the likes of Keepit (https://www.keepit.com) or Backrightup (https://backrightup.com).

The post Azure DevOps Backup and Recovery appeared first on TSLS - Luke Smith.

Introduction

Virtual Private Network (VPN) is a technology that creates a secure and encrypted connection over a public network, such as the Internet, to access corporate resources and services. VPN is widely used by remote workers and mobile users who need to connect to their organisation’s network and applications. However, VPN also has some limitations and challenges, such as performance degradation, bandwidth consumption, complexity, and security risks.

Secure Access Service Edge (SASE) is a new concept that combines network and security functions into a unified cloud-based service. SASE aims to provide secure and fast access to any application, anywhere, and on any device. SASE solutions, such as zScaler and Entra global secure gateway, leverage modern security approaches, such as zero trust network access (ZTNA), cloud access security broker (CASB), and software-defined perimeter (SDP), to protect the data and identity of the users and devices.

The purpose of the next sections is to assess broadly how a VPN and SASE can access corporate resources and services (Cloud and non-cloud based). It will contrast the five main VPN options and their advantages and disadvantages from a network speed, reliability, high availability and security point of view. It will also suggest a VPN option or a No VPN option that uses modern security methods and functions.

VPN Options

There are five main VPN options that can be used to access corporate resources and services. They are:

• VPN Forced Tunnel: 100% of traffic goes into VPN appliance, including on-premise, Internet, and all SaaS/M365
• VPN Forced Tunnel with few exceptions: VPN tunnel is used by default (default route points to VPN), with few, most important exempt scenarios that are allowed to go direct
• VPN Forced Tunnel with broad exceptions: VPN tunnel is used by default (default route points to VPN), with broad exceptions that are allowed to go direct (such as all Microsoft 365, All Salesforce, All Zoom)
• VPN Selective Tunnel: VPN tunnel is used only for corpnet-based services (typically on-premise). Default route (Internet and all Internet-based services) goes direct.
• No VPN: A variation of #2. Instead of legacy VPN, all corpnet services are published through modern security approaches (like Zscaler and Microsoft Entra Global Secure Access)

Pros and Cons of VPN Options

The following table summarizes the pros and cons of each VPN option from a network speed, reliability, high availability and security perspective.

Recommendation

Based on the comparison of the VPN options, the recommendation is to use either the VPN Selective Tunnel option or the No VPN option, depending on the availability and feasibility of the SASE solutions and integration. Both options offer the best network speed, reliability, high availability and security for accessing corporate resources and services.

The VPN Selective Tunnel option is suitable for organisations that have a mix of corpnet-based and Internet-based services, and that want to reduce the VPN bandwidth consumption and cost, and improve the user experience and productivity, while maintaining the network and security policies for the corpnet-based services. However, this option also requires complex and inconsistent configuration, and lacks network and security policies for the Internet-based services (such as Microsoft 365).

The No VPN option is suitable for organisations that have mostly Internet-based services, and that want to eliminate the VPN bandwidth consumption and cost, and optimize the user experience and productivity, while applying modern and consistent security policies for all services. This option also provides full visibility and control of all services, and leverages the features of the SASE solutions, such as zScaler, Entra Global Secure Access (GSA), FortiGate FortiSASE . However, this option also requires SASE solutions and integration, identity and device management, and cloud and network optimisation.

Some of the features of the SASE solutions that improve the security posture over a traditional VPN are:

• Tenant restriction option (Feature of Microsoft Entra): This feature allows the organisation to restrict the access to its cloud services only to the authorized devices and users, and prevent the access from any unauthorized or compromised devices or users.
• Conditional Access (Feature of Microsoft Entra): This feature allows the organisation to enforce granular and dynamic policies based on the context of the user, device, location, application, and data, and grant or deny the access accordingly.
• Continuous Access Evaluation (Feature of Microsoft Entra): This feature allows the organisation to monitor and evaluate the security posture of the user and device continuously, and adjust the access level or revoke the access if any changes or anomalies are detected.
• Support for multi-platform: This feature allows the organisation to support and secure the access from any device and platform, such as Windows, Android, Mac, Linux, iOS, etc.

Useful reference materials:

1. What is Global Secure Access? – Global Secure Access | Microsoft Learn
2. Learn about the Global Secure Access clients for Microsoft Entra Private Access and Microsoft Entra Internet Access – Global Secure Access | Microsoft Learn
3. Zscaler Internet Access | AI-Powered Security Service Edge
4. SASE Solution – Secure Access Service Edge | Fortinet
5. Pulse Secure: Secure Access Made Easy | Ivanti

Final Note: Microsoft Entra Global Secure Access is a fairly new service and some of its features are still in preview, which means as of writing that are not yet fully functional. However, the technology is built on services that are well-established and widely used, such as Application Proxy, Conditional Access and Continuous Access Evaluation. It might be a good idea to evaluate the use of both VPN selective Tunnelling and Entra GSA together. Entra GSA could be applied to Microsoft 365 traffic. Traffic for Microsoft would go directly from the local internet breakout and be secured by Entra GSA.

The post Evaluating VPN and SASE Options for Secure and Reliable Access appeared first on TSLS - Luke Smith.

Issue

You try to connect your Draytek 2860n but receive the below error in the logs:

Reason

Reason for the failure is because the device is unable to decrypt the key. This might be because cypher suites are not be supported. – Currently working with Draytek to understand how this can be resolved.

The post Entra Remote Network to Draytek 2860n Failure appeared first on TSLS - Luke Smith.

The scenario is focused on a FortiGate Firewall Appliance but other VPN Devices should work in a similar way.

NB: not all VPN device will work. IKEv2 Phase 2 is limited to support only GCMAES128, GCMAES192, GCMAES256 and not all device will support these cyphers.

Step	Screenshot
Navigate to https://entra.microsoft.com/   Expand Global Secure Access Expand Remote Network   Click “Create remote network”
Basic Information:   Name: <Endpoint Name> Region: <Local Region>   Click Next
Connectivity Information:   Select Add a Link
Add a Link – General Information   Link Name: <Name of the connected location> Device Type: <Your VPN Device Make> IP Address: <Your VPN Public IP> Local BGP Address: <Microsoft BGP IP Address which you generate and must not conflict with any existing networks> Peer BGP Address: <Your Route BGP Address> Link ASN: <Your Router BGP ASN Address> Redundancy: <Select as per your requirements> Bandwidth capacity: <Select you required capacity; 250mbps, 500mbps, 750mbps, 1000mbps>   Click Next
Add a Link – Details Information   Protocol: IKEv2 IPSEC/IKE Policy: <Default / Custom>   If custom then the following options will need to be completed:   IKE Phase 1: Encryption: <AES128, AES192, AES256, GCMAES128, GCMAES265> IKEv2 integrity: <SHA256,SHA384, GCMAES128, GCMAES265> DH Group: <DHGroup14,>   IKE Phase 2: IPSec Encryption: <GCMAES128, GCMAES192, GCMAES256, None> IPSec Integrity: <GCMAES128, GCMAES192, GCMAES256, SHA256> PFS Group: <None, PFS1, PFS2, PFS14, PFS2048, PFSMM, SCP256, ECP384> SA lifetime (seconds): <value from 300 – 86400>   Click Next   Note: SA IP Range must be configured as 0.0.0.0/0 – 0.0.0.0/0
Add a Link – Security   Pre-shared key (PSK): <enter a key to be used on Entra and on your VPN Device> Click Save
Connectivity Tab Information:   Click Next
Traffic Profile:   Select the traffic profile for this connection
Review + Create Information   Confirm the information is correct   Click Create remote network
From the main remote network Select view configuration
From the network configuration   Click Copy and Save

FortiGate Firewall Configuration

The following table details the steps to configure a FortiGate Firewall (in this instance a 60E)

Step	Screenshot
Navigate to your routers IP http://x.x.x.x Expand VPN Expand IPsec Tunnel Click Create New Tunnel
Within the Wizard Name: VPNtoEntra Template Type: Custom Click Next
On the Next Screen complete the following: IP Version: IPv4 IP Address: EntraID VPN Interface: WAN Port NAT: Disabled DPD: On Idle Method: PSK Pre-Shared Key: xxxxx IKE: 2
Phase 1 Proposal Encryption: AES256 Authentication: SHA256 DH: G14 Key Life: 86400 Phase 2 Proposal Local Address: 0.0.0.0/0.0.0.0 Remote Address: 0.0.0.0/0.0.0.0 Encryption: AES256GCM Enable PFS: uncheck Key Lifetime: 27000 (from above) Next Click OK
Configure BGP Navigate to Network Expand BGP (if missing add via system/feature visibility) Enter your Local AS: (ASN from above) Under Neighbors Click Create New
Add in the Azure BGP details: IP: (Azure BGP from above) Remote AS: (Azure ASN from above) Update source: name of your IPSEC tunnel Enable Enforce eBGP multihop Enable Activate IPv4 Check Soft reconfiguration Check Capability: route refresh Click OK
Navigate to Network Expand BGP (if missing add via system/feature visibility) Add in the local networks Click Apply
Confirm the BGP has established and is not idle
And confirm that the routes are visible
Next you will need to config the firewall policy to allow the internal traffic to Entra	TBC

Conclusion

Make sure the following are in place:

• SA is configured with the routes 0.0.0.0/0 – 0.0.0.0/0.
• Route is configured for the Entra BGP Peer within the subnet /32 i.e. 172.16.2.254/32 (172.16.2.254 being the Microsoft BGP endpoint).
• Within BGP make sure enforce eBGP multihop is enabled (if you see packets being RST/DROP from your router IP to the Azure BGP IP it’s likely because eBGP is not enabled.
• Routes to your local network is enabled in BGP

The post How to create a remote network into Entra Global Security Access appeared first on TSLS - Luke Smith.

1. LG Magic Remote ( OLED Screen)
2. Sky Q remote (basic controller)
3. Sonos Soundbar

Using the LG Magic Remote select the home button.

1. Select LG Device Connections
2. Select Soundbar
3. Select Optical
4. Select Pioneer
5. Select Option 1 and Save

From Sky Q

1. Select Settings
2. Select Setup
3. Select Remote Controls
4. Select Sky Remote
5. Configure the TV and Home Theatre with the following codes

TV = 0206 (LG) | Home Theatre = ?0041 (Pioneer)

From the Sonos App

1. Settings
2. System
3. Speaker Name
4. Remote Control Setup
5. Point the sky remote at the soundbar and press the volume button.

Both the Sky remote and LG remote should be able to control the TV, Volume and Sky.

The post Remote Controller LG Magic Remote, Sonos and Sky Q appeared first on TSLS - Luke Smith.

AzureDiagnostics | where ResourceType == “APPLICATIONGATEWAYS” and Category == “ApplicationGatewayFirewallLog”

The post Azure App Gateway Log Analytics appeared first on TSLS - Luke Smith.

To increase the php upload size please run through the following steps:

In the Azure Portal, select your App Service
Navigate to Configuration
Select Application Settings
Click New Application settings

Name = PHP_INI_SCAN_DIR
Value = D:\home\site\ini

Click Save

Then Under Development Tools select Advanced Toolees (KUDU) or navigate to https://.scm.azurewebsites.net

From the menu select Debug Console\CMD

Go to site directory and press the “+” button and create an “ini” directory.
In the ini directory, create an “extensions.ini” file.
Press the edit button next to the file.
Add the following to the file and save. This will modify the Master values.
upload_max_filesize=30M
post_max_size=30M
Go to the wwwroot directory and create a “.user.ini” file.
Edit the file and add the same values as mentioned in step 7 above. This will modify the Local values.
Restart the site using the Azure Portal.
PHPMyAdmin Import page will also reflect the changes.

The post Azure MySQL In App Manager – Increase Import Size appeared first on TSLS - Luke Smith.

When you create an Office 365 Data Loss Protection (DLP) Policy the Action to “Encrypt email messages (applies only to content in Exchange)” is missing.

RESOLUTION:

Exchange Online Azure AD Rights Management needs to be eneabled.

Download the Exchange Online PowerShell from: https://docs.microsoft.com/en-us/powershell/exchange/exchange-online/exchange-online-powershell?view=exchange-ps


Connect-ExchangeOnline
Connect-AadrmService
(Get-AadrmConfiguration).LicensingIntranetDistributionPointUrl -match “https:\/\/[0-9A-Za-z\.-]*” | Out-Null; $matches[0]

#Copy URL into $list below
$irmConfig = Get-IRMConfiguration
$list = $irmConfig.LicensingLocation
$list += “https://512889fd-d24f-4f29-87e1-7111b27ebada.rms.eu.aadrm.com/_wmcs/licensing“
Set-IRMConfiguration -LicensingLocation $list
Set-IRMConfiguration -internallicensingenabled $true
<\code>

The post Office 365 DLP Action Encrypt email messages Missing appeared first on TSLS - Luke Smith.

netsh advfirewall firewall add rule name=”ICMP Allow incoming V4 echo request” protocol=”icmpv4:8,any” dir=in action=allow

netsh firewall set service RemoteAdmin enable

netsh firewall add portopening protocol=tcp port=135 name=DCOM_TCP135

The post Lansweeper Windows Firewall Requriements appeared first on TSLS - Luke Smith.