That all looks OK. The only potential issue I can see is that the local LAN behind the server is 192.168.1.0/24. If the place the client is connecting from is also 192.168.1.0/24 (or includes that), then the client will try to talk locally to 192.168.1.0/24 when it should be sending that traffic across the OpenVPN link. If that is an issue, then, if you can, try connecting from somewhere with different private address space and see if it works. In the long term, it will pay to change the LAN subnet behind the OpenVPN server to be some different private address space - http://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces - picking a "random" chunk of 172.16.0.0/12 is likely to avoid clashes with the local coffee shop WiFi.

I was successful editing using the GUI. Unfortunately, the OpenVPN windows client can't parse an IPv6 address and can't resolve a host with only an AAAA record. Fri Nov 14 19:27:33 2014 RESOLVE: Cannot resolve host address: xxx.xxx.duia.us: The requested name is valid, but no data of the requested type was found. Fri Nov 14 19:27:38 2014 RESOLVE: Cannot resolve host address: xxx.xxx..duia.us: The requested name is valid, but no data of the requested type was found. Off to the OpenVPN forum…

Do a quick search of your config file for "192.168.1" - that will quickly show where are the other references to things in 192.168.1.0/24 And of course you have to change any clients with hard-coded IP addresses (maybe some Windows servers, a managed switch, an AP or 2, a print server lying around your LAN…)

I had this same problem (and more than a year later). The solution I found was to generate a new bundle using the OpenVPN Client Export Utility package, and switching the "Verify Server CN" setting to "Automatic - Use verify-x509-name", since using tls-remote is now deprecated. The resulting .visc bundle worked perfectly. This was on the latest version of pfSense (2.1.5), so YMMV if you're running an older version.

Yes I could restrict more NAT rules, but I have many networks behind pfSense A, so I prefer all open here:–)

@Derelict: Add LAN B's subnet to the IPv4 Local Network/s on the remote access server on pfSense A. Add the Remote Access subnet to the IPv4 Local Network/s on the Site-to-Site server on pfSense A going to pfSense B. You will need to be sure the Remote Access subnet and pfSense B subnet are both passed on the rules on the OpenVPN tab on pfSense A. I think that's all you need to do to get this working. You might consider binding interfaces to the OpenVPN server instances on pfSense A and B to give you more control but I don't think it'll be necessary to get this project done. Thank you !!! and sorry for the delay on getting back to you.. For this really to work I had to do 2 more steps to yours: 1 - On the PFSENSE B, on the Site2Site Client config, add to the 'Remote Nets' Option the Network from the Roadwarrior VPN connection from PFSENSE A, in conjunction to the LAN A network. 2 On the PFSENSE A, on the Site2Site server config, add to the 'Remote Nets' option the network from the RoadWarrior VPN connection from PFSENSE B, in conjunction to the LAN B network. With Step 1 I'm able to access LAN B from INSIDE Roadwarrior VPN on PFSENSE A. –> My original request <-- With Step 2 I'm able to access LAN A from INSIDE Roadwarrior VPN on PFSENSE B. Inside the FIREWALL->OpenVPN rules, I have an ANY-ANY rule. Thank you all for taking the time to help us solving this issues. If, you guys see fit, I can do an HOW-TO for this type of setup, just let me know. Best regards. Jorge Gomes

Thank you, that worked perfectly! Cheers

If you have the right routes on either end to reach LAN to LAN you should be able to reach the LAN IP of the DD-WRT box, unless they do something odd with routing in that context. I seem to recall seeing that work before though.

Any one can advice? Thank You Best Regards

Ok, it should be easy. Create Alias_VPN inserting 192.168.1.220 & 192.168.1.225. Create Alias_LAN with 192.168.100.0/24 and 192.168.1.0/24 I assume you have used the "route-nopull" option, you have 2 Gateway, 1 for clear net and 1 other for the VPN tunnel. I should start with Manual Outbound NAT with 2 simple rule: VPN_WAN      Alias_VPN  *  *  *  VPN_WAN address  *  NO WAN      Alias_LAN  *  *  *  WAN address  *  NO Then you should build the firewall rules, the order is important, the rules are processed in top-down order, the first which meets all conditions is applied. Firewall rule on interfce 192.168.1.0/24 TAB PASS –- IPv4 *  Alias_VPN  *  *  *  VPN_WAN_GW  none  //IPs in Alias_VPN will use gateway VPN_WAN_GW (or whatever you named)// PASS --- IPv4 *  Alias_LAN  *  *  *  *  none  //IPs in Alias_LAN are allowed and will use default gateway, this rule should allow communication between clients on different subnets) Firewall rule on interface 192.168.100.0/24 TAB PASS --- IPv4 *  Alias_VPN  *  *  *  VPN_WAN_GW  none  //IPs in Alias_VPN will use gateway VPN_WAN_GW (or whatever you named)// PASS --- IPv4 *  Alias_LAN  *  *  *  *  none  //IPs in Alias_LAN are allowed and will use default gateway, this rule should allow communication between clients on different subnets) Let me know if works.

So I need to set the client computer to do that? I've been trying to find info on how to do that, but all the tutorials out there cover linux, and my clients are Windows.

Or you need to statically assign based on topology net30.  I think it's something like ifconfig-push 10.10.0.9 10.10.0.10. But if topology subnet works it's the preferred mode.  net30 is being deprecated I think.

What do you mean by prioritize between the interfaces? You can shape traffic going out an interface.

Looks like sha256.