I can confirm the problem is fixed. The connection was successfully tested with remote clients with windows 7 and 8 and openVPN gui version 2.3

Try looking at the following, found by random Google searching: http://forums.freebsd.org/archive/index.php/t-26035.html http://www.linuxquestions.org/questions/linux-newbie-8/error-pem-routines-pem_read_bio-no-start-line-pem_lib-c-644-expecting-trusted-certif-654698/ http://forums.freebsd.org/showthread.php?t=26035 http://www.question-defense.com/2009/07/08/litespeed-ssl-error-error0906d06cpem-routinespem_read_biono-start-line http://stackoverflow.com/questions/3617293/openssl-pkey-get-public-not-open-public-key-no-start-line-error

I ended up using an OPT interface in pfsense and giving it a seperate subnet from my lan.  Just setup a rule in opt interface firewall rules  to allow traffic from the opt subnet through the openvpn gateway. I should also add that i'm using two nics on the machine i'm routing through the vpn.  I also use forcebindip to force binding applications i want to to the nic connected to the opt interface.

I am trying to do the same as you and it works as expected if the VPN is up.. However if the VPN is down or you disable the service it seems to route through the default gateway regardless of rules. Do you see this as well?

Jimp to the rescue! Thank you, that was it. I did not check it because computers were connecting fine. Best regards Kostas

Use Diagnostics->Routes to see what routes are on each pfSense. If you have the local network and emote network in the OpenVPN config correctly, then there should be routes on each box to the opposite LAN. And yes, the WAN of each pfSense should be fine pointing to your D-Link router 192.168.0.1 - in your test environment, 192.168.0.0/24 is playing the role of the real internet.

@johnpoz: So your fully working and functional now, even to your window boxes, which I take it were running firewalls blocking the traffic you wanted to allow. So you get your browselist working, or live without that MS nonsense ;) As you said (without that MS nonsense)…thank you man your a hero .

Need more specifics to troubleshoot. Which guide did you follow to set up the tunnel? Post your Server openvpn config Post your client openvpn config (site b) And I have to ask… but is there a PFsense box on both ends? Post screen shots of firewall rules on both ends on the openvpn tab

I figured out the answer to my problem. I needed to add a route to the gateway at B for the subnet IP's being assigned the the vpn users

The OpenVPN Forum thread is: Involvement of FOX-IT in OpenVPN https://forums.openvpn.net/topic10180.html I saw it in a Wilders Security Forum thread: Involvement of FOX-IT in OpenVPN https://www.wilderssecurity.com/showthread.php?p=2196713 The Wikipedia page on FOX-IT: http://en.wikipedia.org/wiki/Fox-IT Edit: The AirVPN forum admin just said this: Basically the statements by Sommerseth hold and Yonan's analysis, as well as the OpenVPN community work and the peer-review of OpenVPN after 4 months from that thread, show that there's no such vulnerability neither on OpenVPN 2.2.x nor on OpenVPN 2.3.0. Additionally, Palatinux team members have proved unable to support their claims, even after a clear invitation to do so by Bakker from PolarSSL (see his message on the very same thread). Unless Palatinux provides evidence of their claims (and in 4 months they failed to do so), all the stuff is just an attempt to inject FUD (Fear, Uncertainty and Doubt) for purposes we are not willing to comment. https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=8070&Itemid=142

It might be bad form to answer your own question but I wanted ensure that this thread has closure. I found the solution. I had to manually create an interface for VPN (OPT1) and bridge it to the LAN interface. I had assumed that the wizard & settings would have done this automagically like it is on other firmwares.

This worked like a charm, Thanks!  It makes a lot more sense now. Have a good one.

While connecting through ubuntu client system following error occured NOTE: unable to redirect default gateway – Cannot read current default gateway from system Is it causing the issue.Can any one help me.........

On OpenVPN Server you set the tunnel network. for example 10.10.10.0/24 10.10.10.0/30 is the OpenVPN Server itself 10.10.10.4/30 is the first OpenVPN client which connects 10.10.10.8/30 is the second OpenVPN client which connects …. 10.10.10.252/30 is the 63rd OpenVPN client which connects. In short: Every client connection on OpenVPN needs a subnet of /30 First IP: Network IP Second IP: OpenVPN Server IP Third IP: OpenVPN Client IP Foruth IP: Broadcast IP This is how every client connection/subnet looks like.

