1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Practicality of a reflexive firewall?

Discussion in 'Tomato Firmware' started by ArmoredDragoon, Dec 16, 2012.

  1. ArmoredDragoon

    ArmoredDragoon Serious Server Member

    I want to create a reflexive firewall on my tomato router, and I'm wondering if there is already a way to do this, and if so, is it practical?

    For anybody who doesn't know, a reflexive firewall is one where ALL incoming ports (0-65535) are always blocked unless a device internal to the network initiates an outbound connection first. When that happens, a firewall rule is created which permits the destination IP address to send return traffic to the outbound port, and expires after so much inactivity. This is superior to checking the TCP flags.

    I know something exists for linux via the ip_conntrack module, but I don't know if this is available for these routers, or if such a thing might put too much of a burden on the CPU/RAM (my router is an Asus RT-N16, which has about the same CPU/RAM as a base model C1841, sans the crypto hardware.)
  2. occamsrazor

    occamsrazor Network Guru Member

    Isn't this the same as Port Triggering and already available in Tomato?
    Menu > Port Forwarding > Triggered
  3. koitsu

    koitsu Network Guru Member

    This is what's referred to as Port Triggering (as occamsrazor said).

    However, you should be aware that you may have to add exceptions to the "reflexive" model for certain TCP and UDP ports (i.e. certain traffic needs to be unsolicited) depending on what your usage/needs are.

    Also be aware that Port Triggering relies on an assumption model where there is an internal timeout used to determine when a allowed port should have its permit/allowance "rule" removed. This is a separate timeout from the rest of the TCP model; tuning this often requires time/effort and great familiarity with your setup (and a lot of time in Wireshark or tcpdump). For example, if a TCP session can remain in ESTABLISHED state for 1800 seconds, but your internal timeout for "reflexive" model is set at 60 seconds, and an underlying program on your LAN sends a TCP PSH+ACK or TCP ACK packet after 60 seconds, it's going to get pissed off/confused because your "reflexive" model quite literally just dropped a packet on the floor. This is usually why I don't recommend that model.

    Finally, the "reflexive" model is not superior to checking TCP flags, particularly from a security perspective. There are absolutely, hands down, no argument cases where you absolutely want to check TCP flags for certain combinations to be approved, while others should be rejected. I strongly recommend you look at things like FreeBSD/OpenBSD's pf.conf (search for "flags S/SA") for examples of this. Consider this your warning -- I would not want to use a network where the admin believed in "avoiding TCP flags". I would not trust this network.

Share This Page