OK good news, the ROUTE-NOPULL command resolved the issue for me. Now firewall rules work and the VPN static connection to the Server does NOT override the router and pull all the traffic into it.
thanks for all your help.

Christian Laf

OK I found this link: https://help.ubuntu.com/lts/serverguide/openvpn.html#openvpn-simple-client-configuration  which gave me the clues to set up.

cd /etc/openvpn unzip  XX--udp-1194-bsdp-config.zip ln -s  XX-udp-1194-bsdp.ovpn client.conf service openvpn start

It asks for a name and password , I'll figure out how to store that next.

then check connection with:

ifconfig tun0

Problem resolved by reinstalling the OpenVPN Client Export Utility package.

What you have done is to guarantee an IP space collision with anyone else you have to connect to who happens to be on 192.168.X.X.  This is, essentially, everyone.

Want to set up OpenVPN so you can VPN in from the road?  It'll break from any LAN using 192.168.X.X which is, essentially, everywhere.

Here are some random suggestions:

10.162.93.0
172.19.80.0
192.168.232.0

172.19.80.0 is perfect.  I'd use 172.19.80.0/20.  Give your segments 172.19.80.0/24, 172.19.81.0/24, 172.19.82.0/24 … 172.19.95.0/24

ETA: It looks like we're misreading you and you assigned /24s.  You are better off keeping the address space you occupy as small as possible while reasonably anticipating all future needs at the site.  Notice that the scheme I recommend lets you cover the entire network with one route: 172.19.80.0/20, and gives you 16 /24 networks to work with.  The odds of you ever colliding with anyone else (who didn't do something idiotic like use 172.16.0.0/12) are very minimal.  If you think there is no way you'll ever need 16 subnets, by all means allocate out of a /21 or /22.  Or just go from 80 to 81 to 82, etc and it'll get as big as it gets.

Okay, okay, so this seems to have hilighted that my setup is a bit backwards regardless.

I was under the impression that I need to set up a separate server for each client who wants to connect. Why would I need to do that, you ask? No idea, just thought I did. Hence, the allocation of a /24 address range when only one client was connecting seemed wasteful. This is why I was trying to assign a /29 subnet to each server, to keep them all on the same range.

@kejianshi:

Maybe I read wrong…

On the server side are you configuring the same 10.10.7.0/24 on two different openvpn configs running on a single pfsense?

"This is the part I'm struggling with. Assigning a different /24 subnet to each is the only way I've managed to get it to work" - Yeah - Because thats the only way you should do it.

Originally, yes. One server would get 10.10.7.0/29 and the next would get 10.10.7.10/29 - Thus allowing for up to ~eight addresses, but the /29 would only use 6. This should allow for reconnection if the connection drops out and the server keeps the connection open, not being aware it has been closed.

Apparently, my fundamental misunderstanding on how this is supposed to work has been the problem from the beginning.

@phil.davis:

You have to use a different tunnel network in every OpenVPN server instance.
Why are you making 2 OpenVPN servers?
You can have many clients connecting to the 1 server with no problem.
For security you should really give every client its own client certificate, create off the same CA as the server certificate. Then if needing you can use Client Specific Overrides to allocate particular /30 of the tunnel network to particular clients, and then make firewall rules specific to particular client addresses…

