OpenVPN up and running, now try to get Windows7 to actually use it

kejianshi

The biggest problems I've ever had with Win7 and Vista were this:

At install of openvpn, you really MUST right click the file and install as admin.

Then after that, I locate the openvpn connect icon on desktop and right click and change its compatibility to run as admin.

Then I am usually all good. If you didn't install as admin on windows, uninstall and reinstall as admin. The be sure the vpn is run as admin each time you run it. I suspect your issue will go away.

stephenw10

The pfSense DNS forwarder will listen on the OpenVPN adapter address so you can just push that, ~~192.168.19.5~~ in your case. That's what I'm doing and it works fine.
I see that your Win7 box lists the VPN adapter as TAP. Shouldn't that be TUN? :-\

Steve

Edit: Now I come to verify my settings I'm less sure. I'm pushing 192.168.20.1 for DNS on a 192.168.20.0/24 tunnel.

phil.davis

At install of openvpn, you really MUST right click the file and install as admin.

Then after that, I locate the openvpn connect icon on desktop and right click and change its compatibility to run as admin.

I use the Windows install bundle that has OpenVPN Manager included in it. It makes an install package directly from pfSense. A non-admin (or admin) user can start OpenVPN Manager and the OpenVPN connection without needing admin privs.
Of course, the initial software install needs to be run with admin privs.

kejianshi

This is EXACTLY the behavior you get when using openvpn on a windows machine that wasn't installed as admin and isn't running as admin. Thats why I mentioned it. Try using the older version of the openvpn client for windows and doing all the admin privs as I described. Other than wasting some of your time, it can't hurt anything. Also, If you have been using any other sort of vpn tech like hotspot shield or anything else like that, uninstall those first, then uninstall anything remotely associated with any sort of tunneling or vpn and only then reinstall openvpn client.

If that doesn't work, then we have absolutely for sure found out what your problem isn't…

Mr. Jingles

Thank you all for your reply ;D

(I am working my **tt off to get the laptop ready for her majesty my wife, I had to cleanly reinstall everything, which is quite a time sucking nightmare under W7 & Lenovo: the Lenovo update directory alone is 6GB …:-X).

