@jspc You should make clear first, which host is the OpenVPN SERVER and which is the OpenVPN CLIENT and which Networks you want to rech. The network(s) behind the SERVER or behind the CLIENT. If the networks behind the SERVER: then you have to push the routes from the networks behind the server to your client. Pushing routes will be configured on the SERVER. If you do not like to push the routes you can add them at the CLIENT config. Both is working but I think the better solution is to push the from the SERVER to the client. the command on SERVER is: push "route 192.168.100.0 255.255.255.0"; If you like to connect to the network(s) behind the CLIENT: then you have to add the route  of the network behind the CLIENT on the SERVER: route 192.168.200.0 255.255.255.0; AND you have to add an "iroute" command on the CLIENT for the network behind the client. But at the irout command I am not 100% sure. iroute 192.168.200.0 255.255.255.0;

hi, i've seen the openvpn+ospf act the way you descibe when you make changes to the wan configuration and save them. restarting openvpn seems to solve that for me. this does not seem to be the case every time. for me this is rarely a problem so i've never bothered to look into it.

Probably would work with something to make the IP static in a client-specific override entry. Not sure what it would be offhand for a tap IP, but I thought it was supported (I know it is for tun, but the syntax is likely different)

Thank you!  In my OpenVPN server.conf I needed to add the appropriate route and iroute ccd entries, like the Thelonious example.

That's not great news. I set my tcp port to 0 which says it will make it dynamic. I noticed an immediate increase in speed, but it's still nowhere near what I had before. Before changing the port I was barely able to break 2mbit, changing it to dynamic puts it at just under 5mbit. Before I was able to break 50mbit with ease. You are correct in the assumption that I have no control over the server, but I suppose I can put in a complaint to see if I can make something change… Thanks for your help cmb, you're a good man.

Group support isn't all there yet. There are some patches out there, but it's still considered an open feature: http://redmine.pfsense.org/issues/1009

@nooblet: now in my troubleshooting I had to edit the server conf file (/var/etc/openvpn/server1.conf  use Diagnostics > edit file > browse to find it) and change the 'ifconfig' option because it would input it as ifconfig 10.0.8.1 10.0.8.2 when instead it should have been ifconfig 10.0.8.1 255.255.255.248, I have since seen it appear to work with this step but it doesn't hurt (and it cleans up the logs). SAVE I don't want to edit file every time I'm open and save openvpn config. And I made litle change in php-file for version pfSense - 2.0.1 1. On console enter digit 8 - Shell 2. Invoke editor to edit file /etc/inc/openvpn.inc with command ee /etc/inc/openvpn.inc 3. Goto line 405 4. Replace 405 line                                 $conf .= "ifconfig $ip1 $ip2\n"; with 4 lines                                 if ($settings['dev_mode'] != "tap")                                         $conf .= "ifconfig $ip1 $ip2\n";                                 else                                         $conf .= "ifconfig $ip1 $mask\n"; 5. Goto line 527 6. Replace 527 line                         $conf .= "ifconfig $ip2 $ip1\n"; with 4 lines                         if ($settings['dev_mode'] != "tap")                                 $conf .= "ifconfig $ip2 $ip1\n";                         else                                 $conf .= "ifconfig $ip2 $mask\n"; That's ALL! Now in openvpn config will be correct line for ifconfig command.

The static route is the only solution, though you should just be able to set a static route for 10.1.2.0/24 on any machine that is dual-homed (the technical term for a machine connected to multiple networks). If that is too much of an overhead, consider removing the direct WAN connection for those hosts.

This seems to be fixed in 2.0.1. I was able to upgrade to 2.0.1 using the console and everything works fine now.

I love this kind of errors  ;D

Are you going to subnet that out downstream or something - yeah I could see quite a few problems with putting 8000 some clients on the same broadcast domain ;)  BTW /18 is what 16382 hosts – quite a bit more than 8000. And to be honest 192.168.0.0/24 would be a really bad choice for your tunnel network, since 192.168.0.0/24 is a VERY common IP range, so you prob going to conflict with the remote networks local lan space.

Yes, you'd route to the translated subnet

solved thaaanks.

To solve this problem you can override an entire domain by specifying an authoritative DNS server to be queried for your local domain! -Services   -DNS forwarder the last option… [image: Services_DNS_forwarder.png] [image: Services_DNS_forwarder.png_thumb]

Many thanks for all answer. Maybe the roadwarrior Pc's firewall causes it. I will test it again. Other good tip to check vncserver binding.

I sidestepped this issue by changing to 1:1 NAT with a separate subnet for VPN clients.

I sidestepped this issue by changing to 1:1 NAT with a separate subnet for VPN clients.