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.

@mohanrao83: Dear all pfsense fan's and experts, can u pls give me some idea where i m wrong. because where i m try to ping from A psense to B Pfsense lan ip its pinging also same ping from B to A. but not able to ping lan IP'S sir awaiting for your positive and early response . Thanks Mohan Rao I had the same issue: did you check the personal firewall rules on your destination devices? Normally, they drop any packet coming from a not-trusted network (like the remote network). Try to add the entire remote network in your personal firewalls. Motaro

@cmb: OpenVPN traffic needs rules on the OpenVPN interface, maybe that's what you're missing. LAN rules are for outbound, OpenVPN rules for inbound. I found the issue: it was a firewall blocking any incoming packet from a network outside the trusted one (the local network). Adding the remote network in the personal firewall, OpenVPN works like a charm! Anyway, thank you for your reply!

An access point does require a default gateway if you're managing it from off-subnet.

you just need a port forward on the OpenVPN interface. Probably easier if you have proper routing on your VPS to the internal host on your network so it can just route it in, no need for additional NAT in between.

I dont think this is the problem either.  I had a rule under firewall rules - LAN allowing / to */1194.  All of my outbound traffic rules are defined similar to this on the lan tab (and the other traffic always originates from other local machines).  However, since this OpenVPN server actually sits on the same box as the WAN interface, I thought perhaps it was being dropped.  I tried adding a similar rule under WAN tab and the problem persists. I have logging of packets dropped by default turned on (I assume this checkbox applies to all interfaces) and the logs do not show anything being dropped on 1194. To verify its not a firewall issue, I disabled openvpn server and spun up netcat on udp/1194.  Connected to it from external network and could send text both ways no problem. Tried using TCP too with similar results.  We can see the tcp connection established but immediately reset before trying to auth. Sun Feb 19 14:01:09 2012 WARNING: Make sure you understand the semantics of –tls-remote before using it (see the man page). Sun Feb 19 14:01:09 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables Sun Feb 19 14:01:09 2012 Re-using SSL/TLS context Sun Feb 19 14:01:09 2012 LZO compression initialized Sun Feb 19 14:01:09 2012 Attempting to establish TCP connection with WAN-IP:1194 [nonblock] Sun Feb 19 14:01:10 2012 TCP connection established with WAN-IP:1194 Sun Feb 19 14:01:10 2012 TCPv4_CLIENT link local: [undef] Sun Feb 19 14:01:10 2012 TCPv4_CLIENT link remote: WAN-IP:1194 Sun Feb 19 14:01:10 2012 Connection reset, restarting [0] Sun Feb 19 14:01:10 2012 SIGUSR1[soft,connection-reset] received, process restarting

Solved! Set rule generation to Manual in Firewall > NAT > Outbound Create rule (Interface: MYVPN, Protocol: any, Source: Network 10.0.0.0/24, Destination: Network 10.8.0.1/32) When I type 10.8.0.1 in my laptop's browser, I now see a webpage running on my home server, which was my goal. Thanks for the replies!

In order for broadcasts to traverse the VPN, it will need to be set up as a bridge.