[SOLVED] OMSCS/OMSCY CS-6250 SDN Firewall with POX Summer 2026

SDN Firewall with POX

This project involves the introduction of Software Defined Networking using the mininet network simulator and OpenFlow with the POX OpenFlow Controller.

Table of Contents

Project Introduction……………………………………………………………………………………………………………………….. 2

Part 0:  Project References………………………………………………………………………………………………………………. 2

Part 1:  Files Reference……………………………………………………………………………………………………………………. 2

Part 2:  Mininet Overview……………………………………………………………………………………………………………….. 3

Part 3:  Wireshark Demonstration……………………………………………………………………………………………………. 3

Part 4:  Firewall Configuration Details and Coding Dictionary Items……………………………………………………… 5

Part 5:  Firewall Implementation Code……………………………………………………………………………………………… 7

Part 6:  Firewall Configuration Requirements…………………………………………………………………………………….. 8

Firewall Rules for Spring 2026:……………………………………………………………………………………………………… 8

Part 7:  What to Turn In and Grading Rubric………………………………………………………………………………………. 9

Part 8:  What Can and Cannot Share…………………………………………………………………………………………………. 9

Part 9:  Troubleshooting Tips…………………………………………………………………………………………………………… 9

Part 10:  Youtube Videos……………………………………………………………………………………………………………….. 10

Appendix A:  Review of Mininet……………………………………………………………………………………………………… 10

Appendix B:  Testing Methodologies……………………………………………………………………………………………….. 11

Part A:  How to Test Manually…………………………………………………………………………………………………….. 11

Part B:  Automated Testing Suite………………………………………………………………………………………………… 13

How to test alternate cases:……………………………………………………………………………………………………. 13

How to test normal cases:………………………………………………………………………………………………………. 14

Appendix C:  POX Excerpt………………………………………………………………………………………………………………. 14

Flow Modification Object…………………………………………………………………………………………………………… 14

Match Structure……………………………………………………………………………………………………………………….. 14

OpenFlow Actions…………………………………………………………………………………………………………………….. 16

Example: Sending a FlowMod Object………………………………………………………………………………………….. 16

Project Introduction

This project is an introduction to Software Defined Networking using Mininet (network simulator) and a Python-based OpenFlow Controller named POX to create a relatively simple configurable firewall, although it can be extended to provide complex solutions.

For this project, there are several phases:

1.       If you did not complete the Simulating Networks optional project, you may want to review the Mininet Tutorial located in Appendix A.  Mininet simulates a network topology that you will use in building your firewall rules.

2.       Wireshark – In this phase, you will use the Wireshark (tshark) network packet capture utility to capture a subset of network traffic.  The purpose of this phase is to introduce this powerful network tool and to demonstrate the different aspects of the packet headers that you will use in your firewall implementation and the configuration ruleset that you will use.  You will need to submit the simple packet capture that you generate as a part of the submission.

3.       POX Firewall Implementation – In this phase, you will build the firewall implementation that will ingest a firewall configuration and create the POX OpenFlow Flow Modification object, traffic matching, priorities, and an action item based on the configuration.  You can code this implementation and then subsequently test using the alternate testing platform without needing to code your configuration first.

4.       Firewall Configuration – In this phase, you will create a firewall configuration that will implement a simple firewall.  You will be able to test this with your implementation from phase 3 using a provided testing suite.

You will NOT be able to submit this project to Gradescope in the Spring 2026 semester.  You will submit this to Canvas in a ZIP file.  You can test your submission with the included test-suites and any student-developed test suites that may be made available.

This project is released on March 9, 2026 and will be due at 23:59 AOE (Anywhere-On-Earth) on March 22, 2026.  There is a 20 hour late submission period with a penalty of 5% of the grade per hour on March 23, 2026.

Part 0:  Project References

You will find the following resources useful in completing this project. It is recommended that you review these resources before starting the project.

•       IP Header Format – https://erg.abdn.ac.uk/users/gorry/course/inet–pages/ip–packet.html  

•       TCP Packet Header Format – https://en.wikipedia.org/wiki/Transmission_Control_Protocol  

•       UDP Packet Header Format – https://en.wikipedia.org/wiki/User_Datagram_Protocol  

•       The ICMP Protocol – https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol  

•       IP Protocols – https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers  

