DA On-Prem -> OCI Journey when UR on a Budget --aka Cheep like Me - Part 4 - The Secret Sauce: PFsense Config
Part5: Da PFSense Configuration.
Ok now that you have the pfsense and the Oracle Linux Vboxes on the same subnet. You should be able to pull up the PFSense dashboard on the Oracle Linux Machine’s browser. Note that the ip address is 192.168.2.1. So let’s just take a look at the Dashboard first:
A
few things to note here:
1> the Oracle Linux Box is reported to be @ 192.168.2.77 – which is the IP address assigned to it when the Oracle Linux Box was created.
2> the Interface are the same as assigned on the pfsense (WAN,LAN and OPT1) Note the subnet differences between the WAN and the others. So you can see that the pFSense can get to both the outside and inside internal network. Again, this emulates an on-prem datacenter.
Before we go through the configuration, lets look at the final result first. So from the dashboard above, go to the top menu bar and select Status → IPSEC. As below:
So, after exploding the blue ‘Child SA entries’, you can see all the configurations that have been performed.
Ok, a few things to note.
1> there is only one tunnel in this demo (tunnel1). Look a little closer at con1000:
a> the Local IP is the LAN and OPT1 IP in the PFSense console – this is the LAN IP of the
pfsense Virtual Machine.
b> the Host IP is 192.168.1.73 – this is the WAN address that the internal pfsense machine routes to in order to get to the outside world via the Bridged Network Card configured for it in Part 3 of this series.
c> Note the remote ip is 193.122.176.97 – this is the tunnel gateway IP in OCI
connection. This will change upon re-establishment of the tunnel.
d> Note that the tunnel is up! (the green ESTABLISHED)
2> Child SA connections for con100000. A closer look:
a> The local subnet matches the CIDR range on for PFSense.
b> The Remote connection is using the CIDR 175.25.102.0/24 which is the subnet CIDR range configured in Part 2.
c> the Child SA confirms that the local ip and the cloud vpc ip are talking. Just to confirm, let’s ping from the Oracle Linux Box with an ip of 192.168.2.77 to the compute instance created in Part2: 175.25.102.15:
Bingo (was his name-o)
Cool huh.
Ok so now you know it works. But How did we get all this spaghetti to work (it seems that way because of all the different components that are required to get it all to work – like I said, most of the presentations and How-to’s I have seen leave a lot out. I hope find this easier to follow.
Ok so while configurations in the above parts is critical (you gotta get all that right!). The secret sauce is in the PFSense configuration. There are a few parts to this:
#1 – The IPSEC Tunnel Configuration:
This is the, let’s call it level 1. This is where the WAN interface makes its connection to the cloud tunnel configured in Part 2:
So, on the main Dashboard, go to VPN→IPSEC→Tunnels. Hit the pencil like above and you will see the required configurations:
Ok, some important points:
I. The First Section: General Information
1> The Key exchange version must match what you have selected for the Tunnel configured in Part 2. To confirm, login to our cloud tenancy, use the following sequence : Networking
2> Internet protocol is set to IPv4 (default).
3>the interface is the WAN.
4> the remote gateway is the tunnel1’s IP address you configured in part 2! Get this right or it will never work!!
II. The Second: Phase 1 Proposal (Authentication)
A few points here:
1> Authentication Method is a Mutual Psk (or shared key -uses the highlighed shared key you provide (get this from ur OCI tenancy).
2> My Identifier – the Lan Internal IP (192.168.2.1)! Check Part 2’s Console screenshot above. This threads the needle to ur internal network.
3> Peer Identifier: the Tunnel’s ip address created in Part 1
III. Phase 1 proposal (The Encryption Algorithm).
Most importantly the DH Group MUST match OCI’s DH Group here! To confirm n OCI,
Here is where you find it:
III. The Rest of the Phase 1 config:
Leave all the rest default but ensure that the Dead peer connection detection is selected.
IV. The Phase II config
This is the configuration for the tunnel between the internal network (Vbox Network) and the OCI VPC network/sub-network.
NOTE: In this demo, the Mode is Routed VTI. This can do point-to-point or nework depending n the entry. Here is an example of point to point:
note that address is used not ‘network’ so the resolution is a specific ip address.
And so the status point to point is established:
But what if we need a cidr range instead of point to point? Let’s change the setting from IP Address to network:
Here is what that looks like:
What is the whole PHASE1 and 2 look like now:
See the local and remote subnets in phase 2? this means other machines can be added to that subnet and connect to each other. All the sudden, there is an enterprise configuration…
Final test: lets ping the Compute on the cloud from the Oracle Linux machine using this new configuration:
Bingo Again!!
V. Don’t forget the Firewall settings. From Beginning to end.
1. create a gateway for routing traffic to the OPT1 interface (only what needs to be input is below:
Choose the Opt1 interface. Give it a name (gw1: More on this later in the firewall section) use IPV4. Keep gateway dynamic.
2. Interfaces. Well, enable all of them (WAN, LAN, OPT1). On LAN, set the static to the CIDR in the Pfsense console (see part 3 above for that LAN setting – its 192.168.2.1/24.)
3> Firewall. Key here is to look at the ‘blue’ column for stats. I’ll tell you whats live or not. Look under ‘Rules’ in the Firewall dropdown menu at the top of the page. Select it. You will see a WAN,LAN and IPSEC. Let’s take a look at each:
WAN: not really an issue all is wide open here but notice the third entry has ‘0’ bytes...why?
If you look at the configuration, you will see that it blocks RFC networks (e.g. 192.168.x) since
the internal is set to that , this makes sense. So no issues here main thing you want to do is not burden the WAN with keeping up with internal traffic, that’s for the LAN to do.
LAN: Ok a few things here:
First, firewall rules are activated from top to bottom. What this means when a rule is above another, then it takes precedence. So let’s look @ the below:
First any incoming traffic on ports 443 or 80 (ssh) is allowed. If you look at the ‘blue’ states column, you can see the traffic coming in through this rule.
The second rule is for any TCP traffic from OCI → LAN. But wait! No traffic indicated
in the ‘blue’ column...why? TCP is not encrypted traffic (that would be TCPS traffic). So that makes sense.
The third rule is an ‘ingress’ rule, allowing traffif to flow into the internal network fromOCI VPC (note ALL traffic on that 175.25 CiIDR! Not just the subnet of the VPC where the Instance we created in Part 2 was done. Note the gateway and the sprocket and bullet icon in the rule -this means traffic is logged. So if yo looked at the debugger, you would see detail on the traffic. Infact, If I pinged, the OCI compute from the Oracle Linux Virtualbox, I would see the ‘blue’ state increase in traffic. So the rule is indeed being used.
The fourth rule is for any other traffic that is IPV4. So...do we need rule three? Probably not since the the Source is LAN and the destination is anything. But I wanted to demonstrate the control of the firewall in that rule.
Finally the IPSEC: basically wide open:
you will probably want to lock this down but that is ur call.
So at this time, You have the status as everything is up and good.
Next time...Hey we only have one tunnel up...I will configure the part two...
time for a cigar after all that crap.
Comments
Post a Comment