Terminate VPN in DMZ or internal network?
-
Our firewall is a Cisco ASA which connects to both our DMZ and our internal network. We'd like to use pfSense to create a VPN to our internal network which we can easily turn off when not in use (it will be turned off 99% of the time). However, is it best practice to have the pfSense sitting in the internal network, or is it better to someone route it through our DMZ first (probably using another pfSense)?
Most of my career the rule was nothing from the internet ever goes directly into the internal network.
-
@Zoltan
Scenario 1
FYSA:
PFSENSE WAN IP: 77.77.77.77
PFSENSE P2P IP: 192.168.255.2/30
ASA P2P IP: 192.168.255.1/30
VPN USER SUBNET (example): 172.16.99.0/24
YOUR CORP NETWORK: 172.16.2.0/24THIS SCENARIO ASSUMES YOU HAVE MULTIPLE WAN IPs, A VPN SETUP [OPENVPN or IPSEC] on PFSENSE, and A CORE EDGE ROUTER/SWITCH or a WAN AGRREGATION SWITCH BEFORE YOUR ASA that your organization controls!*
Hey there Zoltan. I would suggest making your VPN a separate zone on the ASA that will have access to DMZ and CORP zones.
I have done this a million times. If your firewall is connected to an Upstream aggregation switch (aggregates wan connections and customer connections), then I would suggest you connect an interface to your PFSENSE box and assign it a WAN IP so that its reachable from the outside world.
On the same PFsense box, you should take another interface and attach it to your ASA. Give this connection a simple P2P address like in the 192.168.255.252/30 network.
On your pfsense, add a static route pointing to your network i.e.
Target network: 172.16.2.0/24
Destination: 192.168.255.1Create rules you'll need for expected traffic to flow FROM pfsense cpn client network 172.16.99.0/24 TO your corp net 172.16.2.0/24 and vice versa. If you would like to permit everything just to get setup, that's cool too.
Since your pfsense box got the ip 192.168.255.2, your asa will get 192.168.255.1. You'd go on your asa and create a static route i.e. that says:
ip route 172.16.99.0 255.255.255.0 192.168.255.2
You would then configure your security levels and necessary rules for traffic to flow to the CORP NET zone. NO NAT SHOULD TAKE PLACE ON THE ASA. It setup just like any other seemingly local network segment.
That should really be it.
If someone were to VPN into your PFSense host and receive an address in the 172.16.99.0 range and your rules are correct, traffic should flow.
Scenario 2
FYSA:
PFSENSE WAN IP: 77.77.77.77
PFSENSE P2P IP_RED: 192.168.255.2/30
ASA P2P IP_RED: 192.168.255.1/30PFSENSE P2P IP_GREEN: 192.168.254.2/30
ASA P2P IP_GREEN: 192.168.254.1/30VPN USER SUBNET (example): 172.16.99.0/24
YOUR CORP NETWORK: 172.16.2.0/24RED* is untrusted traffic that will receive forwarded VPN connection requests from the outside world via 1:1 NAT on the ASA.
GREEN* is "trusted" traffic that will only pass traffic for successfully authenticated hosts.
THIS SCENARIO ASSUMES YOU HAVE AT LEAST 1 WAN IP and A VPN SETUP [OPENVPN or IPSEC] ON PFSENSE!*
On the pfsense host there should be 2 free ports.
On the ASA there should be 2 free ports.Connect them both together.
Now, on the pfsense box, give one interface (the RED interface) 192.168.255.2/30
Give the other interface (GREEN interface)
192.168.254.2/30Create necessary rules to allow your VPN network 172.16.99.0 to access 172.16.2.0/24 (your CORP NETWORK) over GREEN interface.
Also create a static route such as:
Target network: 172.16.2.0/24 (CORP NET that lives on ASA)
Destination: 192.168.254.1 (ASA GREEN PTP)Create necessary rules to restrict the RED interface (i.e. reject all connection attempts to any port BESIDES what your VPN runs on...etc.)
If you would like to leave the rules wide open (allow any any) just for testing, that's cool.
That's pretty much it on the PFSense box.
Head over to the ASA and configure the RED and GREEN interfaces with 192.168.255.1 and 192.168.254.1 respectively. You should also create VPN_RED and VPN_GREEN zones if not created automatically. Your security level on the red and green interfaces should NOT be the same as your CORP interface!
Now, you want to PORT FORWARD outside connections from your WAN IP on whatever port your vpn uses i.e. 8739 or 500, 4500 TO your pfsense RED INTERFACE.
Create any necessary rules to accommodate the port forwarding. Also make sure that the rules are VERY restrictive.
Almost there.
I hope by now you configured the green interface with whatever rules you need to allow comms.
Now you need to create a static route that says:
ip route 172.16.99.0 255.255.255.0 192.168.255.2
If you want to leave the green interface open, that's ok AS LONG AS PFSENSE HAS RULES CONFIGURED to restrict the 172.16.99.0 net. Don't double configure ACL rules... you'll regret it later. Sometimes, less really is more. The risk is acceptable because its EXTREMELY short term, and the network that lives on green will only pass authenticated users. Best to make sure everything is working, then drop those ACL's on the green interface like its hot.
This is all off of the top of my head. I may have missed something.
If you let me know what model ASA you have, I could give you a sample config. I have an ASA-5555X config that you may find helpful.
Let me know if you have any questions. If you're open to it, we can skype/zoom and I can show you how this works in my lab.
FYI used to setup PFSense based FWs/VPNs for a branch of the DoD and a few 3 letter agencies until very recently.
As much as I like pfsense, I find OpenConnect works as the best Host-to-server VPN setup. If you'd like me to walk you through setting that up, let me know but FYI that solution will not require PFSense at all.
Cheers
With respect,
Regis -
@rmccall2k16 This is excellent, thank you very much. I need to diagram it out to make sure I understand it, and I also need to see if/how I can assign address in different subnets to the same ASA interface.
We're using ASA-5525X, and a sample config would be really helpful, thank you!
-
It will make more since if you see a diagram. I’ll create one tomorrow morning.
You don’t need to assign multiple addresses to the same interface.
In scenario 1, imagine the core edge of your network. Imagine you had multiple firewalls that all needed to share 1 or even 2 WAN connections. How would you go about it?
A) you put a managed layer 2 switch (I refer to as a wan aggregation switch) at the edge, connect your ISP connections to it via fiber or rj45. Once you do that, you can connect all of your firewalls to the switch and they can share that connection.
This scenario requires that the Pf sense box has a connection to the WAN separate from your Asa and another connection directly to the ASA.
We’re using 2 interfaces per host for a total of 4 interfaces. This results in two connections which is why I suggested two /30’s where two interfaces are in one /30 and two interfaces are in the other /30
B) everything from A, but a router instead of a switch in special cases such as mpls, atm, etc etc.
There are no overlapping subnets or any interface with multiple IPs on either the ASA or the pfsense host.
Scenario 1 is for more complex networks. Lol it’s ironic because it’s the easiest scenario. This scenario also accepts incoming client requests directly I.e. client requests do not have to pass through the ASA.
Scenario 2
Scenario 2 assumes you have 2 free interfaces on each host. You will connect the Asa and the pfsense host together through these 2 connections directly one to one. Each interface gets a separate /30 in a different network, so no overlapping there.
Basically you are handing off the vpn function from the Asa to pfsense. In my explanation above, 172.16.99.0 (VPN user subnet) lives on the pfsense box. The Asa does not know about any openvpn or IPSec specifics or any of that. All it knows is that network 172.16.99.0/24 can be reached via pfsense on the green interface with ip 192.168.254.1. A static route accomplishes that (depicted above). Now if we were talking packet inspection... that’s a whole other post hehe
Scenario 2 is for simpler networks, but a little more complex. All vpn traffic (client requests and authorized vpn user traffic) will pass through your Asa.
In both scenarios, the ASA is acting as a simple router that is (for our purposes) unaware that 172.16.99.0 vpn user network is a virtual vpn network terminated by pfsense. It only sees it as a vanilla (vanilla meaning plain/ordinary) network living off of an interface like any other.
I’m sorry if this sounds confusing. It’ll make more since when it’s drawn out on a Visio diagram.
By chance, are you familiar with Taclanes?