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?
