I've seen that the AES-CBC 256 bit is working fine so it is cypher related.

Need a lot more info there about the OpenVPN and system config to guess at a cause. Typically that error is due to a route for a network involved already existing.

If the OpenVPN tunnel terminates to the CARP VIP of fw1/fw2, you don't need to do any kind of fancy failover. Furthermore, if the setup is the same on both connections (same CA/Cert/settings) you can just add another "remote x.x.x.x;" line in the custom options of the client and it will try that other IP if the first one is down.

Probably means to only route select networks across the VPN instead of routing everything. That is the default behavior of OpenVPN on pfSense though. You have to check the box to force client traffic through the VPN in order to not do that.

That automatically puts the management line in?  I ran out of time, but when the next window of opportunity arises to change the network around I'll give it a shot!

You can easily use URL tables in 2.0 to do that with a list of the CIDR blocks of US IPs. Or if you want to limit that to just Netflix and Hulu, go to ARIN and find all their IP blocks and create an alias with those.

thanks much

http://forum.pfsense.org/index.php/topic,36060.0.html http://forum.pfsense.org/index.php/topic,36156.0.html Edit: http://forum.pfsense.org/index.php/topic,38166.0.html

I'm using 1.2.3, it is clear now what I have to do.

solved, it was a routing problem on the windos server just added a route to the 192.168.9.0 network and now it works fine

Solved! But I think I found a bug in the pfsense software …..... ?? The clue was here: routing table client: default    10.138.20.68    UGS    0    40850    1500    sis0     10.138.20.0/24    link#1    U    0    31725    1500    sis0     10.138.20.67    link#1    UHS    0    0    16384    lo0     127.0.0.1    link#5    UH    0    47    16384    lo0     192.168.2.0/24    link#2    U    0    63824    1500    sis1     192.168.2.8    link#2    UHS    0    0    16384    lo0     192.168.4.0/24    192.168.12.2    UGS    0    489    1500    ovpns1   192.168.12.0/24    192.168.12.2    UGS    0    1233    1500    ovpns1     192.168.12.1    link#8    UHS    0    0    16384    lo0     192.168.12.2    link#8    UH    0    0    1500    ovpns1     192.168.18.1    link#9    UH    0    0    1500    ovpnc3     192.168.18.2    link#9    UHS    0    0    16384    lo0 Initially I wanted a tls site to site tunnel and I used this pfsense box as server, I put 192.168.4.0/24 as remote network. Afterwards I deleted it, set up a road warrior network with tls and conigured a shared key tunnel for the site to site connection. 192.168.4.0/24 was removed from the server configuration (at least when I looked at the interface). I wanted to at 192.168.4.0/24 as remote network to the client but it refused to add the route. When I looked at the routing table I noticed that 192.168.4.0 was still connected to the server interface ovpns1! I made a backup of the configuration and there I saw an item <remote_network>192.168.4.0/24</remote_network> in the server config. (Again, in the interface this was nowhere to be seen!). I removed <remote_network>192.168.4.0/24</remote_network> from the xml and restored the edited config file and…...... it works :).

@Metu69salemi: It would be better if you don't have another nat between your setup Clients need to know what external ip-address they're accessing. But because there is router's own lan-subnet, i don't know does this work. Maybe using portforwards from router will do it, but not sure Indeed why not connect you pfsense directly to your modem? incase if it's one box most boxes have the ability to go into just modem mode so you can get your public ip on your pfsense As for a range take 192.168.254.0/24 ? It doesn't really matter just take something that is clear to you

No, this isn't correct (I found it out myself). OpenVPN behaves exactly as described in the manual. There is NO client or server in static-key mode. Even "clients" will connect to each other. The difference with pfsense is, that it omits the "remote <adress>" option when it's configured as server (if you add it under "Advanced configuration", you'll get the "client"; "rport" option is also important). This can be important if you connect to systems with dyndns adresses (for example), because you get a conection even if the "servers"-adress won't resolve at the moment (because the "server" connects the "client"). Anyway, it works as expected…</adress>

yeah i forgot the user manager  ;D but thats cool, now I got it thats exactly what i wanted thanks all (again)  ;)

Upgrade to a recent snapshot if you aren't seeing an OpenVPN dynamic gateway (or if you see it but it's always "gathering data"). There were some bug fixes a week or so ago, after the official RC3.

What solved this one?

If they don't have a certificate, and you're on SSL/TLS, then they can't access the VPN. I don't think there is a permission for OpenVPN use, though there probably should be, may not see that until 2.1 though.