If you can make a separate OPTn local subnet then you can put the NAS in that (and even use the actual subnet that the NAS will finally sit in at the remote end). That way the NAS should first see the route back to your LAN advertised through the tunnel and use that, rather than going locally straight to pfSense on OPTn.
You are going to have to change the NAS IP anyway when you send it, so this way you can change it and test that also.
When finished testing, cleanup your OPTn or you might run into some other confusion when the NAS really does connect from the remote site.

An added question: Does this configuration have any issues?

You are effectively putting the remote NAS as a device on your (logical) private internal network. It is just the same as having it in a different real subnet on an interface on your local pfSense. You can use firewall rules to restrict which local LAN IPs can even reach the remote NAS IP.
Of course, at the remote location the NAS is going to have a local IP there, which it uses to establish the OpenVPN tunnel back to you. I guess you can restrict local access to the FreeNAS box however you like from FreeNAS. But someone is going to have physical hardware/console access at the remote site and so you have all those things that require the remote site also be physically secure.

Thanks phil. I enjoy working through it. Best of luck for the new year.  8)

Damn… that was it.  Forgot to copy the TLS key from one to the other.  Works like a champ!

You are correct the connection tags are not necessary, they do come in handy if you need to set a proxy for just one of the remote entries though.  So I leave them there.

Thanks jimp!

uninstall the client and tap driver, then reinstall making sure to use the latest client.

Odds are, you have the 2.2.x OpenVPN windows client installed and not 2.3, so the verify-x509-name parameter is tripping it up.

Thank you very much. I'm not much of a networking tech ;)

Problem solved.

/Peter

@heper:

did you notice the "Redirect Gateway' checkbox in your server config ?

Force all client generated traffic through the tunnel.

route 10.10.20.0 255.255.255.0; push "route 10.10.20.0 255.255.255.0;

You don't need (or want) both statements, because it might one day mess something up at the other end, your client trying to push the route to the server at the other end. I think you just want at the client:

route 10.10.20.0 255.255.255.0;

which tells the client itself that this VPN is a route to 10.10.20.0/24

You should also be able to add 10.10.20.0/24 to the Local Network/s field at the server end - and that information will be pushed from the server to each client, so they get to know the server is a route to 10.10.20.0/24. That way removes any need to use the Advanced box.

But if it's working and you don't want to risk breaking it, then leave it as is!

I would like to give it a try. Currently i run TorGuard with dd-wrt on an old router.

Phil,
I really don't know what happened but since I rebooted, it now works!
Sorry for the waste of time!
Regards

Hello,

