RDP Teams access

Zero Trust Access
1

I’m about to set up remote access through WARP client and Teams. Web sites work perfectly, but I have difficulties with any more complex protocol - RDP, SMB, SQL.

Docs says it requires cloudflared access redirection to make it work.

  1. Seems this deamon is not included in the WARP client, so I have to install it to all end users (BYOD) devices manually. Not doable for “quick access”.
  2. I’d like to give access to approx 20 resources. While it was pretty easy to remember app.domain.local or build.domain.local is it very impractical use localhost:1233 and localhost:1234.
  3. Change in the infrastructure (eg. adding a resource) will require to distribute updated “routing batch file” to all users.
  4. for some servers I’d like to use several services (eg. HTTPS, RDP and SMB), but seems that I have to define 3 different DNS records to be able to configure ingress rules

Are there some nice solutions to some of these awkward design tasks?

2

You could use Warp to Tunnel instead:

2 Likes
3

@cscharff This looks promising, but I am unable to get it working.
There is no log option at WARP client side, the cloudflared tunnel doesn’t log anything neither.
The tunnel has:

warp-routing:
  enabled: true

tunnel route ip show returns correct subnet map

route print -4 on my Windows client doesn’t show that remote subnet (which might be correct).
I’ve also tried to create a Network policy to allow all traffic, but no luck.
Can one tunnel serve both WARP routing and ingresses?

4

From what I know, yes.

You sure to have followed all steps in the guide @cscharff linked?

5

I think I did:

  • Tunnel is working for HTTP/RDP ingresses
  • WARP client is successfully authenticated with Teams
  • Route of the requested subnet is linked to correct tunnel
  • Proxy enabled, no split tunnels

To access remote servers I am using IP addresses. Not sure whether is valid to have DNS records pointing to a private address.

6

For hostnames I first used override DNS policies to push the hostnames to the local machines. This didn’t quite solve my need to do proper internal DNS server resolution to support an AD domain. For this I setup a split tunnel by domain entry (at bottom) alongside all other IP routes.

image
image390×811 13.4 KB

and added a Local Domain Fallback entry which included my internal domain and my internal DNS server in the address field. (make sure this list doesn’t include another entry that overlaps your existing domain - i.e. if your AD domain is blah.local, remove the .local entry)

image

For SMB, make sure you turn on UDP under Settings → Network → Firewall and make sure you have the latest WARP client. UDP is new.

You also need to use quic protocol in your cloudflared config

tunnel: yourTunnel
credentials-file: /root/.cloudflared/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.json
protocol: quic

warp-routing:
  enabled: true

All this being said however, out of our 43 concurrent connected users, we are having all sorts of DNS issues a the moment. This morning, random 6 users couldn’t resolve the hostnames (short name or full fqdn) despite the warp client being connected. (tested using dig) Restarting the Warp client service seemed to solve it - however its not immediate. The delay is noticeable - around 30 seconds after the client is reconnected, dig finally works).

I know its something with DNS since \\10.0.0.10\share works fine, but the hostname/fqdn does not.

7

Thanks a lot! I did reset Split tunnels setting and it magically started to work!
And added quic and UDP protocol - but I am not sure whether this is needed for HTTP routing.

8

quic is not needed for http routing. It’s needed for UDP connections

9

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.