Some IP address behind the Client-connector are not accessible from Windows hosts using Microsoft Defender Firewall
search cancel

Some IP address behind the Client-connector are not accessible from Windows hosts using Microsoft Defender Firewall

book

Article ID: 373469

calendar_today

Updated On:

Products

VMware VeloCloud SD-WAN Edge Appliance

Issue/Introduction

Enterprise administrator decides the IP address range which will be behind the Client-Connector and those IP addresses will be reachable through the Client-Connector when the user logs into SDWAN-Client application.

But with MS Windows Defender Firewall turned ON (with default policy) , some of the IP address are not reachable.

  

Environment

VMware SD-Access , Velocloud SDWAN-Client,

MS Windows Defender Firewall

Cause

When an IP range is defined the Client-Connector sends the range to the Users and User system OS puts those range in the routing table.

Under Network Resource , the Target IP Range configuration does not carry any subnet information. The Enterprise administrator defines the start and end IP address only as described in the product guide.

The user (client laptop e.g Windows) machine upon receiving the IP range segregates the range to fit under a subnet mask.

If the user system is running with MS Windows Defender Firewall turned ON (with default policy) ,then some of the IP address may not be reachable.

Resolution

This happens as the user system OS tries to fit the defined IP range into the all possible subnets.

During this process some of the IP address will be classified as Broadcast IP in those ranges and get installed in the host kernel with metric of 258.

With Microsoft Defender Firewall turned on, when the response comes back from these IPs, the host system firewall silently drops them.

Lets compare route table information for two entries

10.1.50.1-10.1.50.254 vs 10.1.31.0-10.1.31.255

  • When 10.1.50.1-10.1.50.254 is configured under IP Range of Network Resource, the Client connector pushes that as a route to point to on-link (tunnel). The host OS further tries to fit that into all possible subnets and add them to routing table.
    10.1.50.1-10.1.50.254 is now divided  into multiple subnets (/26,/27,/28,/29,/30,/31,/32).
    The respective Broadcast IP address in those subnets will have the metric of 258.
    Refer to the picture below:

  • When 10.1.31.0-10.1.31.255 is configured the host OS creates a proper subnet of /24 and adds to the routing table. [This is the preferred way]
    Refer to the picture below:



If the purpose is to define a range of IP addresses then define the range which fits into a proper subnet.

Additional Information

To troubleshoot the issue, please follow below steps:

  1. Please check whether the route is present to the destination host
  2. If the route is present then check if the Gateway points to On-link and Interface to the SD-WAN Client Tunnel interface IP
  3. Do a traceroute to the destination IP
  4. Ping the destination IP address and make sure the ICMP request/response is allowed on the destination host
  5. Initiate a continuous ping and take packet capture on the SD-WAN Client Tunnel interface (8e14-0 adapter)

If issue still persists and unable to identify the root cause, please submit a case with Support with all the required details (as mentioned in KB 368552).