Well, I've done quite a bit of searching and I feel that I am getting closer. I am receiving this in my logs when trying to connect. Looks like an issue with the passwords, I've already checked that those are correct… May 18 20:30:32 openvpn[58267]: OpenVPN 2.2.2 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013 May 18 20:30:32 openvpn[58267]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock May 18 20:30:32 openvpn[58267]: WARNING: file '/conf/openvpn-server2.pas' is group or others accessible May 18 20:30:32 openvpn[58267]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts May 18 20:30:32 openvpn[58267]: Control Channel Authentication: using '/var/etc/openvpn/client1.tls-auth' as a OpenVPN static key file May 18 20:30:32 openvpn[58267]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication May 18 20:30:32 openvpn[58267]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication May 18 20:30:32 openvpn[58267]: Control Channel MTU parms [ L:1557 D:166 EF:66 EB:0 ET:0 EL:0 ] May 18 20:30:32 openvpn[58267]: Socket Buffers: R=[42080->65536] S=[57344->65536] May 18 20:30:32 openvpn[58267]: Data Channel MTU parms [ L:1557 D:1450 EF:57 EB:4 ET:0 EL:0 ] May 18 20:30:32 openvpn[58267]: Local Options hash (VER=V4): '0f816d6e' May 18 20:30:32 openvpn[58267]: Expected Remote Options hash (VER=V4): '2f3e190a' May 18 20:30:32 openvpn[58379]: UDPv4 link local (bound): 192.168.1.175 May 18 20:30:32 openvpn[58379]: UDPv4 link remote: My.IP.Address.123:1194 May 18 20:30:33 openvpn[58379]: TLS: Initial packet from My.IP.Address.123:1194, sid=a388832d cb9b06e6 May 18 20:30:33 openvpn[58379]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this May 18 20:30:33 openvpn[58379]: VERIFY OK: depth=1, /CN=OpenVPN_CA May 18 20:30:33 openvpn[58379]: VERIFY OK: nsCertType=SERVER May 18 20:30:33 openvpn[58379]: VERIFY OK: depth=0, /CN=OpenVPN_Server May 18 20:30:34 openvpn[58379]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1542' May 18 20:30:34 openvpn[58379]: WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC' May 18 20:30:34 openvpn[58379]: WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo' May 18 20:30:34 openvpn[58379]: Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key May 18 20:30:34 openvpn[58379]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication May 18 20:30:34 openvpn[58379]: Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key May 18 20:30:34 openvpn[58379]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication May 18 20:30:34 openvpn[58379]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA May 18 20:30:34 openvpn[58379]: [OpenVPN_Server] Peer Connection Initiated with My.IP.Address.123:1194 May 18 20:30:36 openvpn[58379]: SENT CONTROL [OpenVPN_Server]: 'PUSH_REQUEST' (status=1) May 18 20:30:36 openvpn[58379]: AUTH: Received AUTH_FAILED control message May 18 20:30:36 openvpn[58379]: SIGTERM received, sending exit notification to peer May 18 20:30:38 openvpn[58379]: TCP/UDP: Closing socket May 18 20:30:38 openvpn[58379]: SIGTERM[soft,exit-with-notification] received, process exiting

As long as you're using an OpenVPN that supports it. Some clients (on phones/tablets?) might not support it.

Hi, good to hear you get it working… i was struggling on same thing couple month ago.... I think your problem was in routes (if openwrt didnt route your request back from pfsense when pinging behind openwrt to pfsense) did you set remote lan 192.168.4/24 (openvpn settings "route 192.168.4/24") (what pfsense routing table shows ? does it know 192.168.4/24 network ? did you use peer-to-peer or remote access ? Set pfsense "Manual outbound nat" -> wan interface NAT all outbound traffic its public interface ip. (thats the way i allways do it, 1 NAT in network everything else is fully routed between routers..) Make sure DNS request goes also to tunnel (dns queries coming from openwrt / openwrt connected networks(lan).. If you use own dns resolver(at endpoint pfsense) you need to set openwrt to allow dns queries coming from private network(from pfsense). br. .k @cgu29: it's solved the problem came from the nat rules on the pfsense server i had to enable manual nat and add a mapping between the remote LAN and the natted IP (PFsense wan interface) hope it helps now time to quit and go to the pub (in France)

By doing this, am I telling the computer to use the VPN on everything EXCEPT for when it is in one of those subnets? Yes. When the VPN comes up, it sets the default route to itself. All packets for destinations that are not on a directly connected subnet and do not have an explicit route, will go to the VPN. Will it still cause DNS leaks? I guess the DNS is another issue. When you first connect to the local LAN, pfSense DHCP gives you an IP address and gives itself as the DNS server (that is thee default behaviour). So your PC will have DNS pointing to pfSensse. Because pfSense is on your local network, your PC will happily send DNS lookups there, and the pfSense DNS forwarder will do the lookup for you out the pfSense WAN. I guess you don't want that to happen - the DNS should go over the VPN also. Someone else could give some advice here - how to make the OpenVPN client replace the DNS server?

It's solved, thanks to cmb On my client side, the tunnel was bind to WAN interface instead of CARP Address. I did not upgrade. Thanks everyone.

U cannot 'push' settings to client over peer-to-peer vpn. If you want have routes over openvpn -> use ospf (more than 1 network wich is configured on openvpn settings.. or use 'redirect-gateway def1' to route all traffic via tun) br. .k

If you are not already having the StrongVPN link out of siteA as the default gateway for pfSenseA, then you will need to use policy-routing on the OpenVPN rules mentioned by @Reiner30 - in the Advanced of the rules, select the StrongVPN as the gateway for the traffic. Make sure your pass policy-routing rules on incoming OpenVPN specify something like "source <network a|network="" c="">destination (or destination )" - you don't want to route packets from network a to network b, straight past and out the StrongVPN.</network>

yes, one of the parallel threads here gives the answer already TODAY (search function is right upper; makes always sense to use it before posting ;)) http://doc.pfsense.org/index.php/CARP_Secondary_Unreachable_Over_VPN

I was just able to solve the problem. My server side config had "ping restart" configured, which I replaced by "keepalive", now the connection is not restarted anymore :)

I resolve this by configuring the router?

I use the OpenVPN Client Export Utility package and there is an option "Use a password to protect the pkcs12 file contents or key in Viscosity bundle. " under VPN:OpenVPN:Client Export. Does that work for you? (I haven't tried myself)

For the configs, just post the text.  For the firewall rules… take screen shots, upload them to photobucket and post using img tags.

No one can help me?

What version of PFsense? Post a network map. Post your server1.conf Post your firewall rules.

There are threads/howtos here for StrongVPN and I think VyprVPN. Anything OpenVPN-based should work similarly.

I've never seen any situation that called for that syntax. Only this: push "route x.x.x.0 255.255.255.0";