My guess is that you didn't install the openvpn client package in windows as admin. When you install the package, you have to right click, run as admin and accept all the following dialogue boxes. I also make a habit of right click and running the openvpn gui as admin even after install, but its not required. If you are not sure that you installed as admin, please uninstall openvpn completely and and then reinstall with the right - click run as admin. I also use TUN usually and not TAP so much.  If you have other VPN solutions installed along side openvpn, those can also cause issue. (windows firewall or any firewall can also break things - Might want to deactivate those during troubleshooting)

Just wanted to post a follow-up. Not sure why, but this config (NAT through the LAN address with the posted config) is working properly today. Thanks for the replies!

Good news. It's working! It's just our one site that's not connecting properly, and of course that was the one I was using for testing. Great guides posted by everybody.

all errors resolved.. thanks all

@phil.davis: What pfSense version? OpenVPN server or client bound to a gateway group should fail-over and fail-back on pfSense 2.1 pfsense version 2.0.3-RELEASE (amd64) OpenVPN client running in pfsense. Failover works well, no problems. When the failed WAN interface comes back online, traffic is still routed through secondary OPT1 and does not switch back to faster WAN. I should switch to 2.1?

What you want in the client config is: redirect-gateway def1

Thx, I'll give it a shot later today… I think he won't release his "Intranator" 800€ hardware box! But yeah that would definitly make things much easier... Greetz Mircsicz

Apologies for the slow reply, I've been on site all day today. @phil.davis: I'm impressed - quickly changed all that network stuff and got it to work again in a reasonable time! The network design looks good. Thanks. Despite the "noob" questions I do actually understand most of the technology and I'm pretty handy . What isn't so clear is the pretty dire explanations of things at times. It's all perfectly fine if you need/want an identical setup but useless to understand whats really going on under the hood. However I digress ;) Ok. We have progress. I'm not quite sure why it's working but it is. I did make a tweak to the rule last night which off hand I can't remember now so it might have been that. I now have to figure out why I still can't access the console of my VMware VM's due to the "MKS" error. I expected that to go away as I'm technically on the same LAN as it but seemingly not :( Thanks once again G

Giving this a little more thought, I checked the log files for my OpenVPN client on Android, just to be sure that it wasn't an issue with the config file being exported form PFsense.  Its not. Using PFsense, the DNS is being pushed just fine using Openvpn Connect, so the PFsense end is working fine. It really must be your Android Client's issue.

The OpenVPN client settings GUI page, Advanced Options box - that can take anything that is valid to add to an OpenVPN conf file - like route-nopull Just type it without quotes - it will be appended directly to the client conf file.

Well….I got it. I started poking around the routing tables after the last msg.  I needed to put a static route to the DMZ using the openvpn IP as the gateway.  Once I did that and added the vendor static routes that exist on the primary firewall to the remote firewall it all worked. Thanks marvosa for pushing me in the right direction.

The binaries for the 64-bit OpenVPN client are there, but hidden in the GUI, because the last time I tried them, they did not function correctly. It produced a broken installation. It could be the config bundling parts to blame, but I'm not sure. Using the 32-bit OpenVPN client on 64-bit Windows is fine, as others have pointed out. Probably not a huge difference either way, but if you really want to, you could install the 32-bit client + config, then uninstall it, and then download and install the 64-bit community client from OpenVPN. That way your config would be in place already. Or just install the 64-bit client and copy an exported inline config into the config dir and do it that way. More manual, but less uninstall/reinstall song and dance.

I wouldn't need to fly there.  I can take a walk there…  Or ride a bicycle.  But the Metro is quicker. Now, the real question is why the heck would I want to spend more time there than absolutely necessary? I do like Dupont Circle from time to time, but its hardly Gangnam.  DC is boring. (I was being FORCED to parade around museums AGAIN by yet ANOTHER visiting friend or I wouldn't have been there.) It just hit me when I checked my logs to compare notes with Honeybadger that the only time I've seen that error I was in DC. If someone did manage to overheat a mainframe and chew through that particular VPN they would be rewarded with a tunnel that just goes back to the internet and no where else.  Quite an accomplishment. I will be turning it on again next time I go to see if it happens again though.

Odd thing is that with an IPsec tunnel, the asymmetry is reversed, faster when the client is on my side of the house.

That is correct I didn't use the wizard to make the site to site. I will do some further testing to make sure there is leakage of ports. For the record I'm not saying that PfSense is leaky I'm just noting that in my situation I was getting flakey connection with my remote site. If I didn't have the port opened up I would expect no connection. I will document the steps if anyone wants to try to duplicate the steps.

I have resolved this now! I have my pfSsense running on an ESXI host. I was messing around with the vsphere switches last night and disabled promiscuous mode for the Firewall switch - this was causing it to not allow certain traffic through!

Hi Guy's, I'm having similar issues with pfsense 2.0.3. I'm using the OpenVPN Client software to setup a remote connection to my pfsense box and the VPN connection itself is up, some routes are being pushed to my client and I can ping the IP-address of the pfsense box itself. But all traffic going through the VPN to the internal systems (like RDP, ICMP etc.) are not passing through. When doing a Wireshark on the RDP-server and tcpdump on the pfsense box I see that the traffic is coming in via the VPN to the firewall, but not going out of the firewall to the RDP-server. Wireshark is not showing any incoming packets from the VPN client. So it seems that there maybe is a routing issue or that all VPN traffic is beeing blocked somehow. What I found out is that when configuring a clean pfsense 2.0.3 box the VPN connection is working and traffic is passing through to my RDP-server. But after rebooting the pfsense box, it does not work anymore. So something changes after rebooting the box. To answer on Kejianshi, i'm using automatic Outbound NAT Rule generation Regards, Cedric.

There is a limit of a couple of days for editing posts. So you can only do what you have already done - add an entry indicating the problem is solved.