thanks all for replaies, I used this link to install and config Openvpn client in my Centos servers http://www.techrepublic.com/blog/opensource/how-to-set-up-a-linux-openvpn-client/1894 After that i get my client config files from " export client " and the CA file and put it on my Centos server Also, i disable the firewall on my Centos then i run Client.conf. this message appeared openvpn client.conf Wed Mar  7 04:23:45 2012 OpenVPN 2.1.4 i386-redhat-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Apr 24 2011 Wed Mar  7 04:23:45 2012 NOTE: OpenVPN 2.1 requires '–script-security 2' or higher to call user-defined scripts or executables Wed Mar  7 04:23:45 2012 Cannot load private key file jrcfw01-udp-2198-tls.key: error:0906D06C:PEM routines:PEM_read_bio:no start line: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib Wed Mar  7 04:23:45 2012 Error: private key password verification failed Wed Mar  7 04:23:45 2012 Exiting any new suggestion. thanks.

@jimp: I don't think there is a howto, but I'm fairly certain I've gone over the whole config elsewhere on the forum in other posts. http://hardforum.com/showthread.php?t=1663797 There is the guide.  I can copy pasta what it says once I test and make sure it works.

So that time must really mean that they aren't connected at all (connected time is null/zero…) if I can reproduce that sometime I'll try to code around it.

For a site-to-site setup, you don't want to use the wizard. Use a shared key setup, check the doc wiki there are several examples.

Removing "auth-nocache" from client configuration files indeed resolved the issue. Although encouraged by OpenVPN to use this option in the client configuration apparently when the data channel renegotiates the keys cached credentials are needed or re-authorization is required to keep the connection active! Thank You for the fix Wasca!

@Wasca: I'm using TUN, should I be using TAP? tun is fine.  Typically though, when I do tunnels, I have the tunnel network on a different subnet that the network that the clients will be trying to reach. ex.  For my home, I have 10.10.6.0 /24.  For my buds to VPN to me and grab stuff from my server, they are on 172.17.0.0 /28. The issue might be that the tunnel network is using the same subnet as the network you're trying to access.

Well, it not working on the one of the WANs, only to the second: I have deleted the floating rule for the WAN in question, created a NAT rule and the corresponding FW rule. I have let the other floating rule untouched, though: NAT Rule [image: natmap1196tolanif.png] Firewall rule [image: allowovpntocyta.png] I have added the info to the Client export for Viscosity: [image: clientq.png] However, Viscosity conf contains the info for the 1st WAN address, nothing for the second: dev tun persist-tun persist-key proto udp cipher AES-128-CBC tls-client client resolv-retry infinite remote 1st_WAN_address 1196 tls-remote VPNServer auth-user-pass comp-lzo ca ca.crt tls-auth ta.key 1 cert cert.crt key key.key The connection is failing, the log is below, and if by hand change the WAN address in the conf file to the 2nd WAN address the connection succeeds: Mar 03 14:38:46: LZO compression initialized Mar 03 14:38:46: UDPv4 link local (bound): [undef]:1194 Mar 03 14:38:46: UDPv4 link remote: 46.198.128.106:1196 Mar 03 14:39:46: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Mar 03 14:39:46: TLS Error: TLS handshake failed Mar 03 14:39:46: SIGUSR1[soft,tls-error] received, process restarting Best regards Kostas

This is route 10.123.45.0 255.255.255.0; The subnet of the roadwarrior from site A that added to site B

I figured it out. I'm using TLS + username password, and I had auth-nocache set in the client config. After I removed that it was all good.

my 192.168.1.* is connect to 192.168.2.* via ipsec I need my openvpn user to connect to either 192.168.1.* or 192.168.2.* but have access to both networks with one vpn connection. What am i doing wrong?

If you are running the OpenVPN Client on a Windows Vista/7 OS then you need to run it  "as administrator" because without windows cannot configure the routes. Further you need to create an allow rule on the openvpn interface on pfsense.

@Darkk: Ok cool. :) I am paranoid about security so wanted to make sure it doesn't have any SSL certificate exploits that I've been hearing about lately. Darkk http://blog.pfsense.org/?p=633

Thanks Jim, I did some quick tests today using an existing site-to-site setup but the results were a little disappointing. At the client end I have a 40mbit WAN connection and a 100mbit connection at the server end. When I redirect the client gateway, I struggle to get over 10mbit on a speedtest.  If I remove the redirect-gateway option, the speedtest correctly reports 38mbit down. This was using no encryption.  The client is running off an Alix box, the server is a quad core Xeon. My initial thoughts are that the client hardware doesn't have enough horsepower to deliver throughput but on the other hand, with no encryption should this really matter? EDIT: Checked CPU using 'top' and the openvpn process peaks at around 40% when using AES-256 and 25% with no encryption  :-\

@focalguy: On Windows 7 you need to start OpenVPN as administrator or it doesn't have the permissions to update the routing table of the PC. That was the problem. Thank you very much. Everything works fine now.

Thanks for all the responses. I think that CMB hit it on the head. Preliminary testing gave me a gut feeling about the smb protocol. I had devised a set of tests to prove that the problem was with that, but never got a chance to implement them. I had to put the project on hold until I finish putting out some other fires….just not sure when that will be....At least now, I have a direction to get started in...

@jimp: there is also a bug in the 2.0 and 2.0.1 upgrade code for OpenVPN - if you did not have compression enabled before, it would show enabled after the upgrade. Disable compression, save, and reconnect. Compression being mismatched isn't enough for the connection to fail, but it will stop traffic from being passed. [Even if you re-create it by hand it would be easy to miss] Thank you!!! Took me several tries to get this stupid traffic pass working.  I togged the compression setting and volia it worked. Now everything is working like it should. Darkk

It sounds like you have 2 options: 1.  Configure a WINS server, add it to your DHCP scope and push it out to your VPN clients.  This way, each connected VPN client will be dynamically mapped to the WINS server and therefore resolvable by name from your LAN. 2.  Go to a bridged solution.

Hello jimp, Thank you very much, Now it works.