OpenBSD Firewall Lab

Introduction

In this lab, you will be working with OpenBSD. OpenBSD is a Unix based operating system. This means that it has many similarities and differences to other Unix based systems like Debian. Most base commands in OpenBSD are the same in Debian, and the file systems and other features related to IPs and routing are somewhat different. Additionally, OpenBSD has its own way of routing protocols, and packages and ports are sent to /usr/local. Although OpenBSD doesn’t use the same exact services that Linux services use, it has the same functionality. OpenBSD is also security-oriented; so, it can be used for implementing firewalls, securing network packets, etc. On OpenBSD, you will not be creating bird or ISC-DHCP servers.

Setup

Console into spokes 1, 2, and 3 and check to see if they can ping each other. Make sure they’re all using OSPF and have the appropriate neighbors before moving on to the next steps.

Download the fw-lab.img and fw-lab.xml files using the guide here:

and store them in /data. Shut down all the VMs that are currently running, except for the spokes.

For this lab, you can either choose the pass only vmbr0, or you can choose to pass individual vmbrs of 104 (where your “hub and firewall connect), and vmbrX (X is the vlan that your Internet connection is coming from which can vary).

In our case for individual vmbrs, you select your Internet vmbr first, and your vmbr104 second. Later on, we’ll connect vio0 to DHCP and give vio1 an internal IP address.

Edit fw-lab.xml, changing the src file (devices) path, vmbrs, interfaces, and slots as necessary, along with the KVM UUID as mentioned in the KVM Lab.

Now, define a VM using the fw-lab.xml file, start fw-lab, and console into it.

To change the hostname, edit /etc/myname.

Configuring Interfaces

For this section, there are two ways to configure our interfaces. The first section will go through how to configure interfaces if you passed individual vmbrs through to the VM. The second section will go over how to configure interfaces if you passed the single vmbr0.

Separate vmbr Interfaces

If you set individual vmbrs, when you run:

ship

You should see two interfaces (vio0 and vio1). Edit /etc/hostname.vio0 and /etc/hostname.vio1. Make vio0

dhcp

(simply write dhcp) and change vio1’s inet (172.30.104.1 255.255.255.252 NONE).

If you’re unsure about the subnet of the router/hub, refer back to the network diagram from the Static Routing Lab.

Now, restart the interfaces by entering the following commands:

sh /etc/netstart vio0
sh /etc/netstart vio1

Labeling Individual Interfaces

/etc/interfacedb.txt is a file used for organizational purposes when running ‘ship’. Insert or edit the VLANs to ensure that vio0 is your WAN interface (vlan11) and vio1 is your LAN interface (vlan104). For vio0, write ‘Internet_vlan:wan’ and ‘104:lan’ for vio1.

{
        'vio0' => '11:wan',
        'vio1' => '104:lan',
}

Single Parent Interface

If you set vmbr0, when you run ship, you will only see a single vio0 interface. To set up our interfaces, we will utilize vlans. Let’s set up our Internet access first.

We’re first going to set up our vlan with Internet access by editing /etc/hostname.vlanX where X is your vlan with Internet access, and making the file look like the following:

parent vio0 vnetid X
dhcp

Here we reference that our parent interface is vio0, very similar to what we did in the KVM lab with our DHCP VM and setting what vlan were are using with the vnetid. Then we are going to have a DHCP address.

Next, we will set up out internal interface that will connect to the “hub” by editing /etc/hostname.vlan104 and its configuration will look like the following:

parent vio0 vnetid 104
inet 172.30.104.1 255.255.255.252 NONE

And now we can bring up both of our interfaces:

sh /etc/netstart vlanX
sh /etc/netstart vlan104

Labeling Vlan Interfaces

You will still use /etc/interfacedb.txt to label your interfaces if you decided to pass a single parent interface, the format will look like the following:

{
        'vlanX'   => 'wan',
        'vlan104' => 'lan',
}

Testing and Adding Routes

Now, console into one of the spokes. Try pinging the hub and the other VLANs. If you cannot ping the hub, check to see if your switch/router is on and all cables are plugged in.

Now console back into fw-lab and type “routes” to check your routes. You’ll notice that on our spokes, there is a default route, but no route to go to our hub. We can fix this by adding static routes in order to test pinging to the internet. To add static routes to the firewall, run the commands:

