Problems remoting in Win Server 2019 through OpenVPN

Question

Today I have set up a VPN using a Raspberry-pi and OpenVPN. The VPN is now connected from both my Windows 10 laptop and my Android mobile phone, not without pain.

I need to remote into my home server but I am stumbling into what seems to be a routing problem.

• My target network is a private IPv4 network 192.168.144.0/24
  • I need to access 192.168.144.11 (Windows Server 2019)
  • HP iLO firmware address is 192.168.144.28, keep this in mind
  • Raspy is 192.168.144.13
  • Main gateway is 192.168.144.1
• I have set up routing tables at the gateway
  • 172.16.0.0/16 routed via raspberry
  • 192.168.0.0/24 routed via raspberry who owns a permanent VPN link to another site. This is out of the scope of the question

With my laptop, I present myself as 172.16.46.10 and the raspberry routes my traffic to its eth0 interface.

I could verify that I can access the https interface for the iLO server. For those who don't know, a lot of HP (micro) servers come with a firmware agent providing a lot of features (including remote console and ability to push the power button) from a web interface.

Since I can access iLO and power the microserver on, I have determined that most of my routing is correct.

However, I still can't remote using rdp.

I have tried the following to investigate:

• RDP fails to connect
• ping 191.168.144.11 from remote laptop, no response
• tracert the same address hits only the 172.16.46.1 VPN gateway, without going further
• ping 172.16.46.10 from the Windows Server machine works. I can ping back my laptop
• ping 192.168.144.28, which is iLO, works
• tracert the above hits the server with 2 hops
• http://192.168.144.1 loads an HTML forbidden page, which is correct because I am trying to hit the home router with a foreign address
• And of course https://192.168.144.28 works like a charm. I can login into the server via serial console and issue commands here (see #4)
• SMBing \\192.168.144.11 does not work from remote laptop

Judging from the various tests, this looks like to me a like a pure routing or firewalling problem.

Answer 1

While I was writing the question, I finally found the answer myself.

I needed to add a static route to Windows Server, don't ask me why

route add -p 172.16.0.0 mask 255.255.0.0 192.168.144.13

Once the route was OK I could do everything with the server. I'll try to understand it better later