After Googling exactly what you mentioned, I stumbled across this article (https://doc.pfsense.org/index.php/OpenVPN_multi_purpose_single_server) which appears to explain what you're referring to in detail. So, it's setting it up in a similar way, but correctly (which I wasn't). This should allow me to allocate only a small address space to each client, which makes much more sense than how I was doing it. Thank you.

@kejianshi:

phil.davis is correct on all counts.

The only time I run more than 1 openvpn instance on a single pfsense is when I need to provide seperate services to people with different needs, or to firewall different types of users from each other or the LAN etc.

If I just had a whole bunch of people who needed openvpn access and I could treat them all the same I'd use just 1 instance of pfsense.

No matter if you decide to use a single or multiple instance of openvpn, make sure the subnet you use for each tunnel doesnt overlap with any other subnet in use on the pfsense and be careful with using /16s because its real easy to have those overlap with all your /24s.

Yes, having extensive networking qualifications through the network+ course I completed some years ago (tongue-in-cheek) I'm trying to be as careful as possible with my subnetting. I think I'm over-allocating in the beginning, but I can always reduce as time goes on.

Thanks again for the help, guys. I think I've got my head around it now.

I setup a vm with pfsense, used dhcp as wan. After adding the ovpn client connection I no longer can access the web configurator (is this because the LAN is added from the ovpn connection and now I have to open a port to the web configurator?

Before setting up the OpenVPN and assigning an interface to it, put the pass rules that you need onto WAN. The 2nd interface is "LAN" underneath, and when that appears, the anti-lockout rule goes there, rather than on WAN.

You should be able to hard-code in the WAN-side client a default gateway (or route(s) if you just want it for some destinations) that points to pfSense WAN IP. Make sure pfSense WAN IP is a static mapped IP on "Router" so it does not change.
Put appropriate pass rules on pfSense WAN to allow that traffic from client and policy-route it to the OpenVPN link-gateway.

After making the internal CA, you make a server certificate for the server end, and a client certificate for each client (user). Then use the name of the client certificate in "common name" in the client specific overrides entry.

Then give each client/user just their own certificate.

Also, in the server settings, check "Strict User/CN Matching" - "When authenticating users, enforce a match between the common name of the client certificate and the username given at login". Then if a client person gets hold of someone else's client certificate they cannot use their own user-password with that other certificate to try and impersonate the other user and gain the other user's access/IP.

@Chrisiesmit93:

so user 1 gets 192.168.3.2 and user 2 gets 192.168.3.2, and so on.

Well that would not be good if you gave the users the same IP.
In your openvpn setup check the

Allocate only one IP per client (topology subnet), rather than an isolated subnet per client (topology net30).
  Relevant when supplying a virtual adapter IP address to clients when using tun mode on IPv4.
Some clients may require this even for IPv6, such as OpenVPN Connect (iOS/Android). Others may break if it is present, such as older versions of OpenVPN or clients such as Yealink phones.

By default clients get IP in a /30 of the subnet you assigned to clients.  In my case 10.0.8.0/24, so they get /30 of that

example
Ethernet adapter vpn:

Connection-specific DNS Suffix  . : local.lan
  Description . . . . . . . . . . . : TAP-Windows Adapter V9
  Physical Address. . . . . . . . . : 00-FF-5A-2F-7E-EA
  DHCP Enabled. . . . . . . . . . . : Yes
  Autoconfiguration Enabled . . . . : Yes
  IPv4 Address. . . . . . . . . . . : 10.0.8.6(Preferred)
  Subnet Mask . . . . . . . . . . . : 255.255.255.252
  Lease Obtained. . . . . . . . . . : Friday, February 20, 2015 7:45:05 AM
  Lease Expires . . . . . . . . . . : Saturday, February 20, 2016 7:45:05 AM
  Default Gateway . . . . . . . . . :
  DHCP Server . . . . . . . . . . . : 10.0.8.5
  DNS Servers . . . . . . . . . . . : 192.168.1.253
  NetBIOS over Tcpip. . . . . . . . : Enabled

The packet is probably getting to the remote sites. But they will need to know how to answer/route back to 172.16.1.0/24 and there will need to be firewall rules in the appropriate places to pass 172.16.1.0/24

OK I managed to get it working by checking the "Force all client generated traffic through the tunnel." option.

@phil.davis:

@tsolrm:

Once unchecked it opens up 'IPv4 Local Network/s'

Do I put the details of my LAN here? And this way only LAN traffic goes through vpn?

Yes, you need to tell it the subnet(s) that you want to be reached across the OpenVPN - your LAN(s)

Thank you for your help. Everything seems to be working

I followed this tutorial, and it has worked for me…

http://hardforum.com/showthread.php?t=1663797

Tks

Yes, it should be easy to change LAN subnet:
a) Change pfSense LAN IP
b) Change pfSense LAN DHCP range
c) Change OpenVPN server Local Network/s list - that cannot have things like LANnet specified, so it has a redundant 192.168.1.0/24 in it  :(
d) Check your aliases in case you have any that included specific addresses in 192.168.1.0/24 and fix as needed
e) Check your firewall rules for any specific uses of addresses in 192.168.1.0/24 (hopefully your rules all use aliases and/or the pre-defined LANnet and LANaddress - which will apply automagically)
f) Diagnostics->Edit File, /cf/conf/config.xml, search for "192.168.1" and see what other stuff is left behind
g) Change anything on LAN that has a static IP set (file server, print server, WiFi AP management interface…)
h) Get all LAN clients to renew DHCP

I have multiple times with no success.

It is normal - whatever address you NAT the site A subnet to, that needs to be an address that site C knows how to route back to. So you probably might want it to be some address in site B, which site C already knows how to reach.

Post a physical network map with IP's.  Post your openvpn config (server1.conf).