Azure to OnPrem Connectivity issue

[H.Thiam]

We have migrated our on-premises firewall from FortiGate to Palo Alto and are experiencing an issue with VPN traffic routing that previously worked as expected.

We have an Azure Point-to-Site (P2S) VPN and an Azure-to-Corporate Site-to-Site (S2S) VPN. A P2S client with IP address 10.40.1.2 is unable to access resources on the Corporate LAN (192.168.62.0/24, e.g. 192.168.62.2) via the S2S tunnel.

However, traffic from Azure virtual machines in subnet 10.20.0.0/24 (e.g. 10.20.0.4) can successfully access 192.168.62.0/24, confirming that the S2S tunnel itself is operational. This setup was working correctly prior to the migration when a FortiGate firewall was in place.

The IPsec proxy IDs on the Palo Alto firewall are configured as follows:

• Local: 192.168.62.0/24, Remote: 10.40.1.0/24

• Local: 192.168.62.0/24, Remote: 10.20.0.0/24

Appropriate security policies and static routes are configured on the firewall. The P2S client routing table also contains a route for 192.168.62.0/24, and traffic is sent into the VPN tunnel from the client. Despite this, no traffic sourced from 10.40.1.0/24 is observed in the Palo Alto traffic or threat logs, while traffic from 10.20.0.0/24 is logged and permitted.

Given that Azure VM traffic can reach the Corporate LAN but P2S client traffic cannot, we are trying to determine whether there is a configuration requirement or limitation on the Palo Alto side (e.g. IPsec, routing, or proxy-ID handling) that could prevent P2S-sourced traffic from being processed or logged. The NGFW is managed through Strata Cloud Manager .

Any guidance on additional configuration or validation steps on the Palo Alto firewall would be appreciated.

Thanks

[JayGolf]

Hi @H.Thiam ,

Thanks for sharing all of that.

I’m not aware of any Palo Alto Networks–specific limitation that would prevent P2S-sourced traffic from transiting an Azure-to-on-prem S2S VPN if that traffic actually reaches the firewall. Based on what you’ve shared, the proxy IDs look correct, and static routing on the Palo Alto side is likely in place given that traffic from Azure VMs (10.20.0.0/24) to on-prem is working as expected.

What I would do next is validate whether your PA is actually receiving P2S-sourced traffic and double check that your return route for the P2S 10.40.1.0/24 exists in the same VR as the tunnel interface, pointing back to that tunnel int. 

If decap counters do not increment then that would strongly indicate the traffic from P2S is not being forwarded correctly from the Azure into the S2S. Since the S2S tunnel itself is confirmed working (Azure VM traffic reaches on-prem), this makes me more suspicious of the Azure P2S-to-S2S forwarding or routing config rather than a limitation on the PA end.

Please let us know if you find out anything else!