Is it possible to not only get Palo Alto running on our own built network but also a rule to run and function within it? This will walk you through the research and work we did to get to that point. We decided on Palo Alto as it is an enterprise cybersecurity platform that provides network and cloud security as well as endpoint protection and other cloud security services. We focused on the firewall feature of Palo Alto, more specifically the logging side of things.
General Overview
We of course started from the ground up. We set up a Cisco Packet Tracer topology. We then created our group name ‘SkyNet’ to use for the rest of the project. We then assigned the IP addresses that we would be using in our local POD network as the following: 192.168.4.215, 192.168.4.216, 192.168.4.217, and 192.168.4.218. These are the IP addresses we started with, however, we did have to change them later as we had problems with the other POD throughout the semester using and changing our configurations, as well as internal issues on our end of simple configuration mix-ups. The final IP addresses for our POD were 14.50.1.215-218.
 |  |
We started the configuration of the router by clearing a CF card so that we could load our configurations into it. We created a hostname, set up the console password, and set up user accounts for each of us in the group and added the correct privileges. We then set up the message of the day and login banners for the router, as well as an SSH setup. We then configured FastEthernet (FA) 0/0 and used the first network created from the design process and assigned a valid host to this interface. We then applied similar changes to FA 0/1. We were able to SSH into the router at this point. Also at this point, we were able to ping from one workstation to the other. We were also able to successfully save all our changes to the flash card. These configurations and changes were reflected parallelly in Cisco Packet Tracer for reference purposes and in Azure for document reassurance.
We then began to work in EVE-NG topology, which is an emulated virtual environment for network, security, and development operations professionals. We emulated the ISO image into EVE and configured our interface router ports as needed. We created a “Lab” for our group at this point within EVE. This is the topology we would use and build from for the rest of the semester. We then applied configurations to our EVE router just like we did to our POD router. We configured our interfaces using our classroom network scheme and then added a third network with a usable IP address within our new network range
 |  |
Within EVE we also added a Windows 2019 Server and connected that node (nodes are the terms for each component in EVE) to our topology within EVE. We added user accounts for each person in our group and added administrative privileges to those accounts and set up Remote Desktop on all the accounts as well so that they would represent and act as similar to normal client hosts as possible.
We then moved on to configure OSPF into our POD network. We added and enabled OSPF to both routers and then set the gateway of last resort on both routers to 10.20.1.1, which is the classroom IP address to the internet. We then moved to integrating the IP Services into the POD network as well as configuring the Dynamic Host Configuration Protocol and Network Time Protocol, using Cloud Fares’ NTP server. We then added local Dynamic Hosts to both routers and tested them to ensure it was working and then disabled the Domain Name System on both routers as well. Once this was all done, we then started integrating Palo Alto into our SkyNet Network.
Troubleshooting
That said, we did have our fair bit of challenges. With our lab being within a shared environment, setbacks were inevitable. At last, our group was able to find workarounds, for example, the physical router would normally be password-locked from the last group's configurations this put us in a position where we had to put the Cisco 1841 router into a rommon mode. This is a mode that allows a user to reset the router back to a point where no configurations are saved, thus allowing us to reload our configurations. With occurrences like this happening more often than we would like, we resorted to putting the router in a mode where it would not save the configurations at all. This way no group was forced to put the router in rommon mode again.
Another issue we had was with the EVE environment; we kept running into issues with IPs we wanted to use already being in use and this interfered with our connections in the beginning until we figured out what was happening. This resulted in the changing of certain interface configurations to allow for a smooth connection flow. Another large issue we had was with our Windows server that was emulated within the EVE environment. The Windows server would need to be reinstalled each time we would return to the virtual machine. This was later swapped out with a ready-to-deploy Linux machine running Ubuntu to run in place of the Windows Server. The switch from Windows to Linux did modify our end product slightly, but not enough to remain detrimental.
At last, we were able to overcome the issues in our own way and developed a deeper appreciation for the documentation offered by each service. This came along with the time and patience needed for solving each problem we would come across in our journey of the semester of setting up our own pod network from scratch. Overall, we valued the depths we would have to go to find the answer, allowing us to learn and tinker more with each piece of equipment or software.
Final Network Configuration Summary
This brings us to the current standing and final version, of our network for the semester. Starting with reaching from each individual POD computer to the POD router and switches, to the EVE servers hosted in the classroom network, and ending with our additional virtualized firewall run by Palo Alto, an enterprise-level firewall with all the bell and whistles we wish we had more time to explore. Although we did not get to experience all the features of Palo Alto, we got to the point where we could view and filter traffic through the firewall within our EVE network.
The physical layer of our group’s network is made up of the four local computers connected to two local cisco switches and a local Cisco 1841 router. Our router was given a custom IP address range of 14.50.1.1 as the broadcast, then for our computers with the range of 14.50.1.215-218. We then followed a naming scheme ‘SkyNet’ for our network, and so forth our physical router was named SkyNetR1. After the overall configuration of interface ports, SSH, OSPF, the user account for each person, and other security protocols. We could finally reach the internet through our physical hardware by using the ‘traceroute’ command to Google.com in Windows PowerShell on our client machines.
Taking things a step further, we decided to use EVE to extend our network to more hardware. This was done by replicating the physical router onto a virtual version of the Cisco 1841 router, then later sending each hop through a Palo Alto firewall to a switch that was connected to a Linux virtual machine. This was done by installing the ISO images onto the EVE environment for each piece of hardware and then configuring each one for the requirements needed for the device. The goal for EVE was the same as our physical: to reach Google.com by ‘traceroute’ through our firewall. In our case, we were using a Linux system and not Windows Server 2019. We faced challenges earlier in the process with Windows Server, resulting in a switch to Linux. However, with our Linux machine being a virtual machine, there was no way for us to truly obtain an internet connection. This caused us to use ‘traceroute’ on our EVE router, SkyNetR2, instead of the Linux machine. We found results when using the ‘traceroute’ command on SkyNetR2, being able to backtrack/trace out of our EVE server to Google.com.
 |  |
