Today I’ve spent a little bit of my time to figure out how to move away from policy-based VPN in favour of a route-based one instead. I was eyeing the concept for a while now and wanted to use it in my home lab to solve a couple of problems I was trying to turn a blind eye to. Without further ado, please follow the guide below to set up a route-based VPN between a StrongSwan-based peer (on RPi 3+) and an OPNSense appliance.
Route VPN traffic between two 3rd parties using CheckPoint
Let’s imagine we have two separate VPNs established to some 3rd parties and they’ve asked us to allow them access to each other’s resources.
This guide will show you how to easily allow routing between VPN communities and what our 3rd parties will have to do in order to get the connection up and running…
Deploying NGINX-based web server | Part 1 – Installing Debian
This is the first post of upcoming series of posts about servers – their deployment, automation, load-balancing and configuration. In this introductory bit, we will focus on deploying our first Debian VM.
LibVirt – overcoming problems with internal routing (aka some features I wish I knew about earlier!)
This article will be expanded with new issues/workarounds if I manage to find any.
Strange title, isn’t it? Well, the title is as strange as what I’ve managed to find when creating my last article for you, folks!
Our first network behind CheckPoint firewall – basic NAT and Firewall policies
My previous post (link) covered creating a CheckPoint R77.30 VM and a simple NAT’d (NATed/NATted? I don’t know!) network. In this example, we’re going to stray away from scenario. We’re going to create a routed (link) network, as well as one isolated (link) network and add two NICs to our VM so it connects to both networks. Additionally, we will need one Linux VM (I’m going to use Debian) to act as a web server.