In this project, you will use Software Defined Networking (SDN) principles to create a configurable firewall using an OpenFlow enabled Switch. The Software Defined Networking (OpenFlow) functionality allows you to programmatically control the flow of traffic on the network.

This project has two phases (and one optional phase) as follows:

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

There are a few videos describing various aspects of the project. Please refer to the Project Description for the current links to the different videos. These videos include:

Unzip the SDNFirewall-Fall2025.zip file into your Virtual Machine. You can extract to any folder on your system. Do this by running the following command:

First, please update the POX version installed on the VM to the latest branch by running the following:

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

Change to the folder where you stored your SDNFirewall-Fall2025.zip file and run the following command.

This will extract the files for this project into a directory named SDNFirewall at your current path (it is recommended that your use the mininet root directory to aid in troubleshooting (cd ~ ). The following files will be extracted:

This file will clean up the Mininet Environment and kill all zombie Python and POX processes.

This file will create the appropriate POX framework and then integrates the rules implemented in sdn-firewall.py into the OpenFlow engine. It will also read in the values from the configure.pol file and validate that the entries are valid. If you make changes to this file, the autograder will likely have issues with your final code as the autograder uses the unaltered distribution version of this file.

Project Deliverables

If you did not complete the Simulating Networks Optional Project, you may want to review the “Mininet Review” section in Appendix D 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.

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 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 Video if you would like to follow along in time for a live packet capture.

This topology matches the topology that you will be using when creating and testing your firewall. To start this topology, run the following command:

This will startup a Mininet session with all hosts created. If you use sdn-topology.py, you will get a controller error. Ctrl-C and redo step 2 to get the correct topology.

export PS1=”hostname >” replacing hostname with the actual hostname.

Type in the following commands at the Mininet prompt. This is optional, but helps with identifying which xterm window belongs to which host.

in the xterm window that pops up) in the second xterm window)

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 – 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.

in us1 xterm: (hit control C after a few ping requests) In us2 xterm: (likewise hit control C after a few ping requests) In us1 xterm: 0 In us2 xterm:

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

In us1 xterm: 0 In us2 xterm:

In us1 xterm: press Control C to kill the server

In Mininet Terminal: press Control C to stop tshark

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 us1 making web request to Host 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.

Using the information that you learned above in running Wireshark, you will be creating two files – one is a firewall configuration file that will specify different header parameters to match in order to allow or block certain traffic that will define the actions of the firewall and the second is the implementation code to create the OpenFlow Flow Modification objects that will create the firewall using the parameters given in the firewall configuration file.

The configure.pol file is used by the firewall implementation code to specify the rules that the firewall will use to govern a connection. You do not need to code this first, but the format of the file is important to understand as your implementation code will need to use these items. The format of the file is a collection of lines that have the proper format:

Rule Number, Action, Source MAC, Destination MAC, Source IP Network Address,

Destination IP Network Address, Protocol, Source Port, Destination Port, Comment/Note

The IP address of a particular host is defined inside the sdn-topology.py file.

Special Notes About Firewall Configurations:

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)

By definition – from the sdn-topology.py file:

This class defines the Mininet Topology for the network used in this project. This network consists of the following hosts/networks: (THESE 5 SUBNETS ARE ALSO REFERRED TO AS THE CORPORATE NETWORKS)

Headquarters Network (hq1-hq5). Subnet 10.0.0.0/24

US Network (us1-us5). Subnet 10.0.1.0/24

India Network (in1-in5). Subnet 10.0.20.0/24

China Network (cn1-cn5). Subnet 10.0.30.0/24

UK Network (uk1-uk5). Subnet 10.0.40.0/24

In Part 5, you will be given a set of firewall conditions that you will need to create the configure.pol needed for your submission.

You may create temporary rulesets to help you complete Part 5b below.

After reviewing the format of the configure.pol file, you will now code a generic implementation of a firewall that will use the values provided from the configuration file (passed to you as dictionary items). As it is provided, the firewall implementation code blocks no traffic. You must implement code that does the following:

