Why does an NSG rule for a CIDR range not work, but a specific IP rule does?

[thin galleon]

Hi everyone,

I'm running into a puzzling issue with Azure Network Security Groups (NSGs) and would love your input.

We have an RDP rule set up in our NSG. Initially, we allowed a CIDR range (e.g., 192.168.0.0/24) to permit access for customers, but for some reason, it didn’t work. When we switched to specifying the exact IP addresses (e.g., 192.168.0.1 and 192.168.0.2), the connection worked perfectly.

Could it be NAT translation issue where the translated address falls out of CIDR range?

Would love to hear your input!

[visual ibex]

That's a weird one.

I don't think it would be related to NAT as the CIDR range is more permissive and would always include the exact IP address from your example.

Your best bet would be to add VNET flow logs to try and see what's going on.

[thin galleon]

Thats a good idea. The client is using some kind of VPN to connect, so I wonder thats whats causing the issue 🤔

[true saffron]

Something else is the problem for sure

[elder trout]

VPN works in two modes, full-tunneling (all the user traffic goes through the vpn gw) and split-tunneling (only specific traffic based on fw policies goes through the vpn gw).

if that the case, the traffic related to m365 services is not going through that vpn..

[thin galleon]

i think our customer has split tunneling, could it be the reason @elder trout

[elder trout]

if that's the case i suggest changing the nsg rule to use the VPN GW IP as a whitelist and in the vpn policies allow access to that endpoint (VM's public ip)

[high lichen]

No input until you share the whole infrastructure and troubleshooting you had in regards to that specific VM/NSG 🙂

[thin galleon]

DeFi already helped 🙂