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. I might create an article on how to create one and edit this article after. For now, however, you will need to stick to some other sources.
In the end, the topology is going to look like this:
It’s a very basic example. If you happen to use CheckPoint in production at work, your topology will obviously be different. In this example, we’re going to look at two scenarios:
- Without NAT – This is usually the case when we aren’t exposing our server to the outside world and it’s only accessed from internal network
- With NAT – When we want to expose our server to outside world but our internal network is hidden behind our gateway’s (TD-FW-001) IP address
Sometimes we simply don’t have to use NAT. For example, if our server will be only accessed from the internal network and appropriate routing is provided, we shouldn’t need to NAT unless for some very specific reason.
This scenario is very simple as it requires no extra configuration of NAT policy; everything should work out-of-the-box. Firewall will (and definitely should!) require at least some configuration. Why should it require extra configuration?
Well, it all depends on our already existing ruleset. It’s considered a standard to create a DROP ALL rule at the end of every policy to ensure that all traffic we don’t make exemption for is dropped. It’s better to be asked to add an extra rule rather than “Why is our RDS server accessible from the guest network?”. I know this example might be a little bit extreme, but trust me. Better safe than sorry!
Enough talking! Since we want to allow our host (or the whole 192.168.200.0/29 subnet) to access our web server, we first have to create an object representing the 192.168.200.0/29 network:
and one more object representing our server:
Now we can create a rule with our net_192.168.200.0_29 object as Source and WEB-SRV-1 as Destination. Services should be HTTP and HTTPS (ports 80 and 443). Action should be set to accept and Track to Log.
As you can see, I have also added ssh to the services. It’s there to make it easier for me to administrate the server in future (I try not to use console view in virt-manager until I have to).
Anyway. Let’s push the policy and see if it works!
And the browser (from host – 192.168.200.1 to WEB-SRV-1 – 172.16.1.100):
If we want to hide our server behind the gateway’s IP, we have to specify NAT rules that will translate the addresses first. Then, we have to create firewall rules slightly different from what we’ve done in a scenario where NAT wasn’t used. Trust me, it’s quite easy!
Let’s get going and head to the NAT policy:
By default, we won’t have much there:
Before we add any rules, let’s make sure we have an object representing our Internet facing interface of the gateway:
Add a new Host object (for example please scroll up and see how we created the WEB-SRV-1 object):
Now, let’s create a new rule at the top of our rule base and configure it like this:
We will need another rule but for now lets focus on explaining this one. As you can see, the Source is set to Any, Destination is ext_TD-FW-001 and Service is http. In the Translated Packet section the Destination is set to WEB-SRV-1. What does it all mean? It means that anything trying to access 192.168.200.2 (ext_TD-FW-001 aka our gateway’s external IP address) on port 80 (HTTP) will have their traffic NAT’d to WEB-SRV-1 (172.16.1.100). Pretty simple, isn’t it?
Now, what if our server needs to access outside world? We add another NAT rule, obviously!
As you can see, rule 2 basically specifies that any traffic that our WEB-SRV-1 host tries to pass on port 80 will be hidden behind the gateway’s external IP address (192.168.200.2 in our case).
Why is this required? Well, CheckPoint appliance will do exactly what we tell it. If we don’t specify what happens with traffic going to, for example, outside world (Internet) then the packets will leave CheckPoint with source IP address from the private network (172.16.1.100) and won’t ever be routed back (since it’s private network address. Everyone can have server with the exact same private IP address!).
Okay, enough talking. Let’s sort out the firewall rules now!
We’re going to need a single rule to make it all work:
To describe what it does: Allow everyone to access 192.168.200.2 on port 80 and log the hits. That’s it. Plain and simple!
Now, let’s test it out!
Woohoo! Fun fact: the web server can STILL be accessed on 172.16.1.100 address. This is because our routing allows us to find path to both of these addresses. Those poor souls from the Internet, however, can only access it on the external IP address you specify in NAT rulebase (192.168.200.2 is still private, remember?).