Please reference code examples in Appendix C, or you may refer to the POX API documentation (WARNING, this is long and the API is confusing).

You will need to rewrite the rule = None to reference your Flow Modification object.

Your code will go into a section that will repeat itself for every line in the firewall configuration file that is passed to it. The “rule” item that is added to the “rules” list is an OpenFlow Modification object. The process of injecting this rule into the POX controller is handled automatically for you in the start-firewall.py file.

TIP: If your implementation code segment is more than 25-30 lines, you are making it too difficult. The POX API can provide many features that are not used in this project. The Appendix provides all of the information that you will need to code the project.

Key Information:

Use these to match traffic. Please note that all fields are strings and may contain a “-“ character.

You will need to assume that all traffic is IPV4. It is acceptable to hardcode this value. Do not hardcode other values. Your code should be generic enough to handle any possible configuration.

You will need to submit a configure.pol 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 allow traffic specified. You will lose many points because the firewall is open by default and only blocks the traffic that is specified.

Firewall Rules for Summer 2025:

(world) including the corporate networks. (two rules max)

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.

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.

You need to submit your copy of packetcapture.pcap, sdn-firewall.py and configure.pol from your project directory using the instructions from the Piazza Post “How to Submit / Zip Our Projects. To recap, zip up the two 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.

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.

Please check your submission after uploading. As usual, we do not accept resubmissions past the stated deadlines.

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 4b.

Rubric

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

(There is a Youtube Video posted that depicts how to manually test)

When you are developing your implementation or troubleshooting a firewall rule, you will want to test by hand. Unfortunately, this process is a bit difficult.

1,Block,-,-,10.0.0.1/32,10.0.1.0/24,6,-,80,Block 10.0.0.1 from accessing a web server on the

10.0.1.0/32 network

Startup Procedure:

This should start up POX, read in your rules, and start up an OpenFlow Controller. You will see something like this in your terminal window:

This should start up mininet and load the topology. You should see the following:

This will start the firewall and set the topology. You do not need to repeat Steps 1-3 unless you are done testing, need to restart the firewall, or need to restart mininet. When you are done with testing all of the rules you intend to use, type in “quit” in the mininet window, close all of the extraneous xterm windows generated, and run the mininet cleanup script ./cleanup.sh How to test connectivity between two hosts:

Two windows should have popped up. You can always identify which xterm is which by running the command: ip address from the bash shell. This will give you the IP address for the xterm window, which will then let you discover which xterm window belongs to which host.

This sets up the test server for us1 that will be listening on TCP port 80. The IP Address specified is always the IP address of the machine you are running it on. If you attempt to start the test-server on a machine that does not have the IP address that is specified in the command, you will get the following error: OSError: [Errno 99] Cannot assign requested address.

o Step 6: In the xterm window for hq1 (which is the source host of the rule – remember that the source is always the client), type in the following command:

This will start up a client that will connect to the TCP Port 80 on the server 10.0.1.1 (destination IP address) and will send a message string to the server. However, if the firewall is set to block this connection, you will never see the message pass on either of the client or the server.

Examples of Connection Status:

You may hit Control C to kill both the server and the client.

Ensure that you do not have a Unspecified Prerequisite Error

Repeat this process for every rule you wish to test. If you feel that after some initial testing that your implementation and ruleset is good, you may then proceed to using the automated test suite.

The automated Test Suit was developed by a student in Summer 2021 (htian66) and has been updated to match the current version of this project. There are two test suites – one that tests your implementation with the configure.pol you created that matches the rules in Part 5, and the second that is a generic test of your implementation with a different topology and provided configuration policy. The first test suite will be the exact same one used in the autograder that will be used after you turn the project into Canvas.

How to test normal cases:

True indicates that a connection was made or was expected. False indicates the opposite condition.

How to test alternate cases: (DO THIS FIRST AFTER PYTHON IMPLEMENTATION)

True indicates that a connection was made or was expected. False indicates the opposite condition.

“python.autoComplete.extraPaths”: [ “/home/mininet/pox/” ],

Also, with Visual Studio code, it sometimes “recommends” _dl_type and other names prepended with a _. Note that this is incorrect – the name is dl_type, not _dl_type.

