Franske ITC-2480 Lab 10: Difference between revisions

From ITCwiki
Jump to navigation Jump to search
(updated for debian buster (nftables with firewalld))
Line 4: Line 4:
# Open an SSH console to your Linux system using the PuTTY software, login with your standard user account
# Open an SSH console to your Linux system using the PuTTY software, login with your standard user account
# Have a browser window set to the webmin interface for your linux VM.
# Have a browser window set to the webmin interface for your linux VM.
== Configure a Firewall and NAT ==
* '''IMPORTANT NOTE:''' If you were using an old version of this lab which used the Webmin software to configure a firewall note that no longer functions correctly with recent versions of Debian which have switched from the old ''iptables'' firewall to the newer ''nftables'' system. You must delete and deactivate your Webmin firewall configuration before proceeding. You can do this by removing the '''/etc/iptables.up.rules''' file from your system and rebooting.
<ol>
<li>It is suggested that instead of managing a firewall directly  using nftables tools (which would also require us to create a script to reload our rules each time the system is restarted) we use a firewall daemon program to manage it based on a set of rules we create and automatically setup the firewall based on those rules each time the system boots. There are many command line firewall management programs out there but for this lab we will use the [https://firewalld.org/ firewalld] package suggested by Debian. Begin by installing the ''firewalld'' package on your system.</li>
<li>First, let's check to see if the firewall is now up and running using the '''firewall-cmd --state''' command.</li>
<li>The firewall has been pre-configured with a couple of rules in it to prevent us from getting locked out. Let's see what those rules are by using the ''firewall-cmd --list-all'' command.</li>
<li>By default all interfaces are in the public zone (this is set in the ''/etc/firewalld/firewalld.conf'' file). Before we start working on rules for our firewall we should assign our outside interface to the external zone which is designed for NAT routing which we'll be setting up shortly. We can do this with the command ''firewall-cmd --zone=external --add-interface=ens192''. We can create custom zones or use pre-defined security zones which will speed up configuring the firewall. Learn more about the [https://firewalld.org/documentation/zone/predefined-zones.html pre-defined zones in firewalld documentation].</li>
<li>Since we have changed zones on our interface let's check and see what rules we have started with. Let's see what those rules are by using the ''firewall-cmd --zone=external --list-all'' command. You can also use the '''firewall-cmd --list-all-zones''' command to see a list of all available zones and their rules.</li>
<li>If you were watching carefully you may have noted that the dhcpv6-client service which was allowed in the public zone but is not allowed by default on the external zone. In our case we want to allow DHCPv6 to operate on our outside interface so we can re-enable it with the '''firewall-cmd --zone=external --add-service="dhcpv6-client"''' command.</li>
<li>Check to see what other services can be allowed on an interface with the '''firewall-cmd --get-services''' command.</li>
<li>If you check you will see that although you can connect with ssh (by default it's on the allowed service list you saw above) you can't connect to your webserver or Webmin anymore. Webmin is not a pre-defined service in the list we saw above so we could either set it up as a new service and then allow it or we could create a manual rule to allow the TCP traffic on port 10000 needed to access Webmin. In this case because the service only uses a single port and to see how manual rules can be created let's manually create a rule to allow access to TCP port 10000. Do this by running the '''firewall-cmd --zone=external --add-port=10000/tcp''' command. You should now be able to access Webmin again.</li>
<li>Using either service rules or manual port rules create additional rules so that the other services on your VM are again accessible from the outside (such as from your home PC over the VPN). Services we have setup so far include SSH, DNS, SMTP, IMAP, Samba, and HTTP. Make sure to test and ensure they are all working again!</li>
<li>Once you are satisfied your firewall is running correctly you can use the '''firewall-cmd --runtime-to-permanent''' command to set these rules to automatically load each time the system is started.</li>
</ol>


== Setup a 2nd NIC Interface ==
== Setup a 2nd NIC Interface ==
Line 17: Line 32:
<li>Verify the second interface is up and running with the correct IP address</li>
<li>Verify the second interface is up and running with the correct IP address</li>
</ol>
</ol>
== Enable Routing and NAT ==
 
== Enable Routing ==
<ol>
<ol>
<li>Now we will need to enable NAT so we can route LAN traffic to the Internet and responding Internet traffic back to our LAN interface.</li>
<li>Now we will need to enable NAT so we can route LAN traffic to the Internet and responding Internet traffic back to our LAN interface.</li>
Line 27: Line 43:
<li>Changes to the ''sysctl.conf'' file require a reboot, but most can be set without a reboot by echoing response codes to "files" in ''/proc''. We will get into that more in a later chapter, but for now run the following command to enable ip_forwarding without rebooting the machine: '''echo 1 > /proc/sys/net/ipv4/ip_forward'''</li>
<li>Changes to the ''sysctl.conf'' file require a reboot, but most can be set without a reboot by echoing response codes to "files" in ''/proc''. We will get into that more in a later chapter, but for now run the following command to enable ip_forwarding without rebooting the machine: '''echo 1 > /proc/sys/net/ipv4/ip_forward'''</li>
* Note: If you are receiving an error when trying to run that command it's likely that the user you are running it as does not have permission to modify the ''/proc/sys/net/ipv4/ip_forward file'' (check the permissions by using ls). Read [http://stackoverflow.com/questions/82256/how-do-i-use-sudo-to-redirect-output-to-a-location-i-dont-have-permission-to-wr this similar question] for more details and possible solutions.</li>
* Note: If you are receiving an error when trying to run that command it's likely that the user you are running it as does not have permission to modify the ''/proc/sys/net/ipv4/ip_forward file'' (check the permissions by using ls). Read [http://stackoverflow.com/questions/82256/how-do-i-use-sudo-to-redirect-output-to-a-location-i-dont-have-permission-to-wr this similar question] for more details and possible solutions.</li>
<li>Now we will use Webmin to setup ''iptables'' and allow for NAT so that we can use private addresses on our internal LAN. In Webmin, go to the ''Networking'' section, then ''Linux Firewall''. Recent versions of Debian will take you straight to a firewall settings page but we'd like to start with some default rules so if you're not taken to a page offering a few pre-set options click the ''Reset Firewall'' button on the bottom of the page.
* NOTE: Linux is in the process of transitioning from an ''iptables'' controlled firewall system to a new system called ''nftables''. While the outcome and purpose is the same the ''nftables'' system uses a new command line utility named '''nft''' instead of the traditional '''iptables''' for controlling the firewall. At this time Webmin does not yet support ''nftables'' which is one of the disadvantages to using a third party control panel interface, it will always lag behind in adopting new technologies. It would likely be beneficial for you to do a little bit of research on Google about how ''nftables'' works and how it differs from ''iptables'', especially if you plan to do further Linux system administration. While you're at it learning about ''ip sets'' which can work with ''iptables'' and are built into ''nftables'' to allow you to create dynamic rules where IP addresses can be added and removed from lists without re-loading the firewall.</li>
<li>You will be taken to a page that will ask you to setup ''iptables'' for the first time. To start, select the option ''Block all except SSH, IDENT, ping and high ports on interface ens192'', then click ''Setup Firewall''.</li>
<li>You will now be shown the firewall configuration page. Notice how Webmin created a handful of default rules for you based on the option we previously selected. We will get into creating custom rules later in this lab, but for now we need to enable NAT in iptables so that our LAN hosts can access the Internet through a shared WAN IP address.</li>
<li>On the top of the page where it says ''Showing IPtable:'', change the dropdown option to ''Network address translation (nat)''.</li>
<li>On the NAT table page, under the POSTROUTING category, press the Add Rule button. Use the following configuration to enable NAT:
<pre>Rule comment: Enable NAT for LAN
Action to take: Masquerade
Source ports for masquerading: any
IPs and ports to SNAT: Default
Source address or network: Equals: 192.168.1.1/24
Outgoing Interfce: Equals: ens192</pre></li>
<li>When you are done, press the ''Create'' button at the bottom, and then on the firewall page press ''Apply Configuration''. At this point you can use your Linux VM as a router/default gateway, but only with static IP addresses set on the LAN clients, so next we will setup a DHCP server.</li>
</ol>
</ol>


Line 54: Line 57:
Address Ranges: 192.168.1.100-192.168.1.254</pre></li>
Address Ranges: 192.168.1.100-192.168.1.254</pre></li>
<li>When you are done, press Create. Now, click on the network you just created to review the settings, then press Edit Client Options at the bottom.</li>
<li>When you are done, press Create. Now, click on the network you just created to review the settings, then press Edit Client Options at the bottom.</li>
<li>From here we will setup the default gateway and DNS servers for the clients to use. Under Default Routers, set the option to 192.168.1.1 and under DNS servers, set it to 192.168.1.1 as well. Notice how we are setting these options to the IP of eth1 that we setup. This is because our Linux VM will act as the router and DNS for our clients as well.</li>
<li>From here we will setup the default gateway and DNS servers for the clients to use. Under Default Routers, set the option to 192.168.1.1 and under DNS servers, set it to 192.168.1.1 as well. Notice how we are setting these options to the IP of ens224 that we setup. This is because our Linux VM will act as the router and DNS for our clients as well.</li>
<li>When you are done, press save, and then on the Edit Subnet page, press save again.</li>
<li>When you are done, press save, and then on the Edit Subnet page, press save again.</li>
<li>Now that you are back on the DHCP server page, press the Start Server button. If all goes good, the button should change to "Stop Server". If this does not happen, then the server was unable start. If that happens, re-check your DHCP server configurations to make sure everything is correct.</li>
<li>Now that you are back on the DHCP server page, press the Start Server button. If all goes good, the button should change to "Stop Server". If this does not happen, then the server was unable start. If that happens, re-check your DHCP server configurations to make sure everything is correct.</li>
</ol>
== Enabling NAT and Firewall Rules for the LAN ==
<li>Now we will use firewalld to setup NAT so that we can use private addresses on our internal LAN but still have access to the public Internet. First, let's set our ens224 interface (LAN) to be in the internal zone with the '''firewall-cmd --zone=internal --add-interface=ens224''' command.</li>
<li>You should now take a minute to all all of the same services and ports on the internal network that you have allowed on the external network. In other words, make sure that Webmin, Samba, DNS, etc. are also allowed on the internal zone.</li>
<li>In order to activate NAT you need to turn on the "masquerade" feature on your outside interface. This is probably already done if you correctly assigned your outside interface to the pre-defined external zone (it's one of the features of that zone) but you can do this manually as well in case you setup a custom zone by running the '''firewall-cmd --add-masquerade --zone=external''' command.</li>
<li>While routing and NAT should be working for hosts on your LAN interface now they probably still can't get an IP address! Just like all the other services being blocked by the firewall DHCP is also blocked unless you specifically allow it. To do this run the '''firewall-cmd --add-service=dhcp --zone=internal''' command.</li>
<li>Once you are satisfied your firewall is running correctly you can use the '''firewall-cmd --runtime-to-permanent''' command to set these rules to automatically load each time the system is started.</li>
</ol>
</ol>


Line 74: Line 86:
== Port Forwarding and Firewalling ==
== Port Forwarding and Firewalling ==
<ol>
<ol>
<li> Now we are going to enable port forwarding to our VM. This will allow you to access the 2nd VM from the IHITC network.</li>
<li>Now we are going to enable port forwarding to our VM. This will allow you to access the 2nd VM from the ITC network and VPN.</li>
<li> In Webmin, go to ''Networking'', and then ''Linux Firewall''. Change the ''Showing IPTable'' option to ''Network Address Translation (nat)'' to display the contents of the NAT table. Under the ''PREROUTING'' rules section click ''Add Rule''.</li>
<li>Because we are already using port 22 on our outside interface to provide SSH access to our main Debian system we need to use a different port to access the Mint system. Instead of changing the port number in the SSH server software on Mint we can have our firewall do it at the same time the NAT masquerading is occurring. Set up a rule by running the '''firewall-cmd --add-forward-port=port=2222:proto=tcp:toport=22:toaddr=192.168.1.100 --zone=external''' command. Note that this rule is a little unstable because it forwards the port to 192.168.1.100 which is currently the IP of our Mint system (if yours has a different IP you should change it in the command) but because that system gets an IP from DHCP it is subject to change which would break the rule. Therefore, if we wanted this to be stable in the long term, we would want to set up a static IP on any machines we were forwarding ports to.</li>
<li> For our rule we are going to forward port 2222 to port 22 on our Mint VM. This will allow someone connecting to port 2222 on our outside (172.17.50.xx) IP address to actually be connected to port 22 on our Mint VM (the SSH port). You will need to know and use the IP address of the Mint Machine, but in this example configuration it will be 192.168.1.100</li>
<li> From a computer on the ITC network, such as one connected to the VPN, try to SSH to port 2222 on the outside (17.17.50.xx) IP address of your Debian system. If everything was setup successfully, you should be able to sign into the Mint VM based on the port forwarding rule we have put in place.</li>
<li> Use the following information to create the new rule:
<li>Once you are satisfied your firewall is running correctly you can use the '''firewall-cmd --runtime-to-permanent''' command to set these rules to automatically load each time the system is started.</li>
<pre>
<li>When you are done testing this section of the lab please power off your new Linux Mint VM as these require far more resources to run than the Debian VMs on our servers.</li>
Rule comment: Forward 2222 to SSH
Action to take: Destination NAT
IPs and ports for DNAT: IP range: 192.168.1.100: Port range: 22
Network protocol: Equals: TCP
Destination TCP or UDP Port: Equals: 2222
</pre>
* Help: Use the following image for extra reference if required: [http://wiki.ihitc.net/mw/images/f/f3/Port_Forward.png Link]</li>
<li> When you are done click ''Save'', and then ''Apply Configuration''. On the Mint VM, make sure ''openssh-server'' package is installed so that you actually have SSH server software listening on port 22.</li>
<li> From a computer on the IHITC network, such as one connected to the VPN, try to SSH to port 2222 on the outside (17.17.50.xx) IP address of your Debian system. If everything was setup successfully, you should be able to sign into the Mint VM based on the port forwarding rule we have put in place.</li>
<li> When we originally setup our firewall in Webmin we chose the option to ''Block all except SSH, IDENT, ping and high ports on interface ens192''. While this worked to get NAT up and running it also means that all of our other services we've had up and running such as our web server, email server, Samba fileserver, etc. are all currently blocked by our firewall. There are also some high ports (above 1024) which are open but don't need to be so it would be a good idea to close those off.</li>
<li> First, review all the current rules in the ''filter'' table in Webmin. You'll see the rules which allow most traffic on ports above 1024:
<pre>
Accept  If protocol is TCP or UDP and destination port is 1024:65535
Drop If protocol is TCP and destination port is 2049:2050
Drop If protocol is TCP and destination port is 6000:6063
Drop If protocol is TCP and destination port is 7000:7010
</pre></li>
<li>  Delete these four rules but be sure NOT to click the ''Apply'' button! Think about why it might be a bad idea to apply these changes. How are you connected to the server and making changes to the firewall right now? Using your web browser you're connected to a webserver running as part of Webmin on TCP port 10000. The first rule we deleted is currently allowing you to access port 10000 but if we delete it and apply the changes our browser will no longer be able to connect to the Webmin webserver! If you accidentally do click Apply you will need to use the command line '''iptables''' utility to put a rule back in place which allows access to port 10000 before Webmin will work again. The next section of the lab explains some about the use of the command line '''iptables''' utilities.</li>
<li> In order to prevent problems use Webmin to create a new rule in the ''filter'' table specifically allowing access on TCP port 10000 like this:
<pre>Action to take: Accept
Network Protocol: Equals: TCP
Destination TCP or UDP port: Equals: 10000
</pre></li>
<li> Once you've created this rule it should be safe to click ''Apply'' because you now have access to port 10000. Of course, if you make a mistake or typo it's still possible you lock yourself out of Webmin and will need to use the '''iptables''' command line utilities to view and fix the firewall configuration.</li>
<li> Using the same type of ''Accept'' rules in the ''filter'' table create additional rules so that the other services on your VM are again accessible from the outside (such as from your home PC over the VPN). Services we have setup so far include SSH, DNS, SMTP, IMAP, Samba, and HTTP. Make sure to correctly identify the port number(s) and protocols (TCP or UDP) that are needed for each of these and after clicking ''Apply'' test to ensure they are working!</li>
<li> Part of doing any sort of IT work is to test and verify what you have done. In this case you have added a firewall on your system which has the potential to block traffic. However, if you carefully followed all the instructions above all your services from earlier in the class (Web server, mail server, DNS server, etc.) should still be working. You should test all of the services you have setup prior to this point and verify they are still working. If they are not you will need to troubleshoot the issue.</li>
<li> When you are done testing this section of the lab please power off your new Linux Mint VM as these require far more resources to run than the Debian VMs on our servers.</li>
</ol>
 
== iptables from the command line ==
<ol>
<li>Now that you know how to create rules with Webmin, let's learn how to do it from the command line using the '''iptables''' utilities.</li>
<li>If you want to view the current rulesets applied on a system, or you want to backup your current configuration, you can use the '''iptables-save''' command. Run it, and review the output. Notice how all of the rules we created in Webmin show up.</li>
<li>To backup your rules, you would use '''iptables-save > rules.txt'''. This would dump the current configuration into a file called rules.txt using standard command redirection as previously covered in the course.</li>
<li>To reload the rules into '''iptables''', you would use '''iptables-restore'''. This command can load a text file full of rules back into the firewall by specifying a file to load like '''iptables-restore rules.txt'''.</li>
<li>Lastly, you can create and delete select rules from the command line using the '''iptables''' command directly. Review the readings and the '''man''' page for '''iptables''' for additional details.</li>
</ol>
</ol>

Revision as of 23:46, 9 November 2020

Introduction

Lab Procedure

Prerequisites

  1. Open an SSH console to your Linux system using the PuTTY software, login with your standard user account
  2. Have a browser window set to the webmin interface for your linux VM.

Configure a Firewall and NAT

  • IMPORTANT NOTE: If you were using an old version of this lab which used the Webmin software to configure a firewall note that no longer functions correctly with recent versions of Debian which have switched from the old iptables firewall to the newer nftables system. You must delete and deactivate your Webmin firewall configuration before proceeding. You can do this by removing the /etc/iptables.up.rules file from your system and rebooting.
  1. It is suggested that instead of managing a firewall directly using nftables tools (which would also require us to create a script to reload our rules each time the system is restarted) we use a firewall daemon program to manage it based on a set of rules we create and automatically setup the firewall based on those rules each time the system boots. There are many command line firewall management programs out there but for this lab we will use the firewalld package suggested by Debian. Begin by installing the firewalld package on your system.
  2. First, let's check to see if the firewall is now up and running using the firewall-cmd --state command.
  3. The firewall has been pre-configured with a couple of rules in it to prevent us from getting locked out. Let's see what those rules are by using the firewall-cmd --list-all command.
  4. By default all interfaces are in the public zone (this is set in the /etc/firewalld/firewalld.conf file). Before we start working on rules for our firewall we should assign our outside interface to the external zone which is designed for NAT routing which we'll be setting up shortly. We can do this with the command firewall-cmd --zone=external --add-interface=ens192. We can create custom zones or use pre-defined security zones which will speed up configuring the firewall. Learn more about the pre-defined zones in firewalld documentation.
  5. Since we have changed zones on our interface let's check and see what rules we have started with. Let's see what those rules are by using the firewall-cmd --zone=external --list-all command. You can also use the firewall-cmd --list-all-zones command to see a list of all available zones and their rules.
  6. If you were watching carefully you may have noted that the dhcpv6-client service which was allowed in the public zone but is not allowed by default on the external zone. In our case we want to allow DHCPv6 to operate on our outside interface so we can re-enable it with the firewall-cmd --zone=external --add-service="dhcpv6-client" command.
  7. Check to see what other services can be allowed on an interface with the firewall-cmd --get-services command.
  8. If you check you will see that although you can connect with ssh (by default it's on the allowed service list you saw above) you can't connect to your webserver or Webmin anymore. Webmin is not a pre-defined service in the list we saw above so we could either set it up as a new service and then allow it or we could create a manual rule to allow the TCP traffic on port 10000 needed to access Webmin. In this case because the service only uses a single port and to see how manual rules can be created let's manually create a rule to allow access to TCP port 10000. Do this by running the firewall-cmd --zone=external --add-port=10000/tcp command. You should now be able to access Webmin again.
  9. Using either service rules or manual port rules create additional rules so that the other services on your VM are again accessible from the outside (such as from your home PC over the VPN). Services we have setup so far include SSH, DNS, SMTP, IMAP, Samba, and HTTP. Make sure to test and ensure they are all working again!
  10. Once you are satisfied your firewall is running correctly you can use the firewall-cmd --runtime-to-permanent command to set these rules to automatically load each time the system is started.

Setup a 2nd NIC Interface

  1. To start this lab we will need to configure a second network interface, named ens224 on our virtual machines. In our simulated setup our existing ens192 interface will be our WAN interface and ens224 will be our LAN interface which could be connected to a switch and then to multiple allow other computers which will connect to the Internet through our server.
  2. Open /etc/network/interfaces with your favorite text editor. Go to the bottom of the file and add the following to configure the second interface with a static IP of 192.168.1.1/24: 
    auto ens224
iface ens224 inet static
	address 192.168.1.1
	netmask 255.255.255.0
  3. As this is a LAN only interface, we do not need to define a gateway for the server VM, as the server VM itself will be the gateway for this network.
  4. Once this is done, save the file and then run ifup ens224 to enable the new interface.
  5. Verify the second interface is up and running with the correct IP address

Enable Routing

  1. Now we will need to enable NAT so we can route LAN traffic to the Internet and responding Internet traffic back to our LAN interface.
  2. In your console, you will need to edit /etc/sysctl.conf. This file is used to change and tweak multiple system variables. Scroll down until you find the following: 
    # Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1
  3. Follow the instructions in the file to enable packet forwarding in the kernel. When you are done, save the file.
  4. Changes to the sysctl.conf file require a reboot, but most can be set without a reboot by echoing response codes to "files" in /proc. We will get into that more in a later chapter, but for now run the following command to enable ip_forwarding without rebooting the machine: echo 1 > /proc/sys/net/ipv4/ip_forward
    • Note: If you are receiving an error when trying to run that command it's likely that the user you are running it as does not have permission to modify the /proc/sys/net/ipv4/ip_forward file (check the permissions by using ls). Read this similar question for more details and possible solutions.

Setup a DHCP Server

  1. To setup a DHCP server, we will first need to install the required software. In your SSH console use your favorite package manager to install the isc-dhcp-server package.
  2. After you install the package you may get a warning about isc-dhcp-server being unable to start. This is normal as we have yet to define the interface and settings we want used.
  3. Now back in Webmin, select the Refresh Modules option. After it is done, go to Servers, then DHCP Server.
  4. Before we define our DHCP range, we need to set our listening interface. Click on the Edit Network Interface option, and select ens224 and press save.
  5. Now under Subnets and Shared Networks, select Add a new subnet. Use the following settings: 
    Subnet description: LAN DHCP Range
Network Address: 192.168.1.0
Netmask: 255.255.255.0
Address Ranges: 192.168.1.100-192.168.1.254
  6. When you are done, press Create. Now, click on the network you just created to review the settings, then press Edit Client Options at the bottom.
  7. From here we will setup the default gateway and DNS servers for the clients to use. Under Default Routers, set the option to 192.168.1.1 and under DNS servers, set it to 192.168.1.1 as well. Notice how we are setting these options to the IP of ens224 that we setup. This is because our Linux VM will act as the router and DNS for our clients as well.
  8. When you are done, press save, and then on the Edit Subnet page, press save again.
  9. Now that you are back on the DHCP server page, press the Start Server button. If all goes good, the button should change to "Stop Server". If this does not happen, then the server was unable start. If that happens, re-check your DHCP server configurations to make sure everything is correct.

Enabling NAT and Firewall Rules for the LAN

  • Now we will use firewalld to setup NAT so that we can use private addresses on our internal LAN but still have access to the public Internet. First, let's set our ens224 interface (LAN) to be in the internal zone with the firewall-cmd --zone=internal --add-interface=ens224 command.
  • You should now take a minute to all all of the same services and ports on the internal network that you have allowed on the external network. In other words, make sure that Webmin, Samba, DNS, etc. are also allowed on the internal zone.
  • In order to activate NAT you need to turn on the "masquerade" feature on your outside interface. This is probably already done if you correctly assigned your outside interface to the pre-defined external zone (it's one of the features of that zone) but you can do this manually as well in case you setup a custom zone by running the firewall-cmd --add-masquerade --zone=external command.
  • While routing and NAT should be working for hosts on your LAN interface now they probably still can't get an IP address! Just like all the other services being blocked by the firewall DHCP is also blocked unless you specifically allow it. To do this run the firewall-cmd --add-service=dhcp --zone=internal command.
  • Once you are satisfied your firewall is running correctly you can use the firewall-cmd --runtime-to-permanent command to set these rules to automatically load each time the system is started.

    • Setup a 2nd VM as a LAN Host

    1. Now we are going to setup a 2nd VM on the VMware server so we can have a client to connect to the LAN network segment we just created. For this though, we will be using Linux Mint instead of Debian so we have a graphical user interface to help us with testing.
    2. You'll need to connect to the VMware server and verify that you have a machine with the same letter ID as you have been working with so far but with a -II suffix on the end. You'll also want to verify that the machine has the Linux Mint ISO in the virtual CD/DVD drive or correct that by browsing for the ISO in the SAN0 datastore.
    3. Boot the VM and get Linux Mint installed, installation settings are not critical as we'll be using the system primarily to explore a Linux GUI and to test web browsing capability from our private network.
      • NOTE: By default Linux Mint will boot into a "Live CD" environment where you can use the system without installing. However, the Live CD environment is much slower and memory limited compared with a full installation to the hard drive so be sure to start an installation and reboot into the installed copy instead of from the Live CD. You will know you're working from an installed copy if you are prompted for your username and password when logging in and don't see a link on the desktop to Install Linux Mint anymore.
    4. Once you have Linux Mint installed, reboot the machine and login. Notice how the machine is able to connect to the network. Now, press the Menu icon in the lower left corner, and enter "Terminal". Then, open the terminal application.
    5. You now have a shell on the system. From here, use ip address show to check your network settings. Notice how you have a IP from the DHCP pool we created earlier. Now try pinging 172.17.50.1. Are you able to ping? If so, NAT is working properly on your network because the 172.17.50.0/24 network is outside of the LAN segment this machine is attached to (192.168.1.0/24).
      • NOTE: Notice how some Linux distributions like Mint haven't switched from the old naming of network interfaces with eth to the new ens style. You can also try using the older ifconfig way of checking the IP address and compare the output to the new ip address show method which we have been using so far in Debian.
    6. Now run ping google.com. If you are able to ping, this shows that not only is NAT working, but DNS resolving as well.
    7. Open a web browser on the system (you can use a graphical browser this time since you have a GUI) and test browsing to a few websites.
    8. At this point we have a fully functional LAN environment.
    9. Spend a few more minutes exploring the functionality of the Linux GUI and desktop.

    Port Forwarding and Firewalling

    1. Now we are going to enable port forwarding to our VM. This will allow you to access the 2nd VM from the ITC network and VPN.
    2. Because we are already using port 22 on our outside interface to provide SSH access to our main Debian system we need to use a different port to access the Mint system. Instead of changing the port number in the SSH server software on Mint we can have our firewall do it at the same time the NAT masquerading is occurring. Set up a rule by running the firewall-cmd --add-forward-port=port=2222:proto=tcp:toport=22:toaddr=192.168.1.100 --zone=external command. Note that this rule is a little unstable because it forwards the port to 192.168.1.100 which is currently the IP of our Mint system (if yours has a different IP you should change it in the command) but because that system gets an IP from DHCP it is subject to change which would break the rule. Therefore, if we wanted this to be stable in the long term, we would want to set up a static IP on any machines we were forwarding ports to.
    3. From a computer on the ITC network, such as one connected to the VPN, try to SSH to port 2222 on the outside (17.17.50.xx) IP address of your Debian system. If everything was setup successfully, you should be able to sign into the Mint VM based on the port forwarding rule we have put in place.
    4. Once you are satisfied your firewall is running correctly you can use the firewall-cmd --runtime-to-permanent command to set these rules to automatically load each time the system is started.
    5. When you are done testing this section of the lab please power off your new Linux Mint VM as these require far more resources to run than the Debian VMs on our servers.
    Retrieved from "https://wiki.ihitc.net/mediawiki/index.php?title=Franske_ITC-2480_Lab_10&oldid=8221"