pfSense+ / OpenVPN / Windows Remote Desktop

I created a VPN using Tom’s tutorial. I’m thinking I must have missed something. If I’m on the network here in the office, I can connect to the RDP machine just fine. However, when I’m logged into the VPN, despite my ability to ping the RDP machine, Remote Desktop is not finding that machine.

What have I overlooked?

Sure check you have allowed the subnet and rdp port in your firewall rules.

Check the Windows firewall rules to make sure it will allow non-local subnet access. Or just turn off Windows Firewall and see if that fixes it.

I turned off Windows firewall but still the problem persists.
@neogrid Is this right?

Actually someone else had the same problem in the past take a look at this posting Need to access files on PC using pfsense OpenVPN w/o modifying Windows Firewall

Your firewall rules are for TCP traffic only. Set them for both TCP and UDP and see if you can connect.

1 Like

Sadly… no dice. I’m just completely lost as to why this isn’t working. Also, to make clear for reference, the Windows firewall on the target machine is completely disabled.

Try NoMachine over the VPN it will connect your mgt station to the remote Win box and you can use ssh for a more secure login.

Sorry, not sure what your experience level is so…hopefully my rambling helps:

I had issues myself…but make sure the OpenVPN is setup correctly. I will include some screenshots that I know I had wrong so hope this helps. Make sure the tunnel network and the local networks are setup correctly (I had those wrong). Make sure the exact network is listed and if you just want to get access to a particular machine for RDP, I included that setup there for you too. (/24 is the network, /32 is the endpoint device, computer?)

Also I see what looks like a port forward in there. Not sure why you need that? if you want to use the VPN you won’t need the port forward on the WAN. I know we used a port forward before implementing the OpenVPN and disabled (removed) that once the VPN was up and running. To use the port forward outside the network, you need to use the IP of your WAN with a port for example: then it would forward to the machine using 3389.

the rules on the OpenVPN is not needed for the port forward. but if you really wanted that, I would move the rule above the Any/Any rule for the OpenVPN. But I don’t see where it is needed.

Once inside the network (connected via OpenVPN), all you need to do is use the ip of your internal network. for example: 192.168.xx.xx



WAN firewall Rules:

OpenVPN firewall rules

I have a site to site set up between two pfsense and oVPN, I don’t have issues RDP into any of my computers from either end. How are you connecting to the VPN, site to site or workstation to server?

Your WAN rules should no long apply since you are coming in on the VPN and everything is encrypted, the WAN doesn’t know what is happening, so that shouldn’t be it.

The any:any rules on the VPN should be enough to let you through.

Thanks Greg!

I’m connecting workstation to server I suppose. I followed Tom’s youtube tutorial which has you set up the VPN in pfSense, then use the client export utility to spit out an executable, preconfigured, to install on the client machine. I am able to connect to the VPN without issue. I can even access the pfSense GUI through the VPN. It’s strictly remote desktop which isn’t working.

It would seem like the RDP is trying to use the “normal” network connection, not the VPN so it may be a workstation issue. Since I haven’t set up this type of oVPN, I’m out of ideas for right now. I’d check on the allowed networks to make sure your remote network is listed.

Also try RDP to the IP of the device you want to connect with, maybe it is a DNS issue. I might have had to set my home workstation to use DNS from my work domain controller to get it to work, been a couple of years since I needed to work from home this much and I’ve forgotten some of the details, worth a try anyway. DNS was assigned in the network settings for that NIC.

1 Like

This somewhat mirrors my immediate impression. How is your RDP session set up, by name or by address? If by name, there are a number of settings that may be effecting proper name resolution. These are all in the Advanced Client Settings area of the OpenVPN configuration and include things like setting a default domain name to match the remote network, providing the correct DNS address for the remote network, blocking external DNS specifically for Windows clients, and running a script to stop / start the DNS cache, flush it, and register the remote dns domain.
If your local machine is a Mac, none of those will apply, but they also won’t hurt the Mac users if you have a mixed environment.
Alternatively, you could set up local DNS to properly resolve the computer name, or you could change your RDP session to connect via IP rather than by name. That might be easier if this is just for you. If you are doing this for multiple users, getting the DNS settings correctly configured would be a better choice.

