you can push your WINS-Servers IP to the Roadwarrior using the DHCP-Options. These Options can be configured in the pfsense GUI /VPN/OpenVPN/OpenVPN: Server (Edit your OpenVPN-Server config)/custom options. We use:
push "dhcp-option DNS xxx.xxx.xxx.xxx"; push "dhcp-option WINS xxx.xxx.xxx.xxx";
The first option is for pushing the DNS-Servers IP, the second Option is for pushing the WINS-Servers IP to the client. Exchange xxx.xxx.xxx.xxx with the IP-Address of your DNS- or WINS-Server. You may push other DHCP-Options as well. Seperate the options with ;
Hopefully this will improve network browsing for you.
Hi, Thanks for that. I put in the various settings and was able to pick up the WINS server through my OpenVPN connection. (see below), but for some reason, the neighborhood of computers still does not appear (only the client machine). I'm a bit puzzled by this. Would the fact that OpenVPN requires that you assign a separate subnet to your LAN be part of the problem? As far as I know, this should work unless I need a rule for some sort of broadcast stuff…
Anyhow, it's not a big deal because I can still access network shares through OpenVPN. I just need to know the name of the computer that I want.
I tried it out with the box hosting the VPNs for us and it works great for just checking to see if the box is up and rebooting if not. We just tested it running it and unplugging the WAN. On the WRAP I tried this on though, the /var/db/hosts file was cleared on reboot. I made something in /usr/local/etc/rc.d recreate it though.
The only problem is that I guess I have the syntax right. For just checking up and down, it works fine though.
Here's the error I get:
PING 184.108.40.206 (220.127.116.11) from 192.168.75.7: 56 data bytes
64 bytes from 18.104.22.168: icmp_seq=0 ttl=247 time=16.167 ms
64 bytes from 22.214.171.124: icmp_seq=1 ttl=247 time=15.761 ms
64 bytes from 126.96.36.199: icmp_seq=2 ttl=247 time=16.309 ms
64 bytes from 188.8.131.52: icmp_seq=3 ttl=247 time=18.847 ms
64 bytes from 184.108.40.206: icmp_seq=4 ttl=247 time=25.969 ms
64 bytes from 220.127.116.11: icmp_seq=5 ttl=247 time=26.756 ms
64 bytes from 18.104.22.168: icmp_seq=6 ttl=247 time=14.858 ms
64 bytes from 22.214.171.124: icmp_seq=7 ttl=247 time=23.865 ms
64 bytes from 126.96.36.199: icmp_seq=8 ttl=247 time=14.006 ms
64 bytes from 188.8.131.52: icmp_seq=9 ttl=247 time=14.264 ms
–- 184.108.40.206 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.006/18.680/26.756/4.708 ms
Checking ping time 220.127.116.11
Ping returned 0
[: 18.664: bad number
Checking wan ping time nan
[: nan: bad number
but yeah, that script is hella useful for OpenVPN tunnels. Maybe it'll fix the tunnel dying problem we're having
Hi, tnx for the quick answer, i've just tried to set openvpn
with the remote subnet as you say, but the problem remain.
Still no routing… probably i'm missing some settings on the openvpn server to route traffic of the openvpn tunnel through the ipsec tunnel.
I'll investigate a little more (or could give a try to pptp :-\ )
Yes, I know that with the actual config only local office (192.168.200.0/24) can access through every other subnet, but for now is what we want. Do you think this could be a problem for the mobile user?
tnx for your help
PS: does anyone know if it's possible do configure openvpn client with username/password?
pfSense provides a wonderful implementation of OpenVPN. There are still some kinks to be ironed out, namely the firewall rules for the OpenVPN interface, but they will get it working. Regardless, it works anyway with some manual steps.
I recommend that you go to www.openvpn.net and read-up on OpenVPN before jumping into it. It is a very powerful and versatile package and along with that comes a bit of a learning curve.
Jan 19 09:49:40 openvpn: WARNING: 'ifconfig' is used inconsistently, local='ifconfig 10.0.10.1 10.0.10.2', remote='ifconfig 10.0.200.1 10.0.200.2'
Your address pool must be the same in both client and server.
Thanks a lot for your reply. The problem is fixed now.
But I still have problem in accessing the remote network. I can ping 10.0.200.253 in the firewall (10.0.100.254) but I can't ping 10.0.200.253 in my lan (10.0.100.0/24). Is there anything I missed in the setting? Thanks a lot.
There IS a way to directly configure OpenVPN firewall rules, but it's not widely known nor talked about. It's through the LAN interface.
Make a firewall rule on the LAN interface that is specific to this particular situation and put it on top. See if that helps.
Most likely because that only handles one side of the conversation. We do not talk about it because its not a real fix.
Unless you control both ends of the tunnel you will feel secure but the oppisite is true. Therefore we simply say there is no firewall rules possible on 1.0 across OpenVpn and IPSEC tunnels, but, we are working on this.
Gotcha. So this is why anyone in the remote network can access anything in the local network (pfSense-side if we're assuming it's the server) provided the routes are set up correctly on the client-side.
I was racking my brain trying to figure out why I could get traffic IN through the tun0 interface, but I couldn't get OUT unless I was using the pfSense box itself. At first I thought it was a route issue, but then realized that the firewall was locking it down. Setting up explicit rules permitting traffic from any source to destination OPVN interface and destination OPVN remote network did the trick.
I haven't used openvpn yet but I have several locations running ipsectunnels. Biggest network consists of 12 locations that are all connected to each other through the mainoffice (only location that has a static IP) which acts as vpn concentrator. This setup is only using pfSense's everywhere.
I also have another setup where a pfSense CARP cluster has VPN connections to a cisco pix, another pfSense and a sonicwall. Everything works smooth :-) For some examples how to configure the non pfSense systems see http://doc.m0n0.ch/handbook-single/#Example.VPN .
Before you start to set this up you need to do some subnetcalculations. If you use IPSEC for that and need the remote locations to talk to each other through the central location you need to use some bigger subnetmasks at the central unit.
the site 2 site is very simple to set up (with the pdf document)…. but is it also possible to connect 3 pfsense client machines to one openvpnserver-pfsensemachine and routed the networks behind the 3 pfsense machines......(i don't want to open to much external (firewall) ports
billm, I hope you're wrong about this. Here's why:
I have a client that needed some serious entropy available to an application. We purchased a hifn card to supplement /dev/random. FreeBSD does not create /dev/hwrandom, and from all appearances, speed of the customer's application went waaay up, and the deployment passed some certification process that I was not involved in. So….hmm.
Interesting stuff. Perhaps I should dig into this further? BTW, another option if I recall correctly would be to insert a sound card, get the driver working, get the block device for the mic-in, then take and have that constantly dumping to /dev/random too. (don't hold me to that, never personally tried it!)
Your not going to like to hear this but I went with IPSEC vpn's instead. The interface is much more reliable and pfsense's implementation will allow you to configure the server as a remote client portal. All the pfsense clients connect as if they were a site to site and it takes care of all routes beautifully. It doesnt matter if they are dynamic or static ip's with this conifig also. I will keep checking with OVPN and hopefully they will have all the kinks worked out soon.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.