After the launch of IPSec over FastConnect, a deep dive approach blog post I received many questions regarding the new security feature integration in a Hub and Spoke architecture. A very interesting question which needs a special attention. A special attention because the Hub and Spoke architectures are one of the most used by our customers.
So, how we can integrate the new security feature in a Hub and Spoke architecture? What are the points that needs configuration attention and what are the expectations? Finally, can the IPSec over FastConnect integrated in a Hub and Spoke architecture? Let's find out!
It is very important to have the prerequisites in our pocket. A very good start is to analyze and understand the above posted blog post. We will use the same networking architecture like in the first blog dedicated to IPSec over FastConnect, slightly modified to include the Hub and Spoke part. The networking topology that we will use is listed below:
Inspection VCN was added to the topology. In the Inspection VCN the firewall cluster is located. The scope is for the traffic that needs to be sent encrypted and non-encrypted to be monitored by the firewall cluster at 192.168.2.4.
The FastConnect VC configuration we have in place is for "All Traffic", this means encrypted and non-encrypted traffic can be handled. As in the previous blog post, we will analyze the architecture from the routing configuration and verify if it is possible to integrate the IPSec over FastConnect in the overall Hub and Spoke topology.
Let's explore the traffic direction depicted by the red arrow, noted 1.
The Workload VCN DRG attachment route table contains two static routes (to encrypted and non-encrypted on-premises networks):
The traffic that needs to be sent encrypted is first received by the Inspection VCN. Sure, for the firewall cluster to receive the traffic we need to attach the DRG VCN route table with the following entries:
After the traffic is processed by the firewall cluster is sent out and it is reaching the DRG Inspection VCN attachment. Now, let's follow the green arrow, noted 2. The route table for the Inspection VCN DRG attachment contains the following routing entries:
Based on the above route rule, the unencrypted traffic is sent to the OCI IPSec service defined using the VPNaaS configuration process at 10.10.0.1. Here, the traffic is encrypted resulting an encrypted IP packet where the visible source and destination IP addresses are 10.10.0.1 and 172.16.0.10 (representing the IPSec tunnel head ends). Let's continue the logic.
The IPSec service is delivering the encrypted packet to the Loopback attachment. How the Loopback attachment route table looks like? Let's find out:
The encrypted traffic is sent through the FastConnect Virtual Circuit to reach the on-premises host at 172.16.0.27.
An interesting poit is to analyze the response (or the traffic initiated from on-premises). This will conlude the use case and will provide the full clarity we need.
Once the 172.16.0.27 responds or initiate a new session to OCI at 192.168.1.3, the traffic will be encrypted by the on-premises firewall and send over the FastConnect VC, green line noted 3. The traffic arrives at the DRG and it is using the FastConnect VC attachment route table. The FastConnect VC attachment route table contains the following entries:
Remember that the traffic received is encrypted and the visible IP addresses are only the IPSec tunnel head-ends. The red marked route will be used for forwarding.
Based on the route above, the encrypted traffic is sent to the Loopback attachment, then to the IPSec service for decryption and the decrypted traffic is looped back to the DRG on the IPSec attachment.
The IPSec attachment has the following route entries in its associated route table:
That is interesting, the decrypted traffic (where the original source and destination IP addresses are visible) is sent to the Inspection VCN for analyze and from there to the destination OCI VM, the red line noted 4:
Conclusion: for the traffic that needs to be sent encrypted, the OCI firewall cluster will "see" only the traffic before encryption and after decryption:
Question: why do you think the packet capture on the OCI Firewall shows two ICMP requests and two ICMP replies each and every time?
The above packet capture on the three key devices proves that the IPSec over FastConnect can be easily integrated in a Hub and Spoke architecture.
For the non-encrypted traffic, the Workload VCN DRG attachment will use the following route entry from its associated route table:
After the traffic is analyzed by the firewall cluster and sent out, the Inspection VCN DRG attachment route table will be used for forwarding:
Now, we can see the difference, the 10.0.0.10/32 has the FastConnect VC as a next-hop attachment, the traffic is not passing through the IPSec crypto engine.
The response is sent back from 10.0.0.10 and the traffic is traversing the FastConnect VC. The non-encrypted traffic arrives at the DRG and the DRG FastConnect VC attachment route table is used. Let's analyze the route table content:
The interesting part is that when the FastConnect VC is set to "All Traffic" we can add static routes as per our requirement, in our case the non-encrypted traffic to be inspected by the firewall cluster.
Finally, the traffic is forwarded to the OCI VM after all the security is enforced by the firewall cluster, using the Inspection VCN DRG attachment route table:
That concludes that the second use case can be achieved. To prove that the non-encrypted traffic is really sent non-encrypted, let's perform a packet capture:
And we have the evidence that the new IPSec over FastConnect security feature can be integrated in a Hub and Spoke architecture.
As a last part, can you tell me what will be the changes in the routing if the FastConnect VC is set to "TransportMode"? Just let me know your thoughts. Enjoy!