@Greg_E @jvedman I didn’t know there were multiple ways to setup RDP. I’ve never really used it before but I wanted a way to access my Quickbooks Desktop from home, and as I learned in a previous post here, opening a database connection through VPN is a bad idea and so RDP should be used.

My Quickbooks machine is named “FRONT-OFFICE”. I can open RDC from any windows machine on the same lan and access it by entering that name. I did not however think to try accessing this machine remotely via ip. This is strictly for me to use so if the ip option works, problem solved. I’ll try this later today and report back here with my findings. Thanks!

IT WORKS!!! It works with the IP address. Thank you SO much! What a noob I am.

1 Like

OK, so now you can dive deeper and set up the DNS options above to get this working through names. It’s all in the learning and something I will need to look into as well.

I did find that from work I can RDP into machines with just the machine name (ex. EWS6020) but from home I had to add the domain name (ex. EWS6020.“mylan”.local) to make it work. I had saved shortcuts to each computer at work and had to go back and edit those when I was working from home (about 60 shortcuts for me).

Yay! So glad you got that working. You have taken your first step into a larger world. :wink:
Now, if you haven’t already, go undo the special firewall rules you made to allow that traffic. The default OpenVPN rules should allow all traffic from the tunnel to the main network so you shouldn’t need anything special there, and having RDP open on the WAN port is VERY dangerous, even if you are using non-standard ports.

Just to back that up, I have attacks daily for RDP against one of the ports I have open for a service. Suricata blocks them, but just know that they are out there trying everything against any port that can be found.

@jvedman @Greg_E
Thanks for the heads up! So I removed the RDP rule on my WAN tab. What exactly else gets removed?

I have no idea why this is with me… I can fix computers all day long. I locate faults on motherboards and repair them and I can get a network up and running with pfSense but I can’t understand firewall rules to save my life. I have always struggled with firewall rules. Maybe it’s the UI and my ADHD mind. Maybe I should just make all rules floating and see if I can better conceptualize what I’m doing.

I totally get that. It took me a while to really grok how firewall rules work (and I still often find mistakes I’ve made, especially in edge cases). The basics really come down to a few concepts that aren’t hard to understand, but aren’t necessarily intuitive either:

  1. The rule will only work at the first interface to see the traffic, so rules to pass or block traffic from the WAN need to be on the WAN interface, but rules to block or pass traffic from VLAN A to VLAN B need to be on the VLAN A interface.
  2. Rules are generally interpreted in order (with a slight variation on NAT rules, because those are actually a set of two rules, a pass rule for the traffic and a re-write rule for the NAT in between interfaces).
  3. Rule evaluation continues until it finds a definitive pass or block rule for the traffic so, as an example, my rules blocking all traffic from outside US/NA are at the top, rules allowing traffic from specific aliases are in the middle, and rules blocking everything else go at the end. That seems simple, but you can do some pretty complex things with blocking and re-direction once you understand rule precedence.
  4. Rule construction is generally easier than it appears, especially with pfSense and the ease of creating aliases. The keys to rule construction are:
    a) make sure you have the right protocol. For instance most traffic is TCP and / or UDP, but if you want ping to respond that is IGMP.
    b) for pass rules whenever possible or reasonable, try to limit to the smallest IP pool possible. For a website / service that people really will be accessing from anywhere, that might not be possible, so Any might be your only choice
    c) source ports will almost always be Any since there are almost no services that use the static source ports
    d) for destination (and source when appropriate, such as between VLANs) pay attention to the difference between address (the actual adapter) and net (the subnet the adapter lives on)
    e) Always give your rules a meaningful description so that 2 years from now you can tell why you put it there (trust me, you are less likely to remember than you think)
    f) There is a lot of cool stuff you can do in the Advanced Options, but unless you know need them, leave them alone.

I’m wondering if anyone else wants to add to or correct this set of basic concepts. Please feel free. I am always happy to learn and relearn!