Force connection tracking & ICMP

[wbeine]

If I'm already dropping inputs & forwards in WAN zone, and dropping invalid packets, is there a point in Forced Connection Tracking? Still learning as I go so please forgive the question if it's an easy one. I read in another blog that you have to have forced conn tracking if you want stateful firewall.

Not running a website or need remote access, just trying to protect home devices. Would you also drop some of the ICMP inputs & forwards as well? Please let me know your thoughts.

[lleachii]

NAT (or your masquerading to WAN) requires connection tracking by default.

Example: If you have a block of IPs from your ISP, and therefore will not NAT - you may need to enable this in order to firewall such traffic.

[wbeine]

Thank you lleachii. So if I'm reading this correctly, I should turn on Forces conn tracking. Or are you saying it occurs by default? What are your thoughts regarding ICMP.

[Mushoz]

Since Masquerading (NAT) is enabled on your WAN interface, it means that conn tracking is already taking place. You can force it to enabled, but it will not change anything. Forcing Conn tracking is only useful if you want to do conn tracking in the absence of NAT.

[jeff]

@wbeine

What are your thoughts regarding ICMP

What ICMP to permit and what to drop is a bit of philosophy.

If you're using IPv6, then there are certain ICMPv6 packets that you must allow or IPv6 will "break".

On IPv4, many ICMP packets once thought useful and benign have become obsolete over the years and can generally be blocked.

ping and responses are one of those gray areas. Personally, I find ping too useful to block when resolving connectivity issues. Rate limiting can help prevent DoS on ping.

There are volumes of suggestions and opinions on this. Pretty much every discussion of firewalls puts forth some suggestions.

My present, personal choice on "home" routers is along the lines of (trimming down to sub-types of ICMPv6 is still on my to-do list)

    icmp type { destination-unreachable, 
                source-quench, 
                time-exceeded
    } accept

    icmp type echo-request ct state new accept

    ip6 nexthdr icmpv6 icmpv6 type {
        destination-unreachable,     # 1
        packet-too-big,              # 2
        time-exceeded,               # 3
        parameter-problem,           # 4
        nd-neighbor-solicit,         # 135
        nd-neighbor-advert           # 136
    } accept

    # RA -- from router's link-local to ff02::1
    # RS -- from host's link-local to ff02::2

    ip6 nexthdr icmpv6 icmpv6 type nd-router-solicit ip6 daddr ff02::2 \
        accept                       # 133

    ip6 nexthdr icmpv6 icmpv6 type nd-router-advert  ip6 daddr ff02::1 \
        accept                       # 134

    ip6 nexthdr icmpv6 icmpv6 type echo-request ct state new accept

I don't respond to ICMPv4 fragmentation-needed as IPv4 should handle any needed fragmentation at routers along the way, and my first-hop, upstream MTU is at least 1500, which is the MTU of the Ethernet interface connected to that path. IPv6, however, does not fragment along the path, so it becomes the sender's responsibility to accommodate end-to-end PMTU.

Note that I only accept echo-response that are associated echo-requests (using conntrack).

Edit: Removed ICMPv4 redirect as the situation when my network uses it is entiely internal and unlikely to impact home-to-ISP connections.

[wbeine]

Thank you Jeff for this response!!! Very helpful. I appreciate your time.

[wbeine]

Thank Mushoz!!