This section contains a highly modified excerpt from the POX Manual (modified to remove extraneous features not used in this project and to provide clarifications). You should not need to use any other POX objects for this project. TA Comments are highlighted. Everything on these pages is important to complete the project.

Excerpted and modified from: https://noxrepo.github.io/pox-doc/html/ Object Definitions:

The main object used for this project is a “Flow Modification” object. This adds a rule to the OpenFlow controller that will affect a modification to the traffic flow based on priority, packet characteristic matchin, and an action that will be done to the traffic that is matched. IF AN OBJECT is matched, it is pulled from the network stream and will only be forwarded, modified, or redirected if you do an action. If you do not specify an action and the packet is matched, the packet will basically be dropped.

The following class descriptor describes the contents of a flow modification object. You need to define the match, priority, and actions for the object.

class ofp_flow_mod (ofp_header): def __init__ (self, **kw): ofp_header.__init__(self) self.header_type = OFPT_FLOW_MOD self.match = ofp_match()

self.priority = OFP_DEFAULT_PRIORITY self.actions = []

OpenFlow defines a match structure – ofp_match – which enables you to define a set of headers for packets to match against.

The match structure is defined in pox/OpenFlow/libOpenFlow_01.py in class ofp_match. Its attributes are derived from the members listed in the OpenFlow specification, so refer to that for more information, though they are summarized in the table below.

You should create a match object and attach it to the flow modification object.

Attribute Meaning dl_src Ethernet/MAC source address (Type of EthAddr) dl_dst Ethernet/MAC destination address (Type of EthAddr) dl_type Ethertype / length (e.g. 0x0800 = IPv4) (Type of Integer) nw_proto IP protocol (e.g., 6 = TCP) or lower 8 bits of ARP opcode (Type of integer) nw_src IP source NETWORK address (Type of String) nw_dst IP destination NETWORK address (Type of String) tp_src TCP/UDP source application port (Type of Integer) tp_dst TCP/UDP destination application port (Type of Integer)

