That's the most likely suspect at this point, I'd say.

Yes! Checked "Don't pull routes" and now it works! Now I want to change the gateway for specific vpn-connected-clients: On LAN: IPv4 * VPNSERVER net * * * VPN_PP_AMSTERDAM_VPNV4 none won't work.

That was it! Thanks @marvosa. All is working beautifully now.

@divsys: If you setup a second server (Serv2), simply create a new Certificate of Authority (Ca2) and build a new Server Certificate (Crt2) from Ca2. Any connections to Serv2 will then require a Certificate created via Ca2 and will not be valid at all for the original OpenVPN Server. Pro's completely separated Certificate chains full isolation of two categories of OpenVPN clients Con's two certificate chains to manage The concern I have is what happens if a mistake is made in one of the CSOs for a static client. That static client would still have a certificate with the original CA and thus would still connect to the original OpenVPN server and network. Since CSOs do not appear to be enforced, that client could get assigned the network from another CSO. @derelict: I have to do some testing but it appears the tunnel network on the server and the tunnel network in the CSO don't have to be related. If you were to, say, route 10.15.20.0/23 to OpenVPN I believe you could set the tunnel network to 10.15.20.0/24 and assign CSOs out of 10.15.21.0/24 You'd just need to add an iroute in the CSO (I think).  So if there was no CSO they'd get an address out of the dynamic pool and not step on any properly-configured CSOs. I might be completely wrong though. Can anyone else confirm if this is a valid configuration? can the "Tunnel network" setting in the OpenVPN server config be completely unrelated to the networks assigned in the CSOs? If so, I think this would be the ideal solution

Maybe it is a MTU problem, try a smaller MTU on the server side (can not modify the client). Is this warning a problem? WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1300', remote='link-mtu 1542'

this thread is from Jan 2015… I doubt the OP is still having a problem.. You reach 350kb doing what??  and is that really kb or KB? You trying to do SMB file copy over a high latency connection?  Yeah its going to BLOW...

I used wizard. Thank for your help~  ;D

You're better off if rules on the OpenVPN tab don't match traffic for the assigned interface. I generally delete all the rules on the OpenVPN tab when I use assigned interfaces.

Reading the text on the page likely would suffice. "If a client is missing from the list it is usually due to a CA mismatch between the OpenVPN server instance and the client certificate"

So you're using Remote access VPN on an 8860 with windows clients connecting to it and accessing a windows server on LAN? And to clarify are you getting 2Mbits or 2MBytes (16Mbits) per second on the clients? How did you configure the VPN? tun/UDP?

You can achieve this with "client specific overrides". Assign a particular tunnel IP to each user and you can control user access by source address in firewall rules.

You can do this on 2.3, you have the option to restrict an override to one or more servers. So on 2.3 you'd have three entries each set for one of your individual servers.

Johnpoz, Forgot to mention: The firewall has a Pentium 4 HT with 1Gb of ram. I have a ADSL connection with a speed of 12Mbs max and 0,625Mbs upload. Thank you

I guess what I really wanted to do was be able to add a pfsense vm without nat, dns, or dhcp to an existing network and use it just as an openvpn appliance with the old router (or in this case fortigate and cheap router ) just port forward to pfsense on the lan side with static ip. Thanks for the help.

I've run into the situation a few times with OpenVPN, mainly when I'm "fiddling" with my configurations. I think the scenario occurs when a client is in the middle of establishing a link and I try to pull the server side down. The server instance tries to stay alive and complete the link so the restart ends up failing (sometimes "silently"). Normally a manual command line kill of the session solves the issue.  Worst case you're stuck with a reboot (very rare). Once you stop playing with the config files on both ends (especially mid-connect), I've found OpenVPN to be very stable.