RRAS VPN cannot connect to remote client

Question

Hi,

I have just deployed an always on VPN built on RRAS on a Server 2022 box.

The server has two NICs, VPN and LAN.
VPN is 172.16.1.6 with a gateway of 172.16.1.1 which is our external firewall and is used for incoming and outgoing connectivity for remote clients.
LAN is 10.0.1.57 with no gateway, but static routes for 10.0.0.0/24 and 10.0.1.0/24 pointing to 10.0.0.5 which is our internal router.

Clients are provided a 172.16.1.0/24 address from a static pool configured in RRAS.

As it stands, remotely connected clients seem to be able to access internal resources as expected, but I am having trouble routing to these clients from an on premise device for remote management.
My routing gets as far as the RRAS server then fails to route out to the client.
Looking at the route table on the RRAS server, I see a route for the remote client IP of 172.16.1.15/32 with gateway of 172.16.1.15 and interface 172.16.1.10 (internal interface shown in RRAS console).

Pings and tracerts from the RRAS server to the remote client IP fail at the first hop. Given there is a route and the client can access internal resources, I'm struggling to understand why I can't route out to that device?

If anyone has any thoughts I'd greatly appreciate it. I can get screenshots of RRAS and routes etc if needed.
Perhaps my address pool is supposed to come from the LAN side rather than WAN side?

Many thanks
James

Answer 1

Hello @James Edmonds

If all of your LAN subnets use intermiediate hardware as their default gateway (which I assume they do), adding a static route (as you have done) to the intermiediate hardware should get traffic for the remotes to the RRAS router which would then deliver them to the remotes. Getting the return traffic to the LAN is what you may not have covered. What is the default gateway of the RRAS server? The intermiediate hardware? If not you will need static routes on the RRAS router to get the LAN subnets to the intermiediate hardware. There are two steps involved - getting the traffic from the remote client to the RRAS server, then getting it from the RRAS server to the intermiediate hardware.

If you add static routes to the clients to route the LAN subnets through the VPN tunnel, you need to use the IP address of the RRAS internal interface, not its LAN IP as the target address.

You probably also need the RRAS router configured for LAN routing, not NAT.

You can additionally use some network capture software such as Network Monitor or Packet Monitor in order to trace the connectivity:

Network Monitor:https://www.microsoft.com/en-us/download/4865
Network Monitor guide: https://learn.microsoft.com/en-us/windows/client-management/troubleshoot-tcpip-netmon
Packet Monitor: https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon

Hope this helps with your query,

-----------

--If the reply is helpful, please Upvote and Accept as answer--

Answer 2

Good morning,

Apologies for the delay in replying.

I thought it might be worth starting by sharing a rudimentary network diagram of the VPN elements as below:

Red lines are the VPN traffic, blue is LAN traffic.
The Cisco switch is acting as the gateway for our new infrastructure on the 10.0 subnet, but has a default route pointing to the Meraki firewall on 10.0.0.1.

The VPN tunnels have routes and traffic filters applied.
The device tunnel has two routes for 10.0.1.1/32 and 10.0.1.2/32, and traffic filters for 10.0.1.1 and 10.0.1.2 (Domain controllers for group policy/management etc.)
The user tunnel has two routes for 10.0.0.0/23 and 192.168.3.0/24, with remote address ranges in the traffic filter of 10.0.0.0/23 and 192.168.3.0/24

One thing I did notice, was the traffic filters on the device tunnel are single IPs rather than rages, but am sure that doesn't matter? Unless they need to be changed to /32 entries as well?

Doing a tracert from one of our domain controllers to either the device or user tunnel IP, it goes:
10. 0.0.5
10. 0.0.1
172. 16.1.6
Then continues to time out.

Given that everything knows to send the traffic for this remote client to the RRAS server, it seems to issue must be there.
The RRAS server has these three routes, so in my mind should know how to route traffic to the client:
172.16.1.10 255.255.255.255 On-link 172.16.1.10 297
172.16.1.11 255.255.255.255 172.16.1.11 172.16.1.10 42
172.16.1.12 255.255.255.255 172.16.1.12 172.16.1.10 42

I assume 172.16.1.10 is being used from the DHCP pool for some internal RRAS purpose, as it is the first IP in the pool and not assigned to either network interface.

RRAS has LAN and demand dial routing enabled.

So the issue is that, remote clients can access LAN subnets whilst on the VPN tunnels, but we cannot route from LAN subnets back out to the remote clients.
Users are actively using the VPN to access some of our internal apps and servers without issue.
I initially wondered if the routing was functioning correctly, but the client firewall was blocking connections, but pings are allowed through the firewall and SMB access doesn't work either.

I will do some packet captures on the RRAS server, but I'm a bit lost as to why once packets hit the RRAS server, they are unable to route to the clients connected to it?

Many thanks
James

Answer 3

This was somehow related to routing and traffic filters configured in the ProfileXML.

We originally had just our 2 DCs listed as /32 routes with matching traffic filters on the device tunnel, for DC connectivity/GP etc.
We then had /23 routes for our LAN on the user tunnel, with matching traffic filters.

We had this issue even when trying to reach the user tunnel IP. So, I set the device tunnel to have a /23 route and removed the traffic filter, and we are now able to connect to the device tunnel IP address.