none
Routing to VPN clients? RRS feed

  • Question


  • AlwaysON VPN server is setup in DMZ (one interface NATed to external network with its own gateway, second to internal LAN with no gateway), default all clients on LAN out routing happens via LAN default gateway

    Any idea how to be able to route back to the client from LAN workstation?

    AOVPN server private interface (10.0.0.x/16), LAN workstations 10.0.10.x/16, VPN clients (get IP from AOVPN server pool 10.0.16.0-10.0.16.254)

    VPN client can access all LAN resources, but no LAN workstation can access VPN client

    Seb


    • Edited by scerazy Tuesday, May 28, 2019 4:11 PM
    Tuesday, May 28, 2019 3:50 PM

All replies

  • Hi,

    Can you ping the VPN client?

    Did you turn on network discovery on VPN client? what about firewall?

    Best regards,

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Wednesday, May 29, 2019 5:46 AM
    Moderator
  • It is nothing to do with network discovery, nothing to do with firewall (AlwaysON are just domain machines connected elsewhere, with VPN recognized as domain network!)

    Ofoncourse I can not ping that client because there is no routing to it (hence the question!)

    Seb

    Wednesday, May 29, 2019 6:55 AM
  • Hi,

    Ofoncourse I can not ping that client because there is no routing to it  

    Why not check the route table and add routing you need? 

    Use command tracert to check the route, especially the gateway.

    Best regards,

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Wednesday, May 29, 2019 7:23 AM
    Moderator
  • But I have no idea what route it might be when the whole lot is after all FLAT network (maybe that is why I am asking here?)

    VPN server private interface 10.0.0.100/16

    VPN client is 10.0.16.2/? (/32 ?)

    LAN client is 10.0.15.1/16

    Equally I can not ping the client even from the AlwaysON VPN server itself!

    Routing table on the server looks like:

    Active Routes:
    Network Destination        Netmask          Gateway       Interface  Metric
              0.0.0.0          0.0.0.0       172.19.1.1       172.19.1.2    266
             10.0.0.0      255.255.0.0         On-link         10.0.0.15    266
            10.0.0.15  255.255.255.255         On-link         10.0.0.15    266
            10.0.16.1  255.255.255.255         On-link         10.0.16.1    287
            10.0.16.2  255.255.255.255        10.0.16.2        10.0.16.1     32
            10.0.16.4  255.255.255.255        10.0.16.4        10.0.16.1     32
            10.0.16.5  255.255.255.255        10.0.16.5        10.0.16.1     32
            10.0.16.6  255.255.255.255        10.0.16.6        10.0.16.1     32
            10.0.16.8  255.255.255.255        10.0.16.8        10.0.16.1     32
            10.0.16.9  255.255.255.255        10.0.16.9        10.0.16.1     32
           10.0.16.10  255.255.255.255       10.0.16.10        10.0.16.1     32

    • Edited by scerazy Wednesday, May 29, 2019 12:33 PM
    Wednesday, May 29, 2019 11:29 AM
  • Hello Seb,

    Could you just humour me and show the output of the PowerShell cmdlet Get-NetConnectionProfile on a client connected to the VPN? This is to just verify the Network Category/Profile that is in use. I see the following in a similar situation:

    Name             : Test 14
    InterfaceAlias   : Test
    InterfaceIndex   : 42
    NetworkCategory  : Public
    IPv4Connectivity : Internet
    IPv6Connectivity : NoTraffic
    
    Name             : Dagmar & Gary
    InterfaceAlias   : WiFi
    InterfaceIndex   : 9
    NetworkCategory  : Private
    IPv4Connectivity : LocalNetwork
    IPv6Connectivity : NoTraffic

    Routing plays a very limited role in your set-up: "Proxy ARP" does all of the heavy lifting (the VPN server performs proxy ARP for all of its VPN clients).

    If ping works in one direction then, firewall filtering aside, it should work in the other direction - from a route finding point of view, there is no difference between an echo reply wending its way back to the client and an echo request from the server pioneering a way to the client.

    Gary


    Wednesday, May 29, 2019 3:57 PM
  • Name             : Private3-5g
    InterfaceAlias   : Wi-Fi
    InterfaceIndex   : 6
    NetworkCategory  : Private
    IPv4Connectivity : Internet
    IPv6Connectivity : NoTraffic
    
    Name             : AO
    InterfaceAlias   : AO
    InterfaceIndex   : 96
    NetworkCategory  : Private
    IPv4Connectivity : LocalNetwork
    IPv6Connectivity : NoTraffic

    PPP adapter AO:
    
       Connection-specific DNS Suffix  . :
       IPv4 Address. . . . . . . . . . . : 10.0.16.6
       Subnet Mask . . . . . . . . . . . : 255.255.255.255
       Default Gateway . . . . . . . . . :
    
    Wireless LAN adapter Wi-Fi:
    
       Connection-specific DNS Suffix  . :
       IPv4 Address. . . . . . . . . . . : 192.168.88.98
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . : 192.168.88.1
    
    PS C:\Users\me> ping 10.0.0.21
    
    Pinging 10.0.0.21 with 32 bytes of data:
    Reply from 10.0.0.21: bytes=32 time=11ms TTL=127
    Reply from 10.0.0.21: bytes=32 time=12ms TTL=127
    Reply from 10.0.0.21: bytes=32 time=12ms TTL=127
    Reply from 10.0.0.21: bytes=32 time=13ms TTL=127
    
    Ping statistics for 10.0.0.21:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 11ms, Maximum = 13ms, Average = 12ms
    

    Wednesday, May 29, 2019 8:56 PM
  • Hello Seb,

    Sorry that that did not throw any light on the problem, but I still think that it is worth one more look at the packet drop idea. Essentially, we just need to see if the Windows Filtering Platform drops any packets on the client when the client is pinged from the server. There are lots of ways of doing this, but if you can issue commands on both the client and server in a short interval, then you could try this:

    • Ping the client from the server, wait for the 4 attempts to time out.
    • On the client, issue a command like "netsh wfp show netevents protocol=1 file=-"

    I see this:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <netEvents numItems="3">
    	<item>
    		<header>
    			<timeStamp>2019-05-29T21:58:26.363Z</timeStamp>
    			<flags numItems="8">
    				<item>FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_APP_ID_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_USER_ID_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_IP_VERSION_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_PACKAGE_ID_SET</item>
    			</flags>
    			<ipVersion>FWP_IP_VERSION_V4</ipVersion>
    			<ipProtocol>1</ipProtocol>
    			<localAddrV4>192.168.0.134</localAddrV4>
    			<remoteAddrV4>192.168.0.128</remoteAddrV4>
    			<localPort>8</localPort>
    			<remotePort>0</remotePort>
    			<scopeId>0</scopeId>
    			<appId>
    				<data>530079007300740065006d000000</data>
    				<asString>S.y.s.t.e.m...</asString>
    			</appId>
    			<userId>S-1-5-18</userId>
    			<addressFamily>FWP_AF_INET</addressFamily>
    			<packageSid>S-1-0-0</packageSid>
    			<enterpriseId/>
    			<policyFlags>0</policyFlags>
    			<effectiveName/>
    		</header>
    		<type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>
    		<classifyDrop>
    			<filterId>385351</filterId>
    			<layerId>44</layerId>
    			<reauthReason>0</reauthReason>
    			<originalProfile>1</originalProfile>
    			<currentProfile>1</currentProfile>
    			<msFwpDirection>MS_FWP_DIRECTION_OUT</msFwpDirection>
    			<isLoopback>false</isLoopback>
    			<vSwitchId/>
    			<vSwitchSourcePort>0</vSwitchSourcePort>
    			<vSwitchDestinationPort>0</vSwitchDestinationPort>
    		</classifyDrop>
    	</item>
    	<item>
    		<header>
    			<timeStamp>2019-05-29T21:58:31.380Z</timeStamp>
    			<flags numItems="8">
    				<item>FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_APP_ID_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_USER_ID_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_IP_VERSION_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_PACKAGE_ID_SET</item>
    			</flags>
    			<ipVersion>FWP_IP_VERSION_V4</ipVersion>
    			<ipProtocol>1</ipProtocol>
    			<localAddrV4>192.168.0.134</localAddrV4>
    			<remoteAddrV4>192.168.0.128</remoteAddrV4>
    			<localPort>8</localPort>
    			<remotePort>0</remotePort>
    			<scopeId>0</scopeId>
    			<appId>
    				<data>530079007300740065006d000000</data>
    				<asString>S.y.s.t.e.m...</asString>
    			</appId>
    			<userId>S-1-5-18</userId>
    			<addressFamily>FWP_AF_INET</addressFamily>
    			<packageSid>S-1-0-0</packageSid>
    			<enterpriseId/>
    			<policyFlags>0</policyFlags>
    			<effectiveName/>
    		</header>
    		<type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>
    		<classifyDrop>
    			<filterId>385351</filterId>
    			<layerId>44</layerId>
    			<reauthReason>0</reauthReason>
    			<originalProfile>1</originalProfile>
    			<currentProfile>1</currentProfile>
    			<msFwpDirection>MS_FWP_DIRECTION_OUT</msFwpDirection>
    			<isLoopback>false</isLoopback>
    			<vSwitchId/>
    			<vSwitchSourcePort>0</vSwitchSourcePort>
    			<vSwitchDestinationPort>0</vSwitchDestinationPort>
    		</classifyDrop>
    	</item>
    	<item>
    		<header>
    			<timeStamp>2019-05-29T21:58:36.443Z</timeStamp>
    			<flags numItems="8">
    				<item>FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_APP_ID_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_USER_ID_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_IP_VERSION_SET</item>
    				<item>FWPM_NET_EVENT_FLAG_PACKAGE_ID_SET</item>
    			</flags>
    			<ipVersion>FWP_IP_VERSION_V4</ipVersion>
    			<ipProtocol>1</ipProtocol>
    			<localAddrV4>192.168.0.134</localAddrV4>
    			<remoteAddrV4>192.168.0.128</remoteAddrV4>
    			<localPort>8</localPort>
    			<remotePort>0</remotePort>
    			<scopeId>0</scopeId>
    			<appId>
    				<data>530079007300740065006d000000</data>
    				<asString>S.y.s.t.e.m...</asString>
    			</appId>
    			<userId>S-1-5-18</userId>
    			<addressFamily>FWP_AF_INET</addressFamily>
    			<packageSid>S-1-0-0</packageSid>
    			<enterpriseId/>
    			<policyFlags>0</policyFlags>
    			<effectiveName/>
    		</header>
    		<type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>
    		<classifyDrop>
    			<filterId>385351</filterId>
    			<layerId>44</layerId>
    			<reauthReason>0</reauthReason>
    			<originalProfile>1</originalProfile>
    			<currentProfile>1</currentProfile>
    			<msFwpDirection>MS_FWP_DIRECTION_OUT</msFwpDirection>
    			<isLoopback>false</isLoopback>
    			<vSwitchId/>
    			<vSwitchSourcePort>0</vSwitchSourcePort>
    			<vSwitchDestinationPort>0</vSwitchDestinationPort>
    		</classifyDrop>
    	</item>
    </netEvents>
    

    Gary

    Wednesday, May 29, 2019 10:02 PM
  • Same?

    But it is not only ping that is the issue (I used it as example). I need to be able to connect back to clients with ie SCCM Remote Control

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <netEvents numItems="3">
            <item>
                    <header>
                            <timeStamp>2019-05-30T06:53:16.549Z</timeStamp>
                            <flags numItems="8">
                                    <item>FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_APP_ID_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_USER_ID_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_IP_VERSION_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_PACKAGE_ID_SET</item>
                            </flags>
                            <ipVersion>FWP_IP_VERSION_V4</ipVersion>
                            <ipProtocol>1</ipProtocol>
                            <localAddrV4>10.0.16.7</localAddrV4>
                            <remoteAddrV4>10.0.16.1</remoteAddrV4>
                            <localPort>8</localPort>
                            <remotePort>0</remotePort>
                            <scopeId>0</scopeId>
                            <appId>
                                    <data>530079007300740065006d000000</data>
                                    <asString>S.y.s.t.e.m...</asString>
                            </appId>
                            <userId>S-1-5-18</userId>
                            <addressFamily>FWP_AF_INET</addressFamily>
                            <packageSid>S-1-0-0</packageSid>
                            <enterpriseId/>
                            <policyFlags>0</policyFlags>
                            <effectiveName/>
                    </header>
                    <type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>
                    <classifyDrop>
                            <filterId>88878</filterId>
                            <layerId>44</layerId>
                            <reauthReason>0</reauthReason>
                            <originalProfile>2</originalProfile>
                            <currentProfile>2</currentProfile>
                            <msFwpDirection>MS_FWP_DIRECTION_OUT</msFwpDirection>
                            <isLoopback>false</isLoopback>
                            <vSwitchId/>
                            <vSwitchSourcePort>0</vSwitchSourcePort>
                            <vSwitchDestinationPort>0</vSwitchDestinationPort>
                    </classifyDrop>
            </item>
            <item>
                    <header>
                            <timeStamp>2019-05-30T06:53:21.671Z</timeStamp>
                            <flags numItems="8">
                                    <item>FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_APP_ID_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_USER_ID_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_IP_VERSION_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_PACKAGE_ID_SET</item>
                            </flags>
                            <ipVersion>FWP_IP_VERSION_V4</ipVersion>
                            <ipProtocol>1</ipProtocol>
                            <localAddrV4>10.0.16.7</localAddrV4>
                            <remoteAddrV4>10.0.16.1</remoteAddrV4>
                            <localPort>8</localPort>
                            <remotePort>0</remotePort>
                            <scopeId>0</scopeId>
                            <appId>
                                    <data>530079007300740065006d000000</data>
                                    <asString>S.y.s.t.e.m...</asString>
                            </appId>
                            <userId>S-1-5-18</userId>
                            <addressFamily>FWP_AF_INET</addressFamily>
                            <packageSid>S-1-0-0</packageSid>
                            <enterpriseId/>
                            <policyFlags>0</policyFlags>
                            <effectiveName/>
                    </header>
                    <type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>
                    <classifyDrop>
                            <filterId>88878</filterId>
                            <layerId>44</layerId>
                            <reauthReason>0</reauthReason>
                            <originalProfile>2</originalProfile>
                            <currentProfile>2</currentProfile>
                            <msFwpDirection>MS_FWP_DIRECTION_OUT</msFwpDirection>
                            <isLoopback>false</isLoopback>
                            <vSwitchId/>
                            <vSwitchSourcePort>0</vSwitchSourcePort>
                            <vSwitchDestinationPort>0</vSwitchDestinationPort>
                    </classifyDrop>
            </item>
            <item>
                    <header>
                            <timeStamp>2019-05-30T06:53:26.585Z</timeStamp>
                            <flags numItems="8">
                                    <item>FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_APP_ID_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_USER_ID_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_IP_VERSION_SET</item>
                                    <item>FWPM_NET_EVENT_FLAG_PACKAGE_ID_SET</item>
                            </flags>
                            <ipVersion>FWP_IP_VERSION_V4</ipVersion>
                            <ipProtocol>1</ipProtocol>
                            <localAddrV4>10.0.16.7</localAddrV4>
                            <remoteAddrV4>10.0.16.1</remoteAddrV4>
                            <localPort>8</localPort>
                            <remotePort>0</remotePort>
                            <scopeId>0</scopeId>
                            <appId>
                                    <data>530079007300740065006d000000</data>
                                    <asString>S.y.s.t.e.m...</asString>
                            </appId>
                            <userId>S-1-5-18</userId>
                            <addressFamily>FWP_AF_INET</addressFamily>
                            <packageSid>S-1-0-0</packageSid>
                            <enterpriseId/>
                            <policyFlags>0</policyFlags>
                            <effectiveName/>
                    </header>
                    <type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>
                    <classifyDrop>
                            <filterId>88878</filterId>
                            <layerId>44</layerId>
                            <reauthReason>0</reauthReason>
                            <originalProfile>2</originalProfile>
                            <currentProfile>2</currentProfile>
                            <msFwpDirection>MS_FWP_DIRECTION_OUT</msFwpDirection>
                            <isLoopback>false</isLoopback>
                            <vSwitchId/>
                            <vSwitchSourcePort>0</vSwitchSourcePort>
                            <vSwitchDestinationPort>0</vSwitchDestinationPort>
                    </classifyDrop>
            </item>
    </netEvents>



    • Edited by scerazy Thursday, May 30, 2019 7:04 AM
    Thursday, May 30, 2019 6:58 AM
  • Hello Seb,

    Demonstrating that "ping" fails due to filtering by WFP was just necessary in order to show that "routing" (in the general sense of finding a path to an endpoint) is working.

    I have a personal (theoretical) interest in understanding the reasons why WFP is dropping this traffic and am looking at the issue again now, and you can now focus your troubleshooting on filtering rather than routing too...

    Gary

    Thursday, May 30, 2019 8:32 AM
  • Thanks, but that is not easy to troubleshoot, as they are domain machines, just connected over VPN

    Hence one would expect that it all working as designed (in domain)


    And in fact I even disabled firewall on my test machine, no difference
    • Edited by scerazy Thursday, May 30, 2019 10:49 AM
    Thursday, May 30, 2019 10:48 AM
  • Hello Seb,

    I am retired and don't have a test set-up for Always On VPN. One approach is to just see if any other AOVPN users have similar problems.

    Richard Hicks wrote (for example, with my emphasis in bold):

    • When configuring a device tunnel, traffic filters can be implemented to restrict communication to only those internal resources required, such as domain controllers, Windows Server Update Services (WSUS) or System Center Configuration Manager (SCCM) servers. However, when traffic filters are used, no inbound traffic to the client is allowed. If manage out is required over the device tunnel, traffic filters cannot be configured. Microsoft expects to remove this limitation in a future update.
    • https://directaccess.richardhicks.com/2017/11/21/always-on-vpn-device-tunnel-configuration-guidance-now-available/

    What I am trying is approaching the problem from a base API (BFE (Base Filtering Engine), WFP (Windows Filtering Platform)) point of view. There are a few mentions of this odd "Query User" "Prompt the User for a decision corresponding this Inbound Traffic" rule (the one causing the packet drop) findable with Google, but no-one seems to know its intended purpose.

    Gary




    Thursday, May 30, 2019 11:20 AM
  • Hello Seb,

    This might sound like an odd request, but can you confirm that you really have a problem with a necessary inbound network service on the VPN clients?

    I am guessing that you just tried to "ping" the VPN clients and when that did not work, you assumed that you had a routing (and/or filtering) problem.

    My current guess is that the filter that is dropping the ping requests is just the "Default Inbound" rule with a slightly misleading name ("Query User"); it has a relatively low filter weight.

    Normally, for a Private or Domain profile network connection, inbound ping requests are allowed by this rule:

    As the text in the yellow box informs us, "This is a predefined rule and some of its properties cannot be modified". The underlying filtering mechanism (https://docs.microsoft.com/en-us/windows/desktop/fwp/filtering-conditions) is much more complex than can be managed by the user interface.

    In the case of the "File and Printer Sharing (Echo Request - ICMPv4-In)" rule, there is a filtering condition that is not visible in the user interface:

    <item>
    	<fieldKey>FWPM_CONDITION_ARRIVAL_TUNNEL_TYPE</fieldKey>
    	<matchType>FWP_MATCH_EQUAL</matchType>
    	<conditionValue>
    		<type>FWP_UINT32</type>
    		<uint32>0</uint32>
    	</conditionValue>
    </item>

    For ICMP echo requests arriving via the VPN tunnel, this rule will not match and the default "block inbound connections that do not match a rule" will be applied.

    Many of the other inbound rules in the Domain and Private profiles do not include this condition so they should succeed. Therefore my request that you try initiating something from your internal LAN to a VPN client and let us know if it works and, in the case of failure, which network service was tested.

    Gary

    Thursday, May 30, 2019 1:05 PM
  • Hello Seb,

    The first network service that I thought of testing was SMB (File and Printer Sharing) but that is protected by a "tunnel type" condition too. Remote Desktop (RDP) might be a good choice if that is enabled on your clients...

    Gary

    Thursday, May 30, 2019 1:18 PM
  • OK, with firewall OFF it does indeed work!

    Excellent catch Gary!

    But what does not work is:

    If FW is ON, I can not control clients via SCCM Remote Control (and this is the only bit that I actually need!)

    Thanks

    Seb

    • Edited by scerazy Thursday, May 30, 2019 1:43 PM
    Thursday, May 30, 2019 1:35 PM
  • Hello Seb,

    OK - what we now need to do is look at the firewall rules that allow SCCM remote control for your clients, see which filter condition is possibly failing and work out the minimal intervention to get it working. This sounds like it could be a common issue (SCCM Remote Control and AOVPN), so a web search using those keywords might help now that we know exactly what we are looking for.

    As one would expect, I don't have any SCCM rules on my private PCs so I can't check directly.

    Do the SCCM rules have the "This is a predefined rule and some of its properties cannot be modified" warning?

    If not, you could just try relaxing any aspect of the rule which looks like it might not be applicable to your VPN clients.

    The way to see the how the rules are implemented is to re-enable the firewall and then issue a command like "netsh wfp show state file=sccm.xml". This will produce a multi-megabyte XML file with all of the rules.

    The XML is understandable, but having some experience with the WFP/BFE helps. The name that appears in the "Windows Defender with Advanced Security" mmc snap-in for the rule will be present in all of the low-level elements in the sccm.xml file. If relaxing the rules does not work and it is not too much effort then you could just send them in this forum, perhaps eliminating the "_V6" (IPv6) versions (there will probably be corresponding _V4 and _V6 items for everything).

    The WFP state file can contain secrets (such as pre-shared keys on VPN servers) but it is normally pretty innocuous on client systems, so you could instead make the whole file available via a OneDrive or similar if that helps.

    Gary

    Thursday, May 30, 2019 2:19 PM
  • SCCM rule is either a port (TCP 2701) applied to Domain & Private network

    It is not predefined, it is hand crafted applied by GPO


    				<item>
    					<filterKey>{3f14072d-feed-41fd-982f-63caf8904931}</filterKey>
    					<displayData>
    						<name>SCCM Remote Control Service</name>
    						<description/>
    					</displayData>
    					<flags/>
    					<providerKey>{decc16ca-3f33-4346-be1e-8fb4ae0f3d62}</providerKey>
    					<providerData>
    						<data>8707000000000000</data>
    						<asString>........</asString>
    					</providerData>
    					<layerKey>FWPM_LAYER_ALE_AUTH_LISTEN_V4</layerKey>
    					<subLayerKey>{b3cdd441-af90-41ba-a745-7c6008ff2301}</subLayerKey>
    					<weight>
    						<type>FWP_UINT8</type>
    						<uint8>9</uint8>
    					</weight>
    					<filterCondition numItems="1">
    						<item>
    							<fieldKey>FWPM_CONDITION_IP_LOCAL_PORT</fieldKey>
    							<matchType>FWP_MATCH_EQUAL</matchType>
    							<conditionValue>
    								<type>FWP_UINT16</type>
    								<uint16>2701</uint16>
    							</conditionValue>
    						</item>
    					</filterCondition>
    					<action>
    						<type>FWP_ACTION_PERMIT</type>
    						<filterType/>
    					</action>
    					<rawContext>0</rawContext>
    					<reserved/>
    					<filterId>73852</filterId>
    					<effectiveWeight>
    						<type>FWP_UINT64</type>
    						<uint64>10376293542535364352</uint64>
    					</effectiveWeight>
    				</item>



    • Edited by scerazy Thursday, May 30, 2019 2:33 PM
    Thursday, May 30, 2019 2:27 PM
  • Hello Seb,

    It looks as though your scenario should just work; here is an extract from https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-map-da:

    Use of manage-out to allow remote connectivity to clients from management systems located on the corporate network. You can achieve this functionality by using the Device Tunnel feature in the VPN profile combined with configuring the VPN connection to dynamically register the IP addresses assigned to the VPN interface with internal DNS services.

    Note.
    If you turn on traffic filters in the Device Tunnel profile, then the Device Tunnel denies inbound traffic (from the corporate network to the client).

    Define using:
    VPNv2/ProfileName/DeviceTunnel
    VPNv2/ProfileName/RegisterDNS

    Could you try SCCM Remote Control again and then use "netsh wfp show netevents file=-" again on the client to make sure that we are still facing a filtering problem? It may be the case that something else (perhaps DNS related) is wrong and it just manifests itself in the same way (e.g. does not respond).

    Gary



    Thursday, May 30, 2019 2:35 PM

  • AOVPN server private interface (10.0.0.x/16), LAN workstations 10.0.10.x/16, VPN clients (get IP from AOVPN server pool 10.0.16.0-10.0.16.254)

    Hi scerazy,

    there is no any routing, because the network is the same: 10.0.XXX.XXX/16

    Enable firewall logging for each profile on a client:

    And then watch the live logs using powershell command:

    Get-Content C:\Windows\System32\LogFiles\Firewall\pfirewall.log -Tail 50 -wait
    Thursday, May 30, 2019 2:50 PM
  • Will do the capture next week. But it is not DNS issue, as I was trying with client's IP (that I can see as connected in AON VPN server RRAS)

    I do indeed have filters in device config

      <TrafficFilter>
        <RemoteAddressRanges>10.0.0.21, 10.0.0.22, 10.0.0.20, 10.0.0.7, 10.0.0.24, 10.0.0.12</RemoteAddressRanges>
      </TrafficFilter>

    but it makes no sense, cause with firewall OFF on a VPN client I can ping that client from 10.0.0.99 (which is definitely not in above list!)

    I do have

      <RegisterDNS>True</RegisterDNS>

    but it definitely DOES NOT work,  it does not register with DNS (which is kind of correct, because I have GPO configured to not register in DNS, secure updates are handled by DHCP server, and VPN clients do get address from IP Pool, as I could not get DHCP relay agent working

    Seb

    • Edited by scerazy Thursday, May 30, 2019 4:59 PM
    Thursday, May 30, 2019 4:35 PM
  • But we already know it is the firewall filters!
    Thursday, May 30, 2019 4:36 PM
  • But we already know it is the firewall filters!
    Logs show you what exactly is filtered. Then you can create allowing rules for certain ports or protocols as profiles as well
    Thursday, May 30, 2019 4:51 PM
  • Hello Seb,

    I believe that the TrafficFilter limits what the VPN client can reach in the target network - not which systems in the target network can connect back to the client.

    With TrafficFilter defined, normally no system on the LAN can connect back to the client (according to that extract from the Microsoft documentation that I posted earlier) - and that is what we observe.

    With TrafficFilter defined and firewall disabled on the VPN client (probably the mechanism that implements the TrafficFilter amongst other things) then every system on the LAN can connect back to the client.

    I would suggest that the next step should be to remove the TrafficFilter, enable the firewall and then see what works.

    Gary

    Thursday, May 30, 2019 5:09 PM
  • I will do that. The whole AlwaysON VPN to me looks like usual MS great-but-unfinished idea
    Thursday, May 30, 2019 6:03 PM
  • 2019-05-30 19:09:15 DROP ICMP 10.0.0.99 10.0.16.6 - - 60 - - - - 8 0 - RECEIVE

    and same from IP that IS in filter list

    2019-05-30 19:14:29 DROP ICMP 10.0.0.20 10.0.16.6 - - 60 - - - - 8 0 - RECEIVE

    That is with firewall ON

    • Edited by scerazy Thursday, May 30, 2019 6:16 PM
    Thursday, May 30, 2019 6:12 PM