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.

If you have a TLS authentication key configured on the server, you need the same key on the client.  If not, you don't.

pfSense stores the TLS authentication key as clientX.tls-auth and serverX.tls-auth.

This is used in the server using tls-auth /var/etc/openvpn/server2.tls-auth 0

I guess if your CentOS config is doing something similar, you'll find the key in there.  If you don't need a tls-auth key to connect via CLI, I guess your walkthrough didn't configure TLS Authentication and you need to turn it off in the client's GUI.

Why not just use pfSense as your OpenVPN server?

If your VPN is set to user auth, that's what it's going to use.

I've never done this but on 2.1.5 I'd use Remote Access ( SSL/TLS ).

It's working.
I've spent many hours on that and what helped was a pfSense reboot :)

I also followed this tutorial:
http://www.derman.com/blogs/OpenVPN-Firewall-Setup