Robert Meany's questions

I'm trying to understand why my internal network machines are unable to RDP into my DirectAccess clients.. My internal network is on IPv6, so there is no ISATAP going on.. Just direct routes to and from the clients.. I am able to ping the DA clients from my management devices on the internal network without issue.. But when I try to RDP directly into one of the DA clients, I am unable to connect. The clients are accepting RDP connections.

To rule out windows firewall, I set blanket allow rules on the management pc, the DA server and the remote client I am testing.

I used wireshark to do some investigation and found that the DA server receives the RDP connection request on 3389 with the correct IPV6 source of the management computer, and the correct IP-HTTPS IPV6 tunnel address of the DA client.

I can't read the traffic beyond that as it becomes encrypted in the IP-HTTPS tunnel, but I am not seeing any connection attempts getting logged in windows firewall on the remote client.

I am able to establish an RDP connection directly from the DA server itself.

I'm at a loss of where to go from here and would appreciate if anyone can provide assistance.

If you need more information let me know what you need and I'll get it to you.

I'm setting up and testing IPv6 on our network and have run into a snag with our windows clients..

I've got a Cisco Catalyst 3850 switch setup for ipv6 unicast-routing and have two networks setup on it. The catalyst switch also has a working ipv6 route out to the internet and I've been able to successfully contact public ipv6 server addresses without issue from the switch CLI (from the switch's ipv6 gateway address on either network).

The gateway addresses/networks on the switch are: VLAN 20: 2607:f460:21c0:a020::1/64 VLAN 200: 2607:f460:21c0:a200::1/64

I can ping one of the configured networks from the other with no issue:

ping 2607:f460:21c0:a200::1 source 2607:f460:21c0:a020::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2607:F460:21C0:A200::1, timeout is 2 seconds:
Packet sent with a source address of 2607:F460:21C0:A020::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms

There are no ACLs or special routes setup on the switch other than the default ::/0 public route to the internet.

The windows client resides on VLAN 20 and has the static address: 2607:f460:21c0:a020::2/64 with 2607:f460:21c0:a020::1 set as the default gateway..

If I ping the gateway, it works...

C:\Windows\system32>ping 2607:f460:21c0:a020::1

Pinging 2607:f460:21c0:a020::1 with 32 bytes of data:
Reply from 2607:f460:21c0:a020::1: time=2ms
Reply from 2607:f460:21c0:a020::1: time=2ms
Reply from 2607:f460:21c0:a020::1: time=2ms

C:\Windows\system32>tracert -6 2607:f460:21c0:a020::1

Tracing route to 2607:f460:21c0:a020::1 over a maximum of 30 hops

  1     2 ms     2 ms     2 ms  2607:f460:21c0:a020::1

Trace complete.

If I try to ping anything outside the local On-Link network, it fails with an unreachable error:

C:\Windows\system32>ping 2607:f460:21c0:a200::1

Pinging 2607:f460:21c0:a200::1 with 32 bytes of data:
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.

Ping statistics for 2607:f460:21c0:a200::1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),


Tracing route to 2607:f460:21c0:a200::1 over a maximum of 30 hops

  1  Destination host unreachable.

Trace complete.

The fact that the trace fails on the first hop with unreachable implies to me that windows does not seem to be trying to contact the default route but rather is searching for the host on-link...

This doesn't make sense to me, because I have a gateway set, and it has a lower metric than the on-link route..

===========================================================================
Interface List
  7...00 50 56 94 e7 38 ......vmxnet3 Ethernet Adapter
  1...........................Software Loopback Interface 1
===========================================================================

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
  7    271 ::/0                     On-link
  7    271 ::/0                     fe80::521c:bfff:fe73:1656
  7     16 ::/0                     2607:f460:21c0:a020::1
  1    331 ::1/128                  On-link
  7    271 2607:f460:21c0:a020::/64 On-link
  7    271 2607:f460:21c0:a020:947a:1291:c6e3:b93d/128
                                    On-link
  7    271 fd67:df27:a77::/48       On-link
  7    271 fd67:df27:a77:7777::/96  On-link
  7    271 fe80::/64                On-link
  7    271 fe80::947a:1291:c6e3:b93d/128
                                    On-link
  1    331 ff00::/8                 On-link
  7    271 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

Anyone able to help me with this?

Just curious.. I was thinking that, on a NAT firewall that is normally overloaded, offloading some or all of the IPV4 traffic to IPV6 might make a performance difference?

I'm trying to get machine authentication working with Microsoft "always on vpn".. I'm running into error 13801 on attempting to connect with a client. This error implies there is some sort of certificate-related issue - though I've gone through and checked all of the obvious items.

Both the client and the RAS server have the CA as a trusted root authority and both have been issued certificates, kept in their local computer/personal stores. The client has client authentication EKU and the server has server authentication, IPSEC IKE intermediate and Client Auth EKUs. The subject name on the server cert matches the host name in the client's connection. I've also disabled IKE EKU and CRL checking on the client as part of the troubleshooting process.

I've generated RRAS trace logs and all I can see are that the vpnike module is kicking back with error 13801.. I don't see anything about the process it went through, which certs it actually attempted to use etc...

Here is config output on my client's VPN connection, which was created per Microsoft directions using the system context so the machine certificate could be used...

ServerAddress         : server.domain.com
AllUserConnection     : True
Guid                  : {87C51048-BC50-475F-8CEF-2C9C49687205}
TunnelType            : Ikev2
AuthenticationMethod  : {MachineCertificate}
EncryptionLevel       : Maximum
L2tpIPsecAuth         :
UseWinlogonCredential : False
EapConfigXmlStream    :
ConnectionStatus      : Disconnected
RememberCredential    : True
SplitTunneling        : True
DnsSuffix             :
IdleDisconnectSeconds : 0