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.

I ran a packet capture on a client and the server, and the clients are sending data, but no traffic is showing in the packet capture on the server. Literally none; the box is blank after I stop the packet capture on the OpenVPN server interface.

What I had posted would work? changing every server? Yes, you can put the servers at the branch offices, like your 2nd diagram, and have 4 clients connecting out from the main office. But myself, I make my OpenVPN servers listen on a different port to the default (1194) anyway, and it is no problem having 4 of them listening on 4 different port numbers.

Yes, you can use a single site-to-site OpenVPN server with Certificates, have multiple site-to-site OpenVPN clients connecting in and use Client-specific-overrides to tell the server which remote office subnets are reached down which client. Or you can make 3 separate servers at main office using pre-shared keys, listening on 3 different ports. If you only have a couple of remote offices then it can be easier to use the pre-shared keys method and have a few servers, rather than bothering to make the certificate authority, certificates,…

Well, the firmware update solved the VPN and aPinger issues. My long term to do list includes switching this router over the straight pfSense, but all is well for now. Andy

Thanks heper! I'll try that.