@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

Firewall rule

I have added the info to the Client export for Viscosity:

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