All traffic from EVE is passed through the Palo Alto firewall for logging and filtering purposes. The way we did this was by assigning an IP address on our classroom network, which is 10.20.1.229. The reason we had to do it this way is because that is how EVE was functioning for us and it was the most logical solution at the time. A solid solution in hindsight. In our EVE topology, we plugged into the virtual management port to use the GUI on the class network instead of being on the actual POD network. This took some time to configure because we had to dive into the command line side of Palo Alto, a new experience for all of us, to enable the web GUI for full access to the firewall settings.
Once in the web interface of Palo Alto, we had to learn a bit about each setting and find what we needed for our ultimate end goal. In the end, we decided to use a virtual wire to act as an essential passthrough from our switch to the router. However, we configured a policy to log all the information passing through each port which was assigned via ‘zones’ in our policy. For example, Ethernet ports 0/0 and 0/1 are put in zone ‘SkyNetZone1’ in our ‘SkyNetFilter’ policy. We then were able to log the traffic coming from our clients on the network, which in our case was the virtual Linux computer to the EVE router on the EVE network. Going further, we could filter out specific services, such as blocking connections to HTTP websites but allowing HTTPS sites that are secure. We tested these policies by demonstrating the ‘ping’ command on our router from the Linux client to the router, as well as using the ‘traceroute’ command in our SkyNetR2 EVE router. The ‘traceroute’ command would ideally be sent from our Linux client, however, with the client being virtual, no true internet connection can be established as previously stated
Group Final Thoughts
Overall, we learned a great deal about Networking and were able to gain newfound confidence in our skills and knowledge for setting up and maintaining a network using enterprise-grade hardware and tactics. We have demonstrated that we can design and deploy an active and functional network, as well as skills in troubleshooting different situations that may accrue on the network. An example is the setup of a backup to avoid loss of progress or resting passwords on routers to open the ports of either routers or switches. In the end, we feel that we can take these skills into the workplace and use them as a baseline capable of propelling us forward to further grow and be capable of carrying out the duties of network administrators, but we are also able to acknowledge the tediousness of the network build process and understand that there is still much for us to learn.