sorry for my late reply, Christmas time was a bit hectic :( Thanks again and you were right again. There was a policy based routing rule I didnt thinkt about, something like this:

iptables -t mangle -A PREROUTING -s 10.0.0.0/24 -j MARK –set-mark 2

And I set anoher one which solved the issue:

iptables -t mangle -A PREROUTING -d 192.168.1.0/24 -j MARK --set-mark 1

But now I have nother problem :/ I read myself into why I should use tun instead of tap and not bridging, because like you said it would produce lots of broadcast traffic for example. So I changed my server config to this:

config 'openvpn' 'lan' option 'enable' '1' option 'port' '1194' option 'proto' 'udp' option 'dev' 'tun2' option 'ca' '/etc/easy-rsa/keys/ca.crt' option 'cert' '/etc/easy-rsa/keys/server.crt' option 'key' '/etc/easy-rsa/keys/server.key' option 'dh' '/etc/easy-rsa/keys/dh2048.pem' #option 'ifconfig_pool_persist' '/tmp/ipp.txt' #option 'ifconfig-pool' '10.8.0.2 10.8.0.10 255.255.255.0' option 'keepalive' '10 120' option 'comp_lzo' '0' option 'persist_key' '1' option 'persist_tun' '1' option 'status' '/tmp/openvpn-status.log' option 'verb' '3' #option 'server_bridge' '192.168.1.1 255.255.255.0 192.168.1.200 192.168.1.205' option server "10.8.0.0 255.255.255.0" list push "route 192.168.1.0 255.255.255.0"

But again I cant get it to work, and it's even worse now than before with the bridging, where in the end I got it to work.

First confusing thing is that it shows this on the client:

tun2      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255

And on the server:

tun2      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255

Why two adresses for each? and why does the client get 6 (and 5?) and not 2? Also I cant even ping from side to side from the client to the server. My routing table looks a little bit weird too:

Kernel IP routing table
Destination    Gateway        Genmask        Flags Metric Ref    Use Iface
default        10.0.1.1        0.0.0.0        UG    0      0        0 eth1
10.0.0.0        *              255.255.255.0  U    0      0        0 br-lan
10.0.1.0        *              255.255.255.0  U    0      0        0 eth1
10.8.0.1        10.8.0.5        255.255.255.255 UGH  0      0        0 tun2
10.8.0.5        *              255.255.255.255 UH    0      0        0 tun2
172.20.16.0    *              255.255.248.0  U    0      0        0 tun0
172.20.24.0    *              255.255.248.0  U    0      0        0 tun1
192.168.1.0    10.8.0.5        255.255.255.0  UG    0      0        0 tun2

And on the server:

Kernel IP routing table
Destination    Gateway        Genmask        Flags Metric Ref    Use Iface
default        188-194-- 0.0.0.0        UG    0      0        0 eth1
10.8.0.0        10.8.0.2        255.255.255.0  UG    0      0        0 tun2
10.8.0.2        *              255.255.255.255 UH    0      0        0 tun2
172.20.24.0    *              255.255.248.0  U    0      0        0 tun1
172.20.24.0    *              255.255.248.0  U    0      0        0 tun0
188.194.*.0  *              255.255.255.0  U    0      0        0 eth1
192.168.1.0    *              255.255.255.0  U    0      0        0 br-lan

Hey Phil!
Thank you for your response, I always appreciate your help.
I didn't find the address in /cf/conf/config.xml but I believe it came from the cache of my ISP which kept this address that I used as a proxy/gateway a few days before! (It may have been kept in my adsl box cache, or remotely in my ISP proxy cache).
I turned my box off for a few hours and now everything's back to normal!
BTW I am a Unicef donator.
Regards,
Dennis
http://www.unicef.org
https://www.eff.org

Look at this post - http://forum.pfsense.org/index.php/topic,70683.0.html - it is a very similar thing.
In your OpenVPN server you need to add the friend's subnet(s) in Local Network/s, then the OpenVPN client will be told that the OpenVPN is a route to those places. On your friend's system you will also need to tell it that the IPsec VPN back to your house is also a route to your OpenVPN tunnel subnet. And add rule(s) on the relevant interfaces to allow the traffic.

I believe chroot isn't an option because of the script we need to run for auth to work and other tasks, but I may be wrong on that. Certainly worth testing if someone wants to try it.

The user/group set might be viable, but may also have script issues or route addition issues. Also worth trying, but may or may not work.

I spent  a few hours this weekend reading replies to similar problems and I found one reply that talked about Phase-2 entries.  Once I added an entry into Phase-2 on both psfA and psfB I was then able to connect to servers on lanB.

Thanks for the help and a great product.

The 0.0.0.0 thing was automagically added by the pfSense code (filter.inc 2.1-RELEASE). It is not needed - it was changed to 0.0.0.0/32 in GitHub recently then removed altogether by this commit:
https://github.com/pfsense/pfsense/commit/992324efad8f8c2c8144619e8c7681458560cd16
So you can ignore it - no special NAT rule needed for that.

Normally a reboot is not required for any pfSense config changes, including setting up VPNs… But it is so long since I used 2.0.1 I can't be sure if there were some things that did not always work on-the-fly.
Certainly in 2.1-RELEASE I setup and reconfigure OpenVPN servers and clients without needing to reboot - the system changes all the routes... on the fly.

Thanks.  I implemented the solution today.  During the Holidays it is near impossible to gain access to/leave our building due to the City area being extremely busy for shopping.  As a rule we work remotely for this week, however I moved the PBX to another more manageable and secure network.  The work we do is similar to a NOC, but Tier 2 which is on call.  When persons try to contact the office it was difficult to get to my Staff members or the member needed to fix a problem.  My staff can now work remotely using their Cell, Yealink or PC Soft Phone to remedy issues when someone calls the office PBX.

Thanks to you Jimp for guidance and showing me/us how to patch the GUI  issue and also to sscardefield….a fantastic job of putting the step by step guide together showing the creation of Certificates for OpenVPN both with and without User Authentication.  This actually got me to understand the process better than using the wizard.  Thanks to everyone else who participated in this thread as well.

Yes.  Anyway, don't worry about it.  I moved back to the old IP a few days ago, it's working fine ever since and I've moved on to other projects.