TA Note: (IMPORTANT_

If you use VSCode or Pycharm, it may make the recommendation to use _dl_src and _dl_dst. These are not valid. Please use what is specified above.

Attributes may be specified either on a match object or during its initialization. That is, the following are equivalent:

matchobj = of.ofp_match(tp_src = 5, dl_type = 0x800,dl_dst = EthAddr(“01:02:03:04:05:06”))

#.. or ..

matchobj = of.ofp_match() matchobj.tp_src = 5 matchobj.dl_type = 0x800

matchobj.dl_dst = EthAddr(“01:02:03:04:05:06”)

IMPORTANT NOTE ABOUT IP ADDRESSES

TA Note: What isn’t very clear by this documentation is that nw_* is expecting a network address.

If you are calling out an IP Address like 10.0.1.1/32, it is an acceptable response to nw_*. However, if you are calling out a subnet like 10.0.1.0/24, the IP address portion of the response MUST BE the Network Address.

From Wikipedia: IP addresses are described as consisting of two groups of bits in the address: the most significant bits are the network prefix, which identifies a whole network or subnet, and the least significant set forms the host identifier, which specifies a particular interface of a host on that network. This division is used as the basis of traffic routing between IP networks and for address allocation policies. (https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing)

Thus for a /24 network, the first 24 bits of the address comprises the network address. Thus, it would be 10.0.1.0. For a /25 network, there would be two networks in the 10.0.1.x space – a 10.0.1.0/25 and a 10.0.1.128/25.

Your implementation code does NOT need to convert the given IP Address into a network – you can assume that any given address in a possible configuration file must be valid. However, your configure.pol file MUST be using the proper form if you are using a CIDR notation other than /32. Why would you do this? To reduce the number of rules needed. You may use this for the 5th rule from Part 6.

Note that some fields have prerequisites. Basically this means that you can’t specify higher-layer fields without specifying the corresponding lower-layer fields also. For example, you can not create a match on a TCP port without also specifying that you wish to match TCP traffic. And in order to match TCP traffic, you must specify that you wish to match IP traffic. Thus, a match with only tp_dst=80, for example, is invalid. You must also specify nw_proto=6 (TCP), and dl_type=0x800 (IPv4). If you violate this, you should get the warning message ‘Fields ignored due to unspecified prerequisites‘.

This question also presents itself as “What does the Fields ignored due to unspecified prerequisites warning mean?”

Basically this means that you specified some higher-layer field without specifying the corresponding lower-layer fields also. For example, you may have tried to create a match in which you specified only tp_dst=80, intending to capture HTTP traffic. You can’t do this. To match TCP port 80, you must also specify that you intend to match TCP (nw_proto=6). And to match on the TCP protocol, you must also match on IPV4 type (dl_type=0x800).

The final aspect needed to fully implement a flow modification object is the action. With this, you specify what you want done to a port. This can include forwarding, dropping, duplicating and redirecting, or modify the header parameters. For the purposes of this project, we are only dealing with forwarding of match traffic to its destination. But please note that for a Software Defined Network system, you can do all sorts of actions including round robin server, DDOS blocking, and many other possible options.

Output

Forward packets out of a physical or virtual port. Physical ports are referenced to by their integral value, while virtual ports have symbolic names. Physical ports should have port numbers less than 0xFF00.

port (int) the output port for this packet. This is a bit misleading because it can confuse you with the application “port” for TCP/UDP. For openflow, this port represents the physical swith port that the host is plugged into. However, you do NOT know which physical port on which switch a host is connected to.

Thus, you will need to use one of the virtual ports to define what you want to happen:

Think carefully about the definitions given above for output actions. Remember that if you match a packet, no action (i.e., packet will be dropped) will be done unless you set an output action as the packet is pulled from the stream until it is resolved.

The following example describes how to create a flow modification object including matching a destination IP Address, IP Type, and Destination IP Port, and setting an action that would redirect the matching packet out to physical switch port number 4 (note that you generally DO NO KNOW what physical switch port to use.

Flow Modification Objects work as thus:

For this project, you are making a flow modification object and action while using a matching pattern that can match any or all of the different parameters of the header. Make your implementation generic.

Mininet is a network simulator that allows you to explore SDN techniques by allowing you to create a network topology including virtual switches, links, hosts/nodes, and controllers. It will also allow you to set the parameters for each of these virtual devices and will allow you to simulate real-world applications on the different hosts/nodes.

The following code sets up a basic Mininet topology similar to what is used for this project:

#!/usr/bin/python

from mininet.topo import Topo from mininet.net import Mininet

from mininet.node import CPULimitedHost, RemoteController from mininet.util import custom from mininet.link import TCLink

from mininet.cli import CLI

class FirewallTopo(Topo):

def __init__(self, cpu=.1, bw=10, delay=None, **params):

super(FirewallTopo,self).__init__()

# Host in link configuration hconfig = {‘cpu’: cpu}

lconfig = {‘bw’: bw, ‘delay’: delay}

# Create the firewall switch s1 = self.addSwitch(‘s1’)

hq1 = self.addHost(‘hq1′,ip=’10.0.0.1′,mac=’00:00:00:00:00:1e’, **hconfig) self.addLink(s1,hq1)

us1 = self.addHost( ‘us1′, ip=’10.0.1.1′, mac=’00:00:00:01:00:1e’, **hconfig) self.addLink(s1,us1)

This code defines the following virtual objects:

Useful Mininet Commands:

Whatsapp Us

[SOLVED] Cs6250 omscs/omscy sdn firewall with pox fall 2025

Reviews

Whatsapp Us

[SOLVED] Cs6250 omscs/omscy sdn firewall with pox fall 2025

Reviews

Related products

[SOLVED] Physics 396 homework set 9

[SOLVED] Assignment 6 cop 2220

[SOLVED] Cop 2220 assignment 4

[SOLVED] Oop244 workshop 4: constructors destructors and current object

[SOLVED] Cse6242 – hw 2: tableau, d3 graphs and visualization

[SOLVED] Cop 2220 assignment 7