•       TCP and UDP Service and Port References – https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers  

•       Wireshark – https://www.wireshark.org/docs/wsug_html/  

•       CIDR Calculator – https://account.arin.net/public/cidrCalculator

•       CIDR – https://en.wikipedia.org/wiki/Classless_Inter–Domain_Routing

Part 1:  Files Reference

The files for this project are available for download on Canvas.  You will find a ZIP file named SDNFirewall-Spring2026.zip file.  Please download this file from the VM or transfer the file to the Virtual machine.  Suggested location is the home directory for the mininet user.  Move the file to the home directory and run the following command from the terminal window:

unzip SDNFirewall-Spring2026.zip

If you get a notice that unzip cannot be found, run the following:  sudo apt install unzip

The following table indicates the purposes of files that you should NOT modify in the SDNFirewall directory.

The following table indicates the files that you will edit as a part of this project and what you will ZIP up for your submittal to Canvas before the project deadline.

In the folder, you will also find a test-suite folder that contains two test-suites – one to test your code implementation and one to test your code implementation + your firewall configuration.

Part 2:  Mininet Overview

If you did not complete the Simulating Networks Optional Project, you may want to review the “Mininet Review” section in Appendix A to learn about the different aspects of how a mininet network is setup, including how to configure the physical topology and assignment of addresses to hosts and switches.

Part 3:  Wireshark Demonstration

Wireshark is a network packet capture program that will allow you to capture a stream of network packets and examine them.

Wireshark is used extensively to troubleshoot computer networks and in the field of information security. We will be using Wireshark to examine the IP and TCP/UDP packet headers to learn how to use this information to match traffic that will be affected by the firewall we are constructing.

tshark is a command line version of Wireshark that we will be using to capture the packets between mininet hosts and we will use Wireshark for the GUI to examine these packets. However, you will be allowed to use the Wireshark GUI if you would like in doing the packet capture.

Please watch the Wireshark Tutorial Youtube Video if you would like to follow along in time for a live packet capture.

1.       Open up a Terminal/Console Window and change directory to the SDNFirewall directory.

2.       The first action is to start up the Mininet topology used for the Wireshark capture exercise. This topology matches the topology that you will be using when creating and testing your firewall. To start this topology, run the following command:

sudo python ws-topology.py

This will startup a Mininet session with all hosts created.   If you use sdn-topology.py, you will get a controller error.  Press Ctrl-C, run ./cleanup.sh and then retry this step with the correct topology name.

3.       Using the mininet console (i.e., mininet> prompt), start up an xterm window for hosts us1 and host us2.   

us1 xterm & us2 xterm &      

The window that opens first will be us1 and the second us2.  You may change the prompt to help track the hosts, which will be important if you do manual testing of your firewall.

4.       In this step, we want to start capturing all the traffic that traverses through the ethernet port on host us1. We do this by running tshark (or alternatively, wireshark) as follows from the mininet prompt:

us1 sudo tshark -w /tmp/packetcapture.pcap

This will start tshark and will output a pcap formatted file to packetcapture.pcap to the /tmp directory. Note that this file is created as root, so you will need to change ownership to mininet to use it in future steps –  sudo chown mininet:mininet /tmp/packetcapture.pcap

If you wish to use the Wireshark GUI instead of tshark, you would call us1 sudo wireshark &. You may use this method, but the TA staff will not provide support for any issues that may occur.

YOU WILL SUBMIT THIS FILE AS A PART OF YOUR SUBMITTAL.

5.       Step 5:  Now we need to capture some traffic. Do the following tasks in the appropriate xterm window: o   in us1 xterm:     ping 10.0.1.2      (hit control C after a few ping requests) o       In us2 xterm:     ping 10.0.1.1      (likewise hit control C after a few ping requests) o      In us1 xterm:     python test-server.py T 10.0.1.1 80  o            In us2 xterm:     python test-client.py T 10.0.1.1 80

After the connection completes, in the us1 xterm, press Control-C to kill the server.

o    In us1 xterm:     python test-server.py U 10.0.1.1 8000  o       In us2 xterm:     python test-client.py U 10.0.1.1 8000 o       In us1 xterm:     press Control C to kill the server o     In Mininet Terminal:  press Control C to stop tshark