As to using OpenVPN as administrator, I did that from the start, and I also used the Pfense created installer (in the end), as it turned out the official OpenVPN-installer kept on hanging during install (and I even used the 'hidden administrator'-account in W7 (so the 'real-real'-administrator). To no avail. Of course, the Pfsense-created openvpn-installer worked marvelously, which is no surprise, as it is FreeBSD + Pfsense-teams that do this :-*

Stephen, if I may:

The pfSense DNS forwarder will listen on the OpenVPN adapter address so you can just push that, 192.168.19.5 in your case. That's what I'm doing and it works fine.
I see that your Win7 box lists the VPN adapter as TAP. Shouldn't that be TUN? Undecided

Steve

Edit: Now I come to verify my settings I'm less sure. I'm pushing 192.168.20.1 for DNS on a 192.168.20.0/24 tunnel

You striked-through the 192.168.19.5, so does that mean if I provide the DNS-servers per Kilthro's post I can remove that complete line of 'push'?

The TAP versus TUN: you ask me ??? You are the guru ;D

This is the config file the Pfsense installer created:


dev tun
persist-tun
persist-key
cipher AES-128-CBC
tls-client
client
resolv-retry infinite
remote somebodiesgottodoit.hopto.org 45117 udp
tls-remote goaway
auth-user-pass
pkcs12 pfsense-udp-45117-goaway.p12
tls-auth pfsense-udp-45117-goaway-tls.key 1
comp-lzo
redirect-gateway def1

It says 'tun' there, but you are right: Windows 7 says 'TAP' (there is also a short cut in the start menu: TAP-Windows, in which you can create a new 'TAP' or delete all 'TAPS'). Not that I even know what TAP and TUN is; I am only trying to give my wife a relatively safe way to work when she is on the other side of the world (yesterday, I spent 2 hours in the supermarket finding 17 magnetron meals for me to cook while she is away :-X - ;D).

Could I perhaps please ask one final, but for me very important, question?

Given that the OpenVPN-connection will be on a different subnet than our own LAN, does this mean she can not connect to the normal LAN? So no connections possible from 192.168.19.x to 192.168.1.x? Because I don't want that to be possible. The reason is that I don't trust the hotels she will be staying in, and even 'though she will be using OpenVPN, if they manage to, some way or the other, sniff her uid and password (to the OpenVPN-connection), they could be able to access my private LAN, in which my NAS-ses reside, on which extremely valuable information resides (the videos and pictures of all our current and already gone dogs, to name just one). I don't want to risk any chance of a 'hacker' to get in there, and delete it, 'just for the fun of it'.

So she will be using OpenVPN only to browse the internet via a connection (our own) I trust more than the average 'free Wifi' in a hotel, and she should be blocked out of our own trusted LAN.

Given the standard OpenVPN I set up (the youtube clip), given that I have (thus) different subnets, does that mean she can not go into 192.168.1.x from her OpenVPN-192.168.19.x, or do I explicitly need to create a firewall rule for this? And if so, could I very noobish (I apologize :-[) ask for what rule I need to create then?

I once again would like to thank you all very, very, much for your help ;D

Bye,

(PS I dived into the deepness of Snort: this is an amazing tooling, I managed to block everything, everywhere, except for google.com. No idea how I did that :P).

kejianshi

If you firewall the subnet you are using in openvpn for here away from your LAN then openvpn will not allow access to your LAN. This would mean going into your LAN Firewall rules and adding one line to block anything from 192.168.19.0/24 going to LAN Subnet. Otherwise, someone would be able to ping your LAN from the VPN tunnel or even to manually enter the IP addresses of computers on your LAN to see any files, printers or other resources you may be sharing on the LAN. Make sure that block rule is above the allow rules.

Its an easy fix.

Mr. Jingles

@kejianshi:

If you firewall the subnet you are using in openvpn for here away from your LAN then openvpn will not allow access to your LAN. This would mean going into your LAN Firewall rules and adding one line to block anything from 192.168.19.0/24 going to LAN Subnet. Otherwise, someone would be able to ping your LAN from the VPN tunnel or even to manually enter the IP addresses of computers on your LAN to see any files, printers or other resources you may be sharing on the LAN. Make sure that block rule is above the allow rules.

Its an easy fix.

Thank you very much Kejianshi ;D

Could I ask if the following I just did then is what I am supposed to do? (Screenshots attached).

And, could I perhaps also ask some more noob questions:

Why is it that, when I select 'Source: Type = LAN subnet, I am not allowed to enter a CIDR-notation ??? Because the 'Address' field then is greyed-out ???' So I now selected 'Network' as a Type, so I am at least allowed to enter something, but I don't feel I understand it. I thought 'LAN-subnet' would be the place to enter a CIDR-notation.
I now added the rule to the 'LAN' tab, but should'nt I be also (or just?) be adding it to the OpenVPN-tab?
I have been struggling to move that rule to the top; it appears I first had to select all the rules and then say 'move these down'. Wouldn't it be easier to only select my new rule and tell PFS to 'move it to the top'? (Per your message that it should be the first rule in the list)?

Once again, thank you for helping me out –- very, very much ;D

PS I admit and constantly apologizing write that I am a complete noob on these matters, but I could help people with economics, my line of education. And contrary to popular - and understandable - belief, not all economists are crooks, even 'though we have a hard time to convince people of that, given the last 5 years :-\

001.jpg_thumb

Mr. Jingles

Hmm, the forum is telling me I can only post 1 attachment, since otherwise the attachments would be too big. This one was meant to be next.

002.jpg_thumb

kilthro

Honestly if you have setup your openvpn to require username/pass as well as client certificate, you should be good. I wouldn't worry about someone trying to hijack access… Without the certificate, they still will not be able to connect if they some how got the username/password which would be difficult if its encrypted. (this is how i have mine setup.) Also credentials must match certificate acct or no access will be given if someone tries a different username and password with wrong certificate installed.

If you enable the option to provide the dns list to clients it will do so and you can remove that line in the additional settings.
I see that you have route all traffic through vpn enabled. I know in the past I have seen people having trouble accessing other networks/sub nets behind the firewall with that on as it blocks them from accessing them. I know I don't have that enabled but I have this added in advanced settings.
push "redirect-gateway def1"
This way i know all traffic is routed through vpn and I still still have access to the computers behind the firewall for remote desktop etc.

I also enabled the option to make my other networks available to vpn clients. I didn't have to push them in the advanced settings. If none of that is enabled, (advanced settings or make networks available option) then they should be locked into the virtual network of the vpn. I am not 100% on that haven't tested but that's how it should work.

I also did not mess with any firewall rules. You could set up rules to block the vpn subnet access to certain ips if you wanted to so you don't have to worry about gaining access to certain systems if you are worried.

Again, I am no expert, just speaking from my experiences with it.

Mr. Jingles

Ah, and this I also had to add: while testing OpenVPN at my friend's house, the Windows 7 firewall reported these blockings from the OpenVPN-IP (192.168.19.x), which I really don't understand why (as it was in 'learning mode') ???

huh.jpg_thumb

kejianshi

When you select LAN subnet, the 192.168.1.0/24 is implyed since that is the subnet for the LAN. Basically, its automatically doing what you did manually. Either way should work fine, but selecting LAN subnet seems less fuss and sure fire to me. VERY important here (I think). I would go back into that rule and select "interface - openvpn" not LAN since this rule needs to match for traffic on the openvpn interface. That should move the rule over to the openvpn tab.

Another user noted that you can enable or disable access to network from inside openvpn server config.
I always enable it and then set up firewall rules to allow and disallow what I want, but to disallow everything to local network his suggestion should also work although I've not tested it.

kejianshi

Windows firewalls… Yuck.
Looks like its blocking DNS - fabulous.
I would allow openvpn in windows firewall or allow 192.168.119.0/24.
Windows firewall is a blunt instrument.

Mr. Jingles

Thank you again for your help :P

I've made the changes recommended here, and it appears to be working correctly now (although PFS didn't remember the block rule for my local LAN, which I added to the OpenVPN-rules in the firewall; very strange, I had to enter the rule 4 times ???).

Well, it has to be working anyway, since her majesty has left the house and is on her way to the airport, so I can't do anything about it anymore right now. And I am on my way to the kitchen, to learn how to prepare food for myself :D

Thank you again for your help ;D

(And yes, Windows firewall = yuck. As is Windows. But she wouldn't allow me to put PC-BSD on the laptop :-).