Create an interface and route it out that interface.  Or you can modify the routing tables manually (not suggested).

It didn't finish establishing the connection.  I'd need to see more if you still haven't fixed the solution, you can always contact me.

Cheers.

-Percy

Excellent!! thanks for reply!!

When you set up the VPN configuration, make sure you're using the right certificate authority and client certificate in your config.  Otherwise, delete the CA cert and client cert and redo those.  It'll almost definitely solve your problem.  Sounds like a problem with your cut and paste.

-Percy Kwong
http://swimminginthought.com

The issue with the GFW is that they interfere with the authentication mechanism (TLS).  There are ways around it, although it is not considered secure.  There would be nothing to stop them from killing the connection once it's up.  A shared key configuration would work, although, it isn't exactly secure.

Sorry guys checked my config and realised that I forgot to add the route back from the client site to site to the roadwarrior.

Cheers,

Raj

Hi TooMeek,

Unfortunately the "Tunnel Network" field cannot be left blank and will always result in the server directive. This directive expands into:

**mode server
tls-server
push "topology [topology]"

if dev tun AND (topology == net30 OR topology == p2p):
  ifconfig 10.8.0.1 10.8.0.2
  if !nopool:
    ifconfig-pool 10.8.0.4 10.8.0.251
  route 10.8.0.0 255.255.255.0
  if client-to-client:
    push "route 10.8.0.0 255.255.255.0"
  else if topology == net30:
    push "route 10.8.0.1"

if dev tap OR (dev tun AND topology == subnet):
  ifconfig 10.8.0.1 255.255.255.0
  if !nopool:
    ifconfig-pool 10.8.0.2 10.8.0.254 255.255.255.0
  push "route-gateway 10.8.0.1"**

Given your setup that would result in an ifconfig directive that wronly sets the ip address. As a workaround for p2p mode I have found the following solution:
-Add the ifconfig-noexec directive to the advanced settings.
-Assign your OpenVPN interface.
-Manually give it the correct static configuration.

Now, whenever OpenVPN starts, the wrongly generated ifconfig directive will no longer override your static settings. Et voila, you can configure it however you want. I do the same for routes. I remove any routes in OpenVPN itself, and just manually add routes to gateways set on the other side of my links. This also has the nice side effect of detecting a downed VPN by looking at the remote subnet's gateway status in the dashboard.

However, what I have not tackled yet is how to get this working in Remote Access mode. Apparently OpenVPN wrongly routes the .1 of my "Tunnel Network" despite my configured interface values. My guess is this happens because, although the OS is set correctly, OpenVPN itself doesn't know that the automatically assigned .1 server address is no longer in use. In p2p (site2site) setups this is no problem. It just always sends everything to the other side. However, in Remote Access mode (in OpenVPN it's called "server mode") OpenVPN itself needs to know to which client to route what data. Hence all the new iroute directives. Obviously, overriding the server interface does not override OpenVPN its internal routing and thus keeps believing it's the .1 in the Tunnel Network.
As the config file gets overridden on every reboot, I cannot see how we can currently use "topology mode" in combination with an alternative Tunnel Network server IP. Maybe someone knows how to use the field for extra directives to inhibit automatically configured directives? Or maybe we can prevent pfsense from overwriting a custom server1.conf file?
If not, a nice feature request would be another OpenVPN server mode called "custom". With no fields other than the "Advanced config" field. This way we would be able to do any complex setup while interface adjustments (precious dev-time) remain minimal. Devs?

Anyways, I hope this will help you. And let me know if you find other workarounds.
Jori Huisman

Still an issue for us. This is a UDP connection as well.
I may try swapping to TCP to see if it persists any better.

I think that Amachi is not p2p as OpenVPN but you can pass all traffic throught their server..

uncheck Redirect Gateway "Force all client generated traffic through the tunnel. "

The fact they're marketing "full tunneling" as some big deal feature, something you've been able to do with pfSense since day 1 OpenVPN was implemented ~7 years ago, really shows how desperate they are for marketing material. Welcome to last decade, Untangle!

Has nothing to do with OpenVPN.  Most likely its your ISP's DHCP Server.  It can be safely blocked and a firewall rule created to surpress it from being logged.

Thanks jimp - I got it working with multiple server endpoints on the one pfsense box. When time allows I'll look into the method you've listed to see if it offers any advantages, and I'll report back here with a comparison.

@jimp:

Perhaps, the real fix is of course to not use spaces in CA/cert names to begin with, but either way, it should work with the quotes I thought.

I do agree. Not sure why that one cert of mine had a space in it, none of the others do. As a linux user I don't normally use spaces.

I found it… the problem is with the iphone app "Bria" it has an option for using with VPN and by default this was disabled. After enabling it .. everything works like magic :D

@heper:

the command line is no longer needed for openvpn if you use pfsense 2.0.x (there is a client exporter package available to create a setup for windows/osx clients)

So what do I do just install the open vpn package on my router and follow the promts to connect my laptop?
If you could walk me through this that would be great.

Just tried this and the```
push "route 10.0.2.0 255.255.255.0"

yes

I'm locking this thread as the promotion (mostly deleted, from users with only 1 post) is getting out of hand, smells fishy and this isn't a place for random consultant advertisements.