They still need to know to route that network to you.

Just an indication that such a configuration is possible with pfsense would be extremely helpful.  Thanks

179.142.X.X = 179.142.0.0/16 179.142.15.X = 179.142.15.0/24 If you're unsure use a CIDR calculator like http://www.subnet-calculator.com/cidr.php.

Got this working now. Dns was not.set by pfsense without a static mapping. Once that was sorted it worked. @johnpoz thanks for pointing me in the right direction and confirming the basic vlan config was somewhat.ok. /d

It should be possible. But how to do depends on the stated routes. If pfSensebox1 is the default gateway in the LAN and you push the default route or the route to LAN network to vpn clients (redirect gateway), it should work without adding routes. If that is not given you need to add routes… @finadmin: Should this be possible when client1 has a route to 10.80.0.0/16 via 192.168.1.245 + pfSensebox1 has a static route from 192.168.1.245 to 10.80.0.0/16 ? The client route is fine. It is only necessary if pfSense is not the default gateway in LAN. The second route on pfSense does nothing. You need a route on the vpn client for 192.168.1.0/24 pointing to the vpn server. This can be set by entering 192.168.1.0/24 in the "Local Network/s" box in the server settings. If you use the wizard for setting up the vpn server, this is set by default. Consider that the vpn clients firewall will block such access by default. So you have to open some ports.

@dmjar: Effectively the main issue is getting the traffic from a port forward (incoming from WAN) to actually go further than the PFSense box as currently it is not hitting the device in LAN2. So this should be solution for that already: @dmjar: I am assuming it is a Routing issue however I have tried adding the downstream router as a gateway and creating a static route for both the whole 192.168.2.0/24 range and alternatively just the 192.168.2.200/32 range in this example. Maybe you have done something wrong?

"My anti-virus connects to the database server using a public address" So its hardcoded IP or it uses a FQDN to access.  Hard coding IPs BAD… FQDN good! If you use FQDN its a simple host dns configuration to have that fqdn resolve to the rfc1918 address of your database server while inside.. And while outside you hit the public IP.

Hi johnpoz Thanks for your reply. Yes on the Network 10.0.x are hosts. But this are two different customers and I don't can change the Subnet 10.200.201.0/24. I have draw another picture. I think, we need a policy based routing with the possibility to define Gataways on the IPSec Interface.  

I‘m ashamed to tell this but after setting up the clients, the interfaces, the gateway and the Nat-rule I simply reboot the firewall. Not a valid enterprise option but at home … It always does the trick, even when I have to rectify some errors after the reboot.

Thank you all for the reality check! I am turning up a new firewall and no rules existed except for test rules. Since everyone validated that ICMP is treated the same as TCP/UDP traffic for PF markings (route policies) and the placement of firewall rules matter. I looked at my test rules… It turns out I had an ICMP echoreq rule for all interfaces with a destination of any. This rule was there for diagnostic purposes. Changing the destination to "This Firewall", maintained diagnostic purposes and now the route policies are working as expected! Thank you

Hi, did you solved? Now the version 2.4 is out also but nothing seems changed

Glad to hear - better in bridge mode anyway ;)

Captive Portal https://doc.pfsense.org/index.php/Captive_Portal

never touch a running system. Lots of luck with that.

Note that if the resolver is in forwarding mode and DNSSEC is enabled, things can appear to break randomly if the forwarding servers do not properly support DNSSEC so it is generally best to disable that in forwarding mode. Even the popular ones like google and opendns don't do it right.