Sessions & reverse rules

Trust the session table

Lesson 17 of 20 · 11 min · Module 5: Troubleshooting

When a connection fails, someone will suggest a rule "for the return traffic". On a stateful firewall that suggestion is wrong, and occasionally dangerous.

Start this lesson →

Free. No installation: you write and run the code in your browser, and it is checked automatically.

By the end, you’ll be able to…

Explain how a reply is accepted without a rule
Recognise a reverse rule that should not exist
Find the real cause in the request direction

The idea

A stateful firewall accepts a reply because it belongs to a session created by an allowed request. If replies seem to be missing, the request itself was not allowed, or it never arrived. A reverse rule does not repair that. It gives the server permission to start connections of its own.

# request allowed -> session created -> reply accepted
allow tcp from lan to mail port 993
# no rule from mail to lan is needed, or wanted

01Look at the request first

A session exists only if the first packet was allowed. Check the request: is there a rule for exactly this protocol, destination and port? In this lesson the site moved to HTTPS, and the rule still allows only port 80.

02Remove the reverse rule

"allow tcp from web to lan" does not help a reply, which would be accepted through its session anyway. What it does do is let the web server open new connections to every PC in the office, which is the access a DMZ is meant to prevent.

03Read the session table on real devices

The session table shows the conversation the firewall is tracking: both directions, the translated addresses, and the policy that allowed it. No entry means the request was never allowed.

# FortiGate
diagnose sys session filter dst 10.0.2.10
diagnose sys session list

# Huawei USG
display firewall session table verbose destination inside 10.0.2.10

# Linux
conntrack -L -d 10.0.2.10

Your turn

Staff cannot open the website on web, which now uses HTTPS (tcp 443) as well as HTTP (tcp 80). Someone added a reverse rule "to fix the replies"; it did not help. Find the real cause in the request rule, fix it, and remove the reverse rule.

What the checks look for

The request to the website over HTTPS is allowed
The reply passes through its session, not through a rule
The web server cannot start connections into the office
No reverse rule remains

Try it in the editor →

Take this with you

On a stateful firewall, fix the request. Replies follow their session, and rules in the reverse direction are permissions to start new connections.

Go a little further

Put the reverse rule back next to your fixed request rule and run the lab. Read which test packet changes, and which rule now allows it.