6.       At the mininet prompt, type in exit and press enter. Next, do the chown command as described in step 4 above to your packet capture. You may also close the two xterm windows as they are finished.   Copy the /tmp/packetcapture.pcap to your project This file is the deliverable for this phase of the project.  See the instructions in Step 4 that describe how you will need to change ownership of this file in order to change or move it.

o    sudo chown mininet:mininet /tmp/packetcapture.pcap o cp /tmp/packetcapture.pcap ~/SDNFirewall

7.       Step 7:  At the bash prompt on the main terminal, run:

sudo wireshark  

(You may also use a wireshark tool on your host computer if you’d like.  If you do this, copy over the packet capture to

your host computer)

Go to the File => Open menu item, browse to the /tmp directory and select the pcap file that you saved using tshark.  

You will get a GUI that looks like the example packet capture. You will have a numbered list of all the captured packets with brief information consisting of source/destination, IP protocol, and a description of the packet. You can click on an individual packet and will get full details including the Layer 2 and Layer 3 packet headers, TCP/UDP/ICMP parameters for packets using those IP protocols, and the data contained in the packet.

Example Packet Capture – Host Client us1 making web request to Server us2

Note the highlighted fields. You will be using the information from these fields to help build your firewall implementation and ruleset. Note the separate header information for TCP. This will also be the case for UDP packets.

Also, examine the three-way handshake that is used for TCP. What do you expect to find for UDP?  ICMP? Example TCP Three-Way Handshake

Please examine the other packets that were captured to help you familiarize yourself with Wireshark.

Part 4:  Firewall Configuration Details and Coding Dictionary Items

This part is a reference to assist you in coding your implementation file and for creating your configuration file.

Your firewall configuration (configure.pol) is a comma delimited file that has the following format:

RuleNum,Action,MACSource,MACDest,IPSource,IPDest,IPProtocol,PortSource,PortDest,Comment/Note

These values will be made available to you for use in your python code as a list of a dictionary object (one list item per line in your configure.pol) as STRINGS.

These items are defined as such:

There are a few particular “rules” about these fields:

•       An field not being used in a match should specify a “-“ as its entry.  A “-“ is valid for any field except Action.  Please note that when you build your POX traffic matching, do not pass a “-“ to POX or you will get an error.

•       The minimum allowable subnet mask is /24.  Do not use a /16

•       Do not use 0.0.0.0/0 to address the internat as a whole.  See statement about “-“

•       MAC vs IP Addresses?  Think about what Layer each address is used.

Example Rules (included in the project files:

1,Block,-,-,10.0.0.1/32,10.0.1.0/24,6,-,80,Block 10.0.0.1 host from accessing a web server on the 10.0.1.0/24 network 2,Allow,-,-,10.0.0.1/32,10.0.1.125/32,6,-,80,Allow 10.0.0.1 host to access a web server on 10.0.1.125 overriding rule  What do these rules do?

The first rule basically blocks host hq1 (IP Address 10.0.0.1/32) from accessing a web server on any host on the us network (the subnet 10.0.1.0/24 network). The web server is running on the TCP IP Protocol (6) and uses TCP Port 80.  

The second rule overrides the initial rule to allow hq1 (IP Address 10.0.0.1/32) to access a web server running on us5 (IP Address 10.0.1.125/32)

As mentioned earlier, these values are passed back to you via code as a list of python dictionary objects.   

“policies” is a python list that contains one entry for each rule line contained in your configure.pol file.  Each individual line of the configure.pol file is represented as a dictionary object named “policy”. This dictionary has the following keys:

•       policy[‘mac-src’] = Source MAC Address (00:00:00:00:00:00) or “-“

•       policy[‘mac-dst’] = Destination MAC Address (00:00:00:00:00:00) ) or “-“

•       policy[‘ip-src’] = Source IP Address (10.0.1.1/32) in CIDR notation ) or “-“

•       policy[‘ip-dst’] = Destination IP Address (10.0.1.1/32) ) or “-“

•       policy[‘ipprotocol’] = IP Protocol (6 for TCP) ) or “-“

•       policy[‘port-src’] = Source Port for TCP/UDP (12000) ) or “-“

policy[‘port-dst’] = Destination Port for TCP/UDP (80) ) or “-“

•       policy[‘rulenum’] = Rule Number (1)  