route add 172.30.105.0/30 172.30.104.2
route add 172.30.105.4/30 172.30.104.2

However, a route added with a single command will not still be there after rebooting the firewall. To make sure that these routes save after a reboot edit /etc/hostname.vio1 (LAN interface). Add static routes to all of the networks under the hub in this file. Make sure the next step it set to the hub (172.30.104.2) from the firewall.

Example: !route add 172.30.106.0/24 172.30.104.2

Also, instead of writing out the full netmask next to the IP address, you could just write /30, /24, etc. depending on the subnet.

Make sure that the firewall is able to ping all of the spokes’ LANs and vice versa.

At the moment, the Router(hub) is communicating with the spokes about routes through OSPF, while the Router(hub) and firewall are communicating through static routing.

In the next part of the lab, we will be making the entire network communicate with OSPF, including the firewall. While static routes may work well for communications between the firewall and router in this scenario, this doesn’t mean that static routes are the best choice. OSPF does the same basic job as static routing, but it is much more efficient when setting up and expanding networks.

For example, if you were to add another firewall to this network with static routing, then you would have to add all of the static routes all over again. If you used OSPF to add another firewall, then you would just need to quickly set up OSPF on the firewall and it would be able to communicate with all the other devices on the network.

NAT Tables

Imagine that you had a device on your private network that wanted to connect to the internet. Your private IP cannot directly connect to the internet. In order to allow your private network to connect to a public network, a NAT (network address translation) table would be needed.

NAT tables work by translating a private IP address into a public IP address. So, the packets coming from your private network would change their source IP (originally the private IP) to the router’s public IP. Then, the router would add a new row in the NAT table that would map the private IP to its destination address (the public IP). Now, your device can connect to the public network.

We’re now going to create a NAT table for our LAN’s IPs.

Go back into fw-lab and create the firewall rules by editing /etc/pf.conf. Delete the extra “ext_if” line if more than one are there. Move the “fwip external IP” line below the “ext_if vio0” line and save and exit.

Run “fws” to restart the firewall.

Your firewall should have automatically obtained an IP via dhcp on its WAN interface.
Add that IP address’s subnet to /opt/shared/pf/noc.conf. For example, if your firewall’s WAN IP is 10.20.30.45 with subnet mask 255.255.255.0, you would insert “10.20.30.0/24”.

In /etc/pf.conf, set $fwip to its WAN IP address, ext_if to its external interface, int_if to its internal interface, and lan to its LAN subnet (172.30.104.0/30). These macros that don’t actually configure the firewall, but are useful for editing the firewall rules without having to change the IP in multiple places.

