Member Avatar for Max_20
Max_20 0 Newbie Poster

I have a home lab I am trying to configure multiple subnets on and use Routing and Remote Access LAN Routing to get everything talking. I have two hosts w/ 5 physical NICS running Hyper-V. I have the NICS configured on each host so they each are in a different subnet. Example Host 1 NIC 1 10.10.10.1 Host 2 NIC 1 10.10.10.2 Host 1 NIC 2 10.10.20.1 Host 2 NIC 2 10.10.20.2. I can ping the IPs of each hosts nic from each other. So I know the two hosts are communicating. I setup a RRAS server with 5 virtual NICs (each one associated with one of the 5 physical NICs) and can ping both of the hosts from the RRAS server....all of the IPs assigned. So, I know the RRAS server can talk to the IPs on all of the NICs on both hosts. I have setup RRAS Lan Routing and did no additional configuration. However, my clients that have their default gateway set to the RRAS server cannot talk to systems outside of their own subnet. For example, client A 10.10.10.10 can talk to client B 10.10.10.11 but client A cannot talk to client C 10.10.20.10. This is driving me crazy because I know I have done this before and it was never this difficult. Please help anyone.

  • 1 Contributor
  • 0 Replies
  • 385 Views

Dani AI

Generated

In the setup described by (two Hyper‑V hosts with multiple physical NICs and an RRAS VM that can ping all host NICs), the fact that local pings succeed but clients cannot reach other subnets almost always means a routing/return‑path or virtualization switch issue rather than a basic link problem.

Recommended checks and quick diagnostics:

  • Confirm a client can ping its RRAS gateway IP. Failure here is L2/VLAN or virtual‑switch binding.
  • From a client run a traceroute to a remote subnet to see where packets stop.
  • On the RRAS server verify the Routing and Remote Access service is started and that the server’s routing table contains the expected connected routes (route print or netsh interface ipv4 show route).
  • Check Windows Firewall on the RRAS host (and on hypervisor hosts) — firewall rules can block forwarded traffic or ICMP used during tests.
  • Verify Hyper‑V virtual switches are External (not the NATed Default Switch) and are bound to the correct physical NICs/VLANs.

Most common root causes and fixes seen in labs:

  • Asymmetric routing: other hosts (or the hypervisor management OS) have a different default gateway, so replies never return via RRAS. Fix by making RRAS the default gateway for those subnets or adding static routes on the other hosts pointing back to RRAS. Avoid setting multiple default gateways on Windows hosts; use persistent static routes instead.
  • Virtual switch type or VLAN mismatch: external vs NAT/internal switches or wrong VLAN tags will look like connectivity to the host IPs but will break routed traffic between VMs.
  • RRAS interface not enabled for IPv4 routing or RRAS not fully configured — confirm via the RRAS MMC and the service state.

Useful commands to capture for troubleshooting:

ping <gateway>
tracert <remote-ip>
route print
netsh interface ipv4 show route
sc query RemoteAccess
reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v IPEnableRouter
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.