•       policy[‘comment’] = Comment (Example Rule)

•       policy[‘action’] = Allow or Block

Just a reminder that all items passed to you from the policy dictionary are STRINGS.  You will need to convert as needed.

Part 5:  Firewall Implementation Code

Before starting the project, please update your VM to the latest version pox by running the following four commands:

•     cd /home/mininet/pox • git pull •             git checkout ichthyosaur •            chown -R mininet:mininet ~/pox

Using the data from part 4, you will need to edit your sdn-firewall.py file to implement creating a flow modification object, traffic matching, priorities, and an action (if necessary).  You will use the “policy” to create traffic matching rules based on a configuration passed to you.  This code needs to be generic and should be able to handle all of the header parameters

(source/destination MAC, IP, and Application Ports, as well as the IP Protocol).  You will be implementing this using the POX API (an excerpted version is available in Appendix C).

Your code may include helper functions, but all such functions need to be in sdn-firewall.py.  Please do not add any additional libraries unless they are already installed on the Virtual Machine.  Your code itself should be fairly short (roughly between 20 ~ 30 lines should be all that is necessary.

By default, this is an open firewall which means no traffic is blocked unless it is blocked with a Block rule.  You write Allow rules to override a previously more broad Block rule.  These are the only two activities.

Your code should accomplish the following: •       Create an OpenFlow Flow Modification object

•       Create a POX Packet Matching object that will integrate the elements from a single entry in the firewall configuration rule file (which is passed in the policy dictionary) to match the different IP and TCP/UDP headers if there is anything to match (i.e., no “-“ should be passed to the match object, nor should None be passed to a match object if a “-“ is provided).  

•       Assign a priority to differentiate between Allow and Block

•       Create a POX Output Action, if needed, to specify what to do with the traffic.  

Your code should start by rewriting the “rule = None” from the sdn-firewall.py file.

Some tips:

•       If POX matches a particular packet, it pulls it from the stream and does nothing with it unless you do an action to it.

•       POX traffic priorities are based on the level of exactness.  A rule that matches three items has a higher implicit priority than one that matches two.  Your Allow/Block rules need to overcome this bias.  The suggestion is to use priorities a few thousands apart.

•       Remember that you may be tested with IP Protocols other than 1, 6, and 17.  In addition, remember that “-“ is a valid value for IP Protocol.

•       If Application Source or Destination port is specified, you may assume that you must specify IP Protocols 6 or 17.  You will not be tested with an invalid rule.

You may assume that all traffic is IPV4.  If you get weird errors about missing prerequisites, you may want to check to see if you are matching IP Type.  It is allowable to specify this for all rules, but only certain rules actually require it.

Part 6:  Firewall Configuration Requirements

You will need to submit a configure.pol firewall configuration file to create policies that implement the following scenarios. You may implement your rules in any manner that you want, but it is recommended using this step as an opportunity to check your firewall code implementation. The purpose of these rules is to test your firewall and to help determine how traffic flows across the network (source vs destination, protocols, etc).

DO NOT block all traffic by default and only block/allow traffic specified.  You will lose many points because the firewall is open by default and only blocks the traffic that is specified.   You do not need to remove the two example rules as they do not conflict with any of the tasks below.  The rule counts given below are the typical minimum needed to satisfy this rule.

CIDR Primer Video:  https://www.youtube.com/watch?v=7FZRDqVLgRg The corporate networks are described as follows:

•       Headquarters (hosts hq1-hq5) on the 10.0.0.0/24 subnet

•       US Network (hosts us1-us5) on the 10.0.1.0/24 subnet

•       India Network (hosts in1-in5) on the 10.0.20.0/24 subnet

•       China Network (hosts cn1-cn5) on the 10.0.30.0/24 subnet

•       UK Network (hosts uk1-uk5) on the 10.0.40.0/24 subnet

There are also two additional hosts defined – wo1/wo2 or world1/world2.  These are used to test world connections.  DO NOT USE THEIR IP OR MAC ADDRESSES IN YOUR RULES OR YOU WILL LOSE POINTS.

You may find the MAC and IP Addresses for these hosts in your sdn-topology.py file.

Firewall Rules for Spring 2026:

•       Task 1:  Host cn4 has a TCP-based worm virus.  Block cn4 from initiating network communications to any host on the internet (world) including all of the corporate networks over the TCP Internet Protocol.  You need not block ICMP or UDP. (one rule max)

•       Task 2:  Host cn5 has had a security incident and needs to be completely isolated so it has no connectivity (incoming or outgoing) to any other host in the world including the corporate networks. (two rules max)  

•       Task 3:  Allow all of the hosts on the  Headquarters network to be reachable via an ICMP ping from the world including the OTHER corporate networks.  In addition, the other corporate subnets (except HQ and China) should not be pingable from the world.  However, to satisfy the first half of this task, you must allow the Headquarters network to be able to ping the US, UK, and India subnets.  Can you explain why this must happen?  (six rules typically)   

The China network is exempted from this rule because any overrides that you may do here will override aspects of Task 1 or Task 2 above (in other words, create no Block or Allow rules that involve the China Network).  It is undefined whether or not the US,UK, or IN networks should be able to ping each other, so you may configure your rules as you wish.   

•       Task 4:  Do not allow any response back from a TCP web server (http and https) running on host cn3 to any other host on the internet (world). (two rules max)  Use the standard application ports for HTTP and HTTPS.

•       Task 5:  (CIDR Notation Rule)  The servers located on hosts us3 and us4 run a micro webservice on TCP Port 9520 that processes financial information. Access to this service should be blocked from hosts uk2, uk3, uk4, uk5, in4, in5, us5, and hq5. Please use the minimal CIDR notation that will bracket the subset of hosts for each rule (it should NOT be broader than /28). (four rules typical)

Task 6:  A rogue Raspberry Pi has been found on the network that has cloned the Hardware Address (or physical network address) of host us1.  Block this device from accessing any other hosts on the internet (world) on the UDP Internet Protocol. (one rule max)  Note that when testing this rule, the IP address for host us1 may differ from the published topology.  In this case, you want to address the particular hardware network address.  Note that this rule indicates that host us1 will be blocked as well as the Pi, which is acceptable)

