You may export certificates using the certificate manager in System menu and import them on the other box at same way.

For future readers, when some devices are reachable on a remote subnet across VPN but others are not, the common problems are:

The target device has its own Firewall. Often that firewall might allow access by another device directly on the subnet, but not from a remote subnet. Prime offender - Windows ****. Turn off firewall.

The target device does not have a (correct) gateway set. In that case it can answer directly on its LAN but not to anything off the LAN.

The target device has the wrong subnet mask - causing it to think the wrong range of IP addresses are local, or to not be able to reach the gateway or…

The target device is a really stupid print server or whatever that has nowhere in the firmware to even enter a gateway IP. First choice - ditch it. Second choice - NAT out onto that remote LAN so the traffic from the subnet/s on the other end of the tunnel looks like it comes from the local pfSense LAN IP.

@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!

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