@JMullen: FIXED I'm not sure what exactly this does but I added it to the OpenVPN Server settings and I'm now able to hit all devices on the LAN from the VPN connection! :) Maybe this will help someone else! [image: Screenshot_2015_01_31_at_00_47_40.png] push "route 192.168.1.0 255.255.255.0" push "route 192.168.2.0 255.255.255.0" push "redirect-gateway def1" You really should just put: 192.168.1.0/24,192.168.2.0/24 In the Remote Network/s field of the OpenVPN server settings. Then it does all that push route stuff for you. And I suggest you change your LAN/s to some other private subnet/s that are not so common - your OpenVPN road-warrior users will have trouble when they are at home with their default SOHO device that already has 192.168.1.0/24 LAN.

More information.  Here is the server side config file: dev ovpns1 dev-type tun tun-ipv6 dev-node /dev/tun1 writepid /var/run/openvpn_server1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-128-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown client-connect /usr/local/sbin/openvpn.attributes.sh client-disconnect /usr/local/sbin/openvpn.attributes.sh local xxx.xxx.xxx.xxx tls-server server 10.0.2.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc username-as-common-name auth-user-pass-verify /var/etc/openvpn/server1.php via-env tls-verify /var/etc/openvpn/server1.tls-verify.php lport 1194 management /var/etc/openvpn/server1.sock unix max-clients 5 push "route 192.168.1.0 255.255.255.0" push "dhcp-option DNS 192.168.1.1" push "dhcp-option NTP 192.168.1.1" push "redirect-gateway def1" client-to-client duplicate-cn ca /var/etc/openvpn/server1.ca cert /var/etc/openvpn/server1.cert key /var/etc/openvpn/server1.key dh /etc/dh-parameters.1024 tls-auth /var/etc/openvpn/server1.tls-auth 0 comp-lzo persist-remote-ip float And the client side for the OpenVPN Windows program: dev tun persist-tun persist-key cipher AES-128-CBC auth SHA1 tls-client client resolv-retry infinite remote xxx.xxx.xxx.xxx 1194 udp lport 0 verify-x509-name "CarsonOpenVPNServerCert" name auth-user-pass pkcs12 pfsense-udp-1194-mcarson75.p12 tls-auth pfsense-udp-1194-mcarson75-tls.key 1 ns-cert-type server comp-lzo Thanks, -Matt

Correct and NSA didn't like blowfish….  haha Thats my whole point.

That worked. Thanks a ton.

Strange is, that in a v2.1.5 installation still in use, time is correct.

Seriously - TCP on port 443 to a box that only one or two people use and you will get through. Trust me.  Mine is working fine (-; When you connect, do use IP - Not DNS.  DNS poisoning is how they shut most down or by blocking DNS to certain sites. (Now - I suppose that if you try to pipe 1/2 a gigabit on that you might get caught but if you keep the traffic reasonable, they got no time for you)

Thank you guys !!! Of course simple thing :) All my clients (servers, desktops) have different gateway because I'm buiding pfsense host next to my main UTM. Of course when I changed gateways IP address I can get now that server. And of course pinging is not working in some servers because host interprets vpn client as they coming from privat network. Some firewall rules must be changed. Thanks again.

I can't wait for OpenSSL to go away. Software should never implement its own rng and should always get rng from the OS. That being said, I trust Intel's RNG more than OpenSSL's crazy fall through logic that can sometimes source "random" data directly from your raw secret keys. Or at least it has in the recent past.

@Derelict: Don't see any such thing ever.  Are you sure it's not lovely comcast doing shenanigans with a long-established session? I suspect this is the most likely scenario. It hasn't happened in a while now at least.

That all depends on your config, routing and full tunnel vs split tunnel.  We are all just speculating without looking at the config and your routing tables.

kejianshi: Thanks alot for your tips! I have solved the problem! Now I'm running the VPN Server using UDP on a high port (51750), and disabled the option to redirect all the traffic through the gateway. And I have also changed the topology(of the VPN tunnel) from subnet30 to /24. Now I can connect using Android Phone, Android Tablet and Windows PC and acess all resources from the destination network, even if all the devices are using the same shared internet connection. Thank you! :)

You know what.  I think a lot of people get strange errors at that point.  Not really an error but OpenVPN trying to do something that's already been done or something.

Thank you sirs! Confirmed -win6 variants work perfectly without changes required to win8 services options as mentioned in many early release tutorials. Cheers

When using a more powerful machine as VPN client I'M able to saturate the 100mbit link. Sftp to pfsense over openvpn maxes out at 20 mbit Any thoughts? Edit: the link between both sites has a pretty low latency btw (+- 10 ms)

As a practical matter, I would also change that LAN 192.168.1.0/24 in the middle to some other more obscure private address space. That will help avoid problems for your Road Warriors when they are sitting in their local cafe and the cafe WiFi hotspot is also 192.168.1.0/24

I guess you are using policy-routing rules on your LAN, to direct traffic to WAN1 and WAN2 according to your failover and load-balancing needs. In that case, you need to have a rule on LAN that matches source LANnet, destination OpenVPN tunnel subnet (10.0.8.0/24), gateway none. That will allow the traffic returning from LAN to the OpenVPN client to be passed normally to the routing table, which knows how to route it to across the OpenVPN tunnel to the client. Without that, the traffic can be forced out WAN1 or WAN2 by a policy-routing rule, and of course never reaches the OpenVPN client.