Changes

<tr><th>Step</th><td>'''Procedure'''</td><td>'''Explanation'''</td></tr>

<tr> <th>1</th><td>'''Test Network Connectivity'''</td><td>You can use the [http://zenit.senecac.on.ca/wiki/index.php/OPS335_Lab_1#Linux_Network_Connection_Configuration_Troubleshooting steps in lab 1] as a guide, but keep in mind the firewall may be blocking pings and DNS requests.</td></tr>

<tr> <th>3</th><td>'''List your iptables Rules &amp; Perform a "Walk-Thru"'''</td><td>For many decades, when troubleshooting programs that don't run properly, programmers will resort to reading their "source-code" line-by-line and pretend they are the computer to perform the operation. The programmer "walks-through" the code to force them to think like a computer in order to spot and fix subtle problems.<br><br>Therefore, you can follow a packet's path as you understand it should follow. Keep in mind [http://zenit.senecac.on.ca/wiki/index.php/OPS335_Lab_2#How_Firewalls_.28iptables.29_Relate_to_the_Labs_in_this_Course the diagram from the lecture last week]. What chain applies first on which machine? What's the first rule that matches the packet? What happens if no rules match the packet?<br><br>Don't forget that even if you're tracing the path of outgoing traffic - the INPUT chain on your machine still applies (for the response that comes back to your request).</td></tr>

<tr> <th>4</th><td>'''Use the log target to list unexpected traffic'''</td><td>Add a final rule to your input chain to log all traffic. Any traffic you are allowing will have already been accepted and will not reach this rule, so you will start a log of all the packets you are not allowing. Observing the logs while you attempt to use the service that is not being allowed will show you the type of traffic you need to allow.</td></tr>