I restored from a previous backup that didn't contain any configuration information for OpenVPN. Ping now works. And doesn't stop working after 30 seconds of being up. So far so good. I imported the pfsense certificate authority certificate and key (ca.crt & ca.key) into the Cert Manager CA Authority tab from our older Linux-based router which used easyrsa to generate those certificates/keys. Then I went to the client certificate tab and imported Firewall.crt & Firewall.key from our Linux-based router to a 'Firewall' certificate entry. I also imported a client certificate and key into a new client certificate entry called DougSampson. I went to the OpenVPN configuration and imported the contents of the ta.key into the TLS-Authentication box. For the Peer Certificate Authority I chose the Firewall Certificate Authority certificate (ca.crt in this case) and for the Peer Certificate Revocation List I chose the Firewall Certificate Authority entry (we didn't employ a CRL list on our Linux-based router). For the Server Certificate, I chose the Firewall server certificate (in this case, the Firewall.crt) for the Server Certificate box. I chose 1024 bits for the DH Parameter Length. We had a dh1024.pem file from our Linux-based router but didn't know where to put it- there's no box for selecting the dh1024.pem file. It currently sits in the /root/easyrsa4pfsense/keys folder. POSTSCRIPT: I now notice 'dh /etc/dh-parameters.1024' in server1.conf. Should I replace the contents of that file with the contents from the /root/easyrsa4pfsense/keys/dh1024.pem? The contents of server1.conf is as follows: dev ovpns1 dev-type tun 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 BF-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 69.xxx.xxx.xxx tls-server server 10.0.8.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc 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.101.0 255.255.255.0" push "dhcp-option DOMAIN dawnsign.com" push "dhcp-option DNS 192.168.101.1" push "dhcp-option DNS 192.168.101.4" push "dhcp-option DNS 192.168.101.7" push "dhcp-option DNS 192.168.101.254" push "dhcp-option NTP 192.168.101.254" push "dhcp-option NTP 192.168.101.4" push "dhcp-option WINS 192.168.101.4" client-to-client ca /var/etc/openvpn/server1.ca cert /var/etc/openvpn/server1.cert key /var/etc/openvpn/server1.key dh /etc/dh-parameters.1024 crl-verify /var/etc/openvpn/server1.crl-verify tls-auth /var/etc/openvpn/server1.tls-auth 0 comp-lzo passtos persist-remote-ip float push "route 192.168.102.0 255.255.255.0" Content of client.ovpn: client dev tun proto udp remote 69.xxx.xxx.xxx 1194 resolve-retry infinite nobind persist-key persist-tun ca ca.crt cert DougSampson.crt key DougSampson.key tls-auth ta.key 1 comp-lzo verb 3 The client config file worked just fine with our existing Linux-based router running OpenVPN. Now when I try to connect, it fails with a TLS handshake error. Here is what the openvpn.log spits out: Feb 28 10:07:05 pfsense openvpn[11729]: event_wait : Interrupted system call (code=4) Feb 28 10:07:05 pfsense openvpn[11729]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1542 10.0.8.1 10.0.8.2 init Feb 28 10:07:05 pfsense openvpn[11729]: SIGTERM[hard,] received, process exiting Feb 28 10:07:05 pfsense openvpn[48656]: OpenVPN 2.2.0 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Aug  6 2012 Feb 28 10:07:05 pfsense openvpn[48656]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Feb 28 10:07:05 pfsense openvpn[48656]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file Feb 28 10:07:05 pfsense openvpn[48656]: TUN/TAP device /dev/tun1 opened Feb 28 10:07:05 pfsense openvpn[48656]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Feb 28 10:07:05 pfsense openvpn[48656]: /sbin/ifconfig ovpns1 10.0.8.1 10.0.8.2 mtu 1500 netmask 255.255.255.255 up Feb 28 10:07:05 pfsense openvpn[48656]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1542 10.0.8.1 10.0.8.2 init Feb 28 10:07:05 pfsense openvpn[50174]: UDPv4 link local (bound): [AF_INET]69.xxx.xxx.xxx:1194 Feb 28 10:07:05 pfsense openvpn[50174]: UDPv4 link remote: [undef] Feb 28 10:07:05 pfsense openvpn[50174]: Initialization Sequence Completed Feb 28 10:08:06 pfsense openvpn[50174]: <ovpn client="" ip="" addr="">:51681 Re-using SSL/TLS context Feb 28 10:08:06 pfsense openvpn[50174]: <ovpn client="" ip="" addr="">:51681 LZO compression initialized Feb 28 10:09:06 pfsense openvpn[50174]: <ovpn client="" ip="" addr="">:51681 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Feb 28 10:09:06 pfsense openvpn[50174]: <ovpn client="" ip="" addr="">:51681 TLS Error: TLS handshake failed</ovpn></ovpn></ovpn></ovpn> Moreover, the pfsense server stops being able to ping! After rebooting, I'm unable to ping at all. It looks like there is a misconfiguration error somewhere in there and I cannot figure it out. Can anyone spot any errors? I notice that in the server1.conf file, the cipher is specified but it is not specified in the client config file. Is this an error? Are there any other errors? ~Doug

My example of this "feature" is at http://forum.pfsense.org/index.php/topic,59464.0.html I have noticed it with both Peer-to-peer shared key and SSL/TLS links every now and then. I saw it just now and managed to gather some data.