As a big fan of automation and Ansible I was pretty unhappy when I found out the default “user” Ansible module was not able to handle user management in a way that GAiA likes – since the users need to be added to the config, I started looking at ways to either bring the functionality to the “user” module, or create a separate module that could handle this task.
VLANs allow to introduce network segmentation to our environment. After we make sure the machines sit in separate VLANs, we might want to provide some sort of inter-VLAN routing as well as some sort of a firewall (UTM) that will make sure only desired traffic gets through from VLANs to VLANs.
Vendors generally implement VPNs in a way where phase 1 and phase 2 settings are defined per VPN peer (aka 3rd party we will be establishing the VPN tunnel with) which gives us the flexibility in regards to subnets we will be using for phase 2.
CheckPoint, however, does things a little bit differently which can sometimes give us couple of hours of pain when troubleshooting. Learn how to force CheckPoint to switch to the “traditional” way of configuring phase 2 settings in this guide!
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…
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.