Can not access all subnet devices using P2S

Question

Can not access all subnet devices using P2S

Hugh Dalgleish 1

I've got a simple setup with a few VMs on one subnet, 10.0.2.0/24 and a virtual network gateway using 10.0.3.0/24 for the address pool. Remote devices can connect, get an IP from the address pool, and have a route table entry for 10.0.2.0/24. Devices up to 10.0.2.8 can be connected to or pinged, but devices 10.0.2.9 and up can not be connected to or pinged over the VPN.
They can be connected to from the VM on 10.0.2.4
Why is only some of the subnet accessible?

SaiKishor-MSFT 17,336 Reputation points

2020-12-17T06:36:24.8+00:00
@Hugh Dalgleish

I understand your concern and the issue seems to be very weird that you can connect to part of the subnet and not the other part.

From your write up, I assume that you are using a P2S VPN which is getting its address from the 10.0.3.0/24 pool, right? Can you answer the following questions so I can assist you better-

What is the VNET Address space? Please confirm that the 10.0.3.0/24 does not conflict with Azure vnet or on-premises networks.

Do a traceroute to 10.0.2.4 and 10.0.2.9 IPs from 10.0.3.0/24 subnet and provide the result.

Perform a packet capture using wireshark or tcpdump on the 10.0.2.4 and 10.0.2.9 VMs and provide the result (specifically filter for ICMP traffic)

Please confirm the NSGs at the VMs or the VM subnet or VNET GW do not have rules to block traffic from the 10.0.2.9 and above IPs outbound.

Please also provide the routing table on the clients pc by doing a route print

Thank you!
Hugh Dalgleish 1 Reputation point

2020-12-17T11:58:31.8+00:00

OK, will do that, might take me a while!

Thanks

Hugh
Hugh Dalgleish 1 Reputation point

2020-12-22T10:03:19.75+00:00

It seems that all devices on the subnet are accessible using RDP and I did read a comment that ICMP is disabled in Azure - is that correct?
Andreas Baumgarten 123.4K Reputation points MVP Volunteer Moderator

2020-12-22T10:20:57.24+00:00

ICMP is not disabled in Azure generally. But for instance the firewall of Windows VMs is blocking ICMP by default.

Traceroute/tracert doesn't work in Azure that well. My recommendation is to use the Azure Network Monitor and Next hop:
https://learn.microsoft.com/en-us/azure/network-watcher/network-watcher-next-hop-overview

----------