In /etc/pf.conf, confirm that NAT (##outbound NAT) says

match out on $ext_if from $lan nat-to $fwip

Once done, restart the firewall again. If set up correctly, you should be able to ping the internet from the firewall’s LAN IP and the router’s WAN IP. To ping the internet using the firewall’s LAN IP, do

ping -I <source IP> <destination IP>

Afterwards, try pinging the internet from the router. You’ll want to make sure that the router(hub) has a static default route to the firewall.

Cisco

ip route 0.0.0.0 0.0.0.0 172.30.104.1

Juniper

routing-options {
    static {
        route 0.0.0.0/0 {
            next-hop 172.30.104.1;
        }
    }
}

Back inside the firewall, create a new table by editing “/opt/shared/pf/lan.conf.” List all of the IPs for all of the LANs that you want to include (the screenshot below is an example but is not what you should enter!). Any pings with a source address in the listed ranges will be NATted and consequently get internet, so be sure to include all of them

Now go back to your /etc/pf.conf file. Add this line where the tables are defined:

table <lan>           persist file "/opt/shared/pf/lan.conf"

At the bottom, change the “match out” LAN to use the table instead of the macro:

match out on $ext_if from <lan> nat-to $fwip

Save the file and restart the firewall. Test your connections again by pinging from your spoke’s LAN to the internet.

Setting up OSPF from the Router to the Firewall

Remove the default static route to the internet off of the router. Make sure the router isn’t advertising that it has the route to 0.0.0.0. Then, depending on whether you are using Cisco or Juniper, you can make the following changes:

Cisco

ip ospf cost 100
ip ospf hello-interval 6

Juniper

ospf {
    area 0.0.0.0 {
        interface irb.104 {
            metric 100;
        }
}

Now, OSPF will be listening on vlan104.

Create a loopback address on the firewall by editing /etc/hostname.lo1. Inside this file, type the following command:

inet <loopback ip> <subnet mask> NONE

Run “sh /etc/netstart lo1” to initialize the interface. If that doesn’t work, try changing the file permissions to 700 by typing “chmod 700 /etc/hostname.lo1.”

If you cannot remember the loopback, be sure to check the spokes and bird routers.

Then, run ship to make sure the loopback works.

Go into /etc/ospfd.conf. Inside this file, type the following:

router-id <loopback>
fib-update yes
area 0.0.0.0{
    interface "vio1"{
         hello-interval 6
         router-dead-time 24
         metric 100
    }
}

Now, we have to change the file permissions for ospfd.conf.

ls -al /etc/ospfd.conf

This command lists the file permissions for the owner, users in the same group as the owner, and everyone else (global). We only want to give the owner read and write permissions and everyone else no permissions for security reasons. To do this, we type:

chmod 600 /etc/ospfd.conf

Now, we need to edit /etc/rc.conf.local and add the following:

ospfd_flags=""

It’s important to set the ospfd_flags to “” because it allows the daemon to run at its default. If NO was defined instead, the daemon would not run at all.

Run

/etc/rc.d/ospfd start

Afterwards, we need to go through and delete all the static route off the firewall. You can list the OSPF neighbors by running one of the following commands:

Cisco

show ip ospf neighbor

Juniper

show ospf neighbor

To be able to ping the loopback address of the router, you need to add is as a passive interface in OSPF; you don’t need every interface in OSPF to be active, usually just 1 will work in most environment. We will get into why this is important more during the Tunneling with Firewalls Lab.

Cisco

interface "lo1" {
   metric 100
   passive
}

Juniper

area 0.0.0.0{
    interface "lo0"{
         passive;
    }
}

Try to ping 8.8.8.8, the external IP of the firewall (in this case 192.168.11.17), and 172.31.0.9 (Firewall’s loopback address) from a spoke’s LAN.

These pings should be successful, however pinging the firewall’s loopback address is only working since it is going through the default route to get to the firewall, and the firewall isn’t actually advertising that it has the route to the loopback address over OSPF. While this might work for simple networks, it would become a problem for larger networks with two or more firewalls since only one is going to have the default route. We want to make sure that loopback is included inside OSPF. So, to make the firewall advertise its loopback through OSPF, edit /etc/ospfd.conf and add “redistribute default” right above the line that contains area 0.0.0.0. Then add the following inside of area 0.0.0.0:

To put these changes into effect, restart OSPF with the command “/etc/rc.d/ospfd.conf restart”.

Now ping 8.8.8.8 from spoke1’s LAN (172.30.106.1).

Now delete the static LAN macro in pf.conf and restart the firewall.

Now test by pinging around the various devices. Important connections to test from the LAN of a spoke are to the internet, the firewall’s loopback address, and the external IP of the firewall.

Firewall Rules

You can now mess around with the firewall rules. Firewall rules tell you what traffic is allowed or not allowed based on some criteria in order to protect your network. You can create firewall rules by using certain keywords. For example, “block” denies traffic from traveling to a specific destination.

Additionally, it’s important to remember that “the last matching rule wins.” For example, if you had a block rule that prevented traffic from going out to google.com from a specific IP address but then had an allow rule below that permitted all traffic to reach google.com, the latter would be carried out. However, quick rules are an exception to this as they are prioritized and can override other existing rules.

Here are a couple of sample rules that you can add to pf.conf:

##blocks all traffic going out to 8.8.8.8
block out quick on $ext_if from any to 8.8.8.8

Note: In order to test the “block” rule, change “any” to <lan> and make <lan> only contain spoke1’s LAN. Then, ping 8.8.8.8 from spoke1 and spoke2’s LAN.

##port redirection to ssh into the spokes
pass in quick on $ext_if proto tcp from <noc> to $fwip port 1000 rdr-to 172.31.0.10 port 22

Note: Remember to restart the firewall after you add the rules.

Note: In order to use redirection with SSH you must specify which port you are trying to SSH to. Example to go with the port redirection above:

ssh -p 1000 admin@192.168.11.17

Or for SSH into the Juniper SRX:

ssh -p 1000 root@192.168.11.17

Note: When trying to SSH into the Cisco router the computer will sometimes give you an error and specify what’s missing.

This could include ciphers,in which you add the -c option and what cipher the Cisco router is looking for.

You can have an error for algorithm options, which are are two options. The first will display that you need a certain algorithm (ie.diffie-hellman-group1-sha1 ). In this case, you will set add the following:

-oKexAlgorithms=+diffie-hellman-group1-sha1

The next option is for ssh-rsa. That option will look like the following:

-oHostKeyAlgorithms=+ssh-rsa

So, it’s possible that you’ll have to SSH with a long command like such:

ssh -p 1000 admin@192.168.11.17 -oKexAlgorithms=+diffie-hellman-group14-sha1' -oHostKeyAlgorithms=+ssh-rsa' -c aes256-ctr

Now that you SSH enabled on your spokes, you should start SSHing into the spokes. Up until this point, you were consoling into each spoke with “virsh console <VM>” which limits to only allowing one person at a time to be in the spoke. SSHing will allow more than one person to be in a spoke and really you should start SSHing into them anyway because it lessens the dependency on a console connection.

OpenBSD Firewall Lab

OpenBSD Firewall Lab

Introduction

Setup

Console into spokes 1, 2, and 3 and check to see if they can ping each other. Make sure they’re all using OSPF and have the appropriate neighbors before moving on to the next steps.

Download the fw-lab.img and fw-lab.xml files using the guide here:

and store them in /data. Shut down all the VMs that are currently running, except for the spokes.

For this lab, you can either choose the pass only vmbr0, or you can choose to pass individual vmbrs of 104 (where your “hub and firewall connect), and vmbrX (X is the vlan that your Internet connection is coming from which can vary).

In our case for individual vmbrs, you select your Internet vmbr first, and your vmbr104 second. Later on, we’ll connect vio0 to DHCP and give vio1 an internal IP address.

Edit fw-lab.xml, changing the src file (devices) path, vmbrs, interfaces, and slots as necessary, along with the KVM UUID as mentioned in the KVM Lab.

Now, define a VM using the fw-lab.xml file, start fw-lab, and console into it.

To change the hostname, edit /etc/myname.

Configuring Interfaces

For this section, there are two ways to configure our interfaces. The first section will go through how to configure interfaces if you passed individual vmbrs through to the VM. The second section will go over how to configure interfaces if you passed the single vmbr0.

Separate vmbr Interfaces

If you set individual vmbrs, when you run:

You should see two interfaces (vio0 and vio1). Edit /etc/hostname.vio0 and /etc/hostname.vio1. Make vio0

(simply write dhcp) and change vio1’s inet (172.30.104.1 255.255.255.252 NONE).

If you’re unsure about the subnet of the router/hub, refer back to the network diagram from the Static Routing Lab.

Now, restart the interfaces by entering the following commands:

Labeling Individual Interfaces

/etc/interfacedb.txt is a file used for organizational purposes when running ‘ship’. Insert or edit the VLANs to ensure that vio0 is your WAN interface (vlan11) and vio1 is your LAN interface (vlan104). For vio0, write ‘Internet_vlan:wan’ and ‘104:lan’ for vio1.

Single Parent Interface

If you set vmbr0, when you run ship, you will only see a single vio0 interface. To set up our interfaces, we will utilize vlans. Let’s set up our Internet access first.

We’re first going to set up our vlan with Internet access by editing /etc/hostname.vlanX where X is your vlan with Internet access, and making the file look like the following:

Here we reference that our parent interface is vio0, very similar to what we did in the KVM lab with our DHCP VM and setting what vlan were are using with the vnetid. Then we are going to have a DHCP address.

Next, we will set up out internal interface that will connect to the “hub” by editing /etc/hostname.vlan104 and its configuration will look like the following:

And now we can bring up both of our interfaces:

Labeling Vlan Interfaces

You will still use /etc/interfacedb.txt to label your interfaces if you decided to pass a single parent interface, the format will look like the following:

Testing and Adding Routes

Now, console into one of the spokes. Try pinging the hub and the other VLANs. If you cannot ping the hub, check to see if your switch/router is on and all cables are plugged in.

Example: !route add 172.30.106.0/24 172.30.104.2

Also, instead of writing out the full netmask next to the IP address, you could just write /30, /24, etc. depending on the subnet.

Make sure that the firewall is able to ping all of the spokes’ LANs and vice versa.

At the moment, the Router(hub) is communicating with the spokes about routes through OSPF, while the Router(hub) and firewall are communicating through static routing.

NAT Tables

Imagine that you had a device on your private network that wanted to connect to the internet. Your private IP cannot directly connect to the internet. In order to allow your private network to connect to a public network, a NAT (network address translation) table would be needed.

We’re now going to create a NAT table for our LAN’s IPs.

Go back into fw-lab and create the firewall rules by editing /etc/pf.conf. Delete the extra “ext_if” line if more than one are there. Move the “fwip external IP” line below the “ext_if vio0” line and save and exit.

Run “fws” to restart the firewall.

Your firewall should have automatically obtained an IP via dhcp on its WAN interface.Add that IP address’s subnet to /opt/shared/pf/noc.conf. For example, if your firewall’s WAN IP is 10.20.30.45 with subnet mask 255.255.255.0, you would insert “10.20.30.0/24”.

In /etc/pf.conf, confirm that NAT (##outbound NAT) says

Once done, restart the firewall again. If set up correctly, you should be able to ping the internet from the firewall’s LAN IP and the router’s WAN IP. To ping the internet using the firewall’s LAN IP, do

Afterwards, try pinging the internet from the router. You’ll want to make sure that the router(hub) has a static default route to the firewall.

Cisco

Juniper

Now go back to your /etc/pf.conf file. Add this line where the tables are defined:

At the bottom, change the “match out” LAN to use the table instead of the macro:

Save the file and restart the firewall. Test your connections again by pinging from your spoke’s LAN to the internet.

Setting up OSPF from the Router to the Firewall

Remove the default static route to the internet off of the router. Make sure the router isn’t advertising that it has the route to 0.0.0.0. Then, depending on whether you are using Cisco or Juniper, you can make the following changes:

Cisco

Juniper

Now, OSPF will be listening on vlan104.

Create a loopback address on the firewall by editing /etc/hostname.lo1. Inside this file, type the following command:

Run “sh /etc/netstart lo1” to initialize the interface. If that doesn’t work, try changing the file permissions to 700 by typing “chmod 700 /etc/hostname.lo1.”

If you cannot remember the loopback, be sure to check the spokes and bird routers.

Then, run ship to make sure the loopback works.

Go into /etc/ospfd.conf. Inside this file, type the following:

Now, we have to change the file permissions for ospfd.conf.

This command lists the file permissions for the owner, users in the same group as the owner, and everyone else (global). We only want to give the owner read and write permissions and everyone else no permissions for security reasons. To do this, we type:

Now, we need to edit /etc/rc.conf.local and add the following:

It’s important to set the ospfd_flags to “” because it allows the daemon to run at its default. If NO was defined instead, the daemon would not run at all.

Run

Afterwards, we need to go through and delete all the static route off the firewall. You can list the OSPF neighbors by running one of the following commands:

Cisco

Juniper

To be able to ping the loopback address of the router, you need to add is as a passive interface in OSPF; you don’t need every interface in OSPF to be active, usually just 1 will work in most environment. We will get into why this is important more during the Tunneling with Firewalls Lab.

Cisco

Juniper

Try to ping 8.8.8.8, the external IP of the firewall (in this case 192.168.11.17), and 172.31.0.9 (Firewall’s loopback address) from a spoke’s LAN.

To put these changes into effect, restart OSPF with the command “/etc/rc.d/ospfd.conf restart”.

Now ping 8.8.8.8 from spoke1’s LAN (172.30.106.1).

Now delete the static LAN macro in pf.conf and restart the firewall.

Now test by pinging around the various devices. Important connections to test from the LAN of a spoke are to the internet, the firewall’s loopback address, and the external IP of the firewall.

Firewall Rules

Here are a couple of sample rules that you can add to pf.conf:

Note: In order to test the “block” rule, change “any” to <lan> and make <lan> only contain spoke1’s LAN. Then, ping 8.8.8.8 from spoke1 and spoke2’s LAN.

Note: Remember to restart the firewall after you add the rules.

Your firewall should have automatically obtained an IP via dhcp on its WAN interface.
Add that IP address’s subnet to /opt/shared/pf/noc.conf. For example, if your firewall’s WAN IP is 10.20.30.45 with subnet mask 255.255.255.0, you would insert “10.20.30.0/24”.