•       Task 7:  Block the internet (world) from accessing TCP Port 25 on any of the corporate subnets.  The behavior of access to TCP Port 25 amongst members of the corporate subnets is undefined and you may handle it as you wish. (five rules max)

Part 7:  What to Turn In and Grading Rubric

You need to submit your copy of packetcapture.pcap, sdn-firewall.py and configure.pol from your project directory using the zip command. To recap, zip up the three files using the following command, replacing gtlogin with your GT Login that you use to log into Canvas:

zip gtlogin_sdn.zip packetcapture.pcap configure.pol sdn-firewall.py 

The key to properly zipping the project is to NOT zip up the directory.  ZIP only the files you are included.  

It is not important that the ZIP file contain your name.  Also, note that resubmittals will attach a -1 or -2 to the filename which is acceptable.  The autograder script will pull the last submission.  

You may also include an additional text file if you have comments, criticisms, or suggestions for improvement for this project. If you wish to provide this information, add it to your ZIP file with the name comments.txt. This is completely optional.

IMPORTANT NOTE

Please check your submission after uploading. Many people have uploaded the wrong file to Canvas.  Please re-download from Canvas after submission and unzip the files to make sure you have submitted all of the proper files and for the files for the correct project. 

For the Fall 2025 Semester, this project is worth a total of 100 points which is distributed in the following fashion:

•       5 points for submitting a version of sdn-firewall.py that indicates effort was done.

•       5 points for submitting a version of configure.pol that indicates effort was done.

•       15 points for submitting a version of packetcapture.pcap that indicates effort was done.

•       25 points for testing your configure.pol file with a known-good implementation.   

•       25 points for testing your configure.pol with your implementation.

•       25 points for testing your implementation with an alternate configure.pol and topology.

Note that if you get full credit for your configure.pol and your code implementation, you will automatically get full credit with the known-good implementation.

Part 8:  What Can and Cannot Share

Do not share the content of your sdn-firewall.py, configure.pol, or packetcapture.pcap with your fellow students, on Ed Discussions, or elsewhere publicly. You may share any new topologies, testing rulesets, or testing frameworks, as well as packet captures that do not address the requirements of Part 6.

Part 9:  Troubleshooting Tips

There is a post on EdStem that references common error conditions and how to resolve them.  Please review that post in order to help with any error messages that you may receive while running or coding the project.