(If the reply was helpful please don't forget to upvote and/or accept as answer, thank you)

Regards
Andreas Baumgarten
SaiKishor-MSFT 17,336 Reputation points

2020-12-30T20:03:08.647+00:00

@Hugh Dalgleish Were you able to resolve your issue? Please provide me the requested details if you still have any issues. Thank you!

4 answers

Your answer

SaiKishor-MSFT 17,336 Reputation points

2020-12-17T06:36:24.8+00:00

@Hugh Dalgleish

I understand your concern and the issue seems to be very weird that you can connect to part of the subnet and not the other part.

From your write up, I assume that you are using a P2S VPN which is getting its address from the 10.0.3.0/24 pool, right? Can you answer the following questions so I can assist you better-

What is the VNET Address space? Please confirm that the 10.0.3.0/24 does not conflict with Azure vnet or on-premises networks.

Do a traceroute to 10.0.2.4 and 10.0.2.9 IPs from 10.0.3.0/24 subnet and provide the result.

Perform a packet capture using wireshark or tcpdump on the 10.0.2.4 and 10.0.2.9 VMs and provide the result (specifically filter for ICMP traffic)

Please confirm the NSGs at the VMs or the VM subnet or VNET GW do not have rules to block traffic from the 10.0.2.9 and above IPs outbound.

Please also provide the routing table on the clients pc by doing a route print

Thank you!
Hugh Dalgleish 1 Reputation point

2020-12-17T11:58:31.8+00:00

OK, will do that, might take me a while!

Thanks

Hugh
Hugh Dalgleish 1 Reputation point

2020-12-22T10:03:19.75+00:00

It seems that all devices on the subnet are accessible using RDP and I did read a comment that ICMP is disabled in Azure - is that correct?
Andreas Baumgarten 123.4K Reputation points MVP Volunteer Moderator

2020-12-22T10:20:57.24+00:00

ICMP is not disabled in Azure generally. But for instance the firewall of Windows VMs is blocking ICMP by default.

Traceroute/tracert doesn't work in Azure that well. My recommendation is to use the Azure Network Monitor and Next hop:
https://learn.microsoft.com/en-us/azure/network-watcher/network-watcher-next-hop-overview

----------

(If the reply was helpful please don't forget to upvote and/or accept as answer, thank you)

Regards
Andreas Baumgarten
SaiKishor-MSFT 17,336 Reputation points

2020-12-30T20:03:08.647+00:00

@Hugh Dalgleish Were you able to resolve your issue? Please provide me the requested details if you still have any issues. Thank you!

Answer 1

No, and I will be looking into this issue in more detail, because I've found that I can not access shares on some devices over the subnet either.

VNet subnet is 10.0.2.0/24, Gateway subnet 10.0.3.0/24

tracert 10.0.2.4

Tracing route to 10.0.2.4 over a maximum of 30 hops

1 64 ms 91 ms 66 ms 10.0.3.0
2 46 ms 45 ms 44 ms 10.0.2.4

Trace complete.

tracert 10.0.2.9

Tracing route to 10.0.2.9 over a maximum of 30 hops

1 33 ms 44 ms 39 ms 10.0.3.0
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * ^C

route print

Interface List
14...2c 27 d7 14 db 0e ......Intel(R) 82574L Gigabit Network Connection
31...........................PANtest-vnet

1...........................Software Loopback Interface 1

IPv4 Route Table

Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.254.5 192.168.254.41 25
10.0.2.0 255.255.255.0 On-link 10.0.3.5 43
10.0.2.255 255.255.255.255 On-link 10.0.3.5 281
10.0.3.0 255.255.255.0 On-link 10.0.3.5 43
10.0.3.5 255.255.255.255 On-link 10.0.3.5 281
10.0.3.255 255.255.255.255 On-link 10.0.3.5 281
10.0.4.0 255.255.255.0 On-link 10.0.3.5 43
10.0.4.255 255.255.255.255 On-link 10.0.3.5 281
51.132.254.33 255.255.255.255 192.168.254.5 192.168.254.41 26
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
192.168.254.0 255.255.255.0 On-link 192.168.254.41 281
192.168.254.41 255.255.255.255 On-link 192.168.254.41 281
192.168.254.255 255.255.255.255 On-link 192.168.254.41 281
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.254.41 281
224.0.0.0 240.0.0.0 On-link 10.0.3.5 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.254.41 281

255.255.255.255 255.255.255.255 On-link 10.0.3.5 281

Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 0.0.0.0 192.168.254.5 Default

0.0.0.0 0.0.0.0 192.168.254.5 Default

IPv6 Route Table

Active Routes:
If Metric Network Destination Gateway
1 331 ::1/128 On-link
14 281 fe80::/64 On-link
14 281 fe80::7c8b:3ac7:1a6c:46fc/128
On-link
1 331 ff00::/8 On-link

14 281 ff00::/8 On-link

Persistent Routes:
None

There are no rules in place that would block the traffic.

I can access any of the 20 machines using RDP on 3389, but a few 9,11,14,15,,16,17,16,19,21,22,24 respond on RDP but not ICMP, although within the range, 8,10,13,29,23 respond on both RDP and ICMP. That's weird.

Will setup Wireshark on a test machine later.

SaiKishor-MSFT 17,336 Reputation points

2021-01-07T23:32:30.74+00:00

Routing seems fine to me. Could you check to make sure that the NSGs are not blocking this traffic, inbound or outbound? Yes please let me know what you see on wireshark.
Hugh Dalgleish 1 Reputation point

2021-01-08T21:46:17.257+00:00

The NSGs are not blocking the traffic. It looks like the Vnet client isn't compatible with Wireshark, so no trace from that. I'm going to look at Azure network monitor
I did see an email about a comment on my answer from you but it seems to be addressed to someone with a similar name, so I can't see it?

Answer 2

Hugh Dalgleish 1

Something else I've noticed, the VMs with the addresses that fail ICMP seem to lose connection occasionally, and appear to be slower than the other VMs.

Answer 3

SaiKishor-MSFT 17,336

We are working with the customer offline regarding this issue and will update this thread with the solution once we are able to troubleshoot the issue. Thank you!

Answer 4

shugie abcdefg 1

Thanks to help from Microsoft the problem has been identified. It was the Windows firewall, normally when adding a Windows 10 machine to a domain, the firewall rules get updated to allow traffic from within the domain, but it seems that this had not happened. Manually changing the firewall rules to allow domain ICMP, and then enabling network sharing on each VM seemed to resolve the issue. I was using the same base image for the VMs, but it was not domain joined.

There was a related issue with the VMs being B series, and when first started after being off for a while, ran so slowly that the firewall appeared to be lagging a bit. Another lesson learnt.

SaiKishor-MSFT 17,336 Reputation points

2021-01-27T11:38:54.7+00:00

Thanks for updating! Glad the issue has been resolved.

Share via

Can not access all subnet devices using P2S

4 answers

route print

1...........................Software Loopback Interface 1

IPv4 Route Table

255.255.255.255 255.255.255.255 On-link 10.0.3.5 281

0.0.0.0 0.0.0.0 192.168.254.5 Default

IPv6 Route Table

14 281 ff00::/8 On-link

Your answer