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.

It appears that the update

"2.0-RC3 (amd64)
built on Wed Jun 29 18:35:57 EDT 2011 "

fixed the issue. Very odd.

Thanks for the input, guys.

Thank you jimp, I'll try your suggestions ASAP then report back.

Just some notes on the same topic is found here:
http://forum.pfsense.org/index.php/topic,7840.msg198497.html#msg198497

Thanks. I think a have to learn a little bit more about ovpn. I thought the tunnel network ist just a /24 subnet where Server and Clients can communicate.
But it works now.
Had the problem that on Serverside there is a multiwan configuration and a firewallrule which directs traffic from lan to a Gatewaypool.
This rule caused the traffic with destination to remotenetwork going directly to the gatewaypool and not through the tunnel. So I created a rule with destination 192.168.0.0/24 without any gatewaysetting and  it works perfect now.
But is this normal behavior? My IP-Sec-Tunnels weren't affected by this rule.