Understanding filter firewall rules

General questions
, ,
1

Hello, I’m not seeing packets on some firewall rules I would expect to see packets on and I’m wondering if I have a poor understanding of the filter firewall rules. First I’d like to confirm whether I’ve got all this right:

The INPUT filter is for traffic destined for the router itself
The FORWARD filter is for traffic that’s going between networks
The OUPUT filter is for traffic that’s leaving the router

Here’s how my network is set up:

10.24.10.0/28 - Management, I have the vyos router, a mikrotik switch and a tp-link AP with addresses on this lan

10.24.20.0/26 - Trusted, network for trusted devices

10.24.30.0/26 - Servers, network for my servers

10.24.40.0/26 - Untrusted, untrusted devices (smart devices etc)

If I want to access the internet or the servers network from 10.24.20.2 (Trusted) then I’d be hitting the FORWARD filter

If I want to access a server on the Servers network from the Trusted network I’d be hitting the FORWARD firewall

If I want to access the router from the Trusted network I’d be hitting the INPUT firewall

For context here are the groups I’ve defined that I’m using in my rules:

------------------------- ----------------------- ----------------------- -------------
Firewall Groups
Name Type References Members
------------------------- --------------- ----------------------- -------------
GRP-ADR-TRUENAS address_group ipv4-forward-filter-400 10.24.30.2
GRP-ADR-UNTRUST-TO-SERVER address_group ipv4-forward-filter-400 10.24.40.5
10.24.40.7
GRP-IF-LAN interface_group ipv4-forward-filter-100 eth2.10
ipv4-input-filter-1000 eth2.20
eth2.30
eth2.40
GRP-IF-WAN interface_group ipv4-forward-filter-100 eth1
ipv4-input-filter-10
nat-source-10
GRP-NET-MGMT network_group ipv4-forward-filter-202 10.24.10.0/29
GRP-NET-SERVERS network_group ipv4-forward-filter-200 10.24.30.0/26
ipv4-forward-filter-201
GRP-NET-TRUSTED network_group ipv4-forward-filter-200 10.24.20.0/26
ipv4-forward-filter-201
ipv4-forward-filter-202
GRP-PT-DNS port_group N/D 53
GRP-PT-MGMT port_group ipv4-forward-filter-202 22
443
80
GRP-PT-SERVERS port_group N/D 139
445
GRP-PT-SERVERS-UDP port_group ipv4-forward-filter-201 53
GRP-PT-SERVICES port_group ipv4-forward-filter-200 N/D
GRP-PT-WEB port_group ipv4-forward-filter-400 3001
443
80
81
------------------------- ----------------------- ----------------------- -------------

And my rules for the Forward filter:

Rule Action Protocol Packets Bytes Conditions
------- -------- ---------- --------- --------- -----------------------------------------------------------------------------------------------------------------------------------
10 accept all 97539 878654950 ct state { established, related } accept
11 accept icmp 31 1612 ct state { established, related, new } meta l4proto icmp accept
100 accept all 3522 586504 iifname I_GRP-IF-LAN oifname I_GRP-IF-WAN accept
200 accept tcp 0 0 ip daddr N_GRP-NET-SERVERS tcp dport P_GRP-PT-SERVICES ip saddr N_GRP-NET-TRUSTED prefix “[ipv4-FWD-filter-200-A]” accept
201 accept udp 300 22460 ip daddr @N_GRP-NET-SERVERS udp dport P_GRP-PT-SERVERS-UDP ip saddr N_GRP-NET-TRUSTED prefix “[ipv4-FWD-filter-201-A]” accept
202 accept tcp 0 0 ip daddr @N_GRP-NET-MGMT tcp dport P_GRP-PT-MGMT ip saddr N_GRP-NET-TRUSTED accept
400 accept tcp 0 0 ip daddr @A_GRP-ADR-TRUENAS tcp dport P_GRP-PT-WEB ip saddr A_GRP-ADR-UNTRUST-TO-SERVER prefix “[ipv4-FWD-filter-400-A]” accept
default drop all 66 3960

My question is why don’t I see packets for rules 200,202 and 400? 200 should be matched by traffic generated on 10.24.20.0/26 and targeted to 10.24.30.0/26 on ports defined by the SERVICES group (it includes the other defined groups)

202 should match on traffic to management addresses from the Trusted network

400 should match on requests to my truenas system from a couple specific devices on the untrusted network

Everything is working normally so I’m assuming these packets are being matched somewhere I’m missing.

Here’s my input filter:

Rule Action Protocol Packets Bytes Conditions
------- -------- ---------- --------- ------- ----------------------------------------------------------------
10 accept all 163 32759 ct state { established, related } iifname @I_GRP-IF-WAN accept
1000 accept all 2957 410500 iifname @I_GRP-IF-LAN prefix “[ipv4-INP-filter-1000-A]” accept
default drop all 487 34410

And my output filter:

Rule Action Protocol Packets Bytes

default accept all 1646 249211

I’ve also attached the bulk of my configuration minus dhcp / user stuff. Thanks!

r01-config-10-18-25.txt (7.8 KB)

2

Your rules look fine. Are you sure you have had traffic matching this?:

10.24.20.0/26(eth2.20) to 10.24.30.0/26(eth2.30) on dports (22, 53, 80, 81, 139, 443, 445, 3001)

You can throw a log on all of the rules and look for traffic originating from 10.24.20.x and see if something weird is going on with it matching an earlier rule, but it shouldn’t based on your config.

Can you post the output of this command?:

sudo nft list table vyos_filter
3

My guess would be almost all your traffic is hitting rule 10 - allows already established connections:

                rule 10 {
                    action "accept"
                    description "Allow established/related"
                    state "established"
                    state "related"
                }

If the TCP session is already in the conntrack table, this is the rule that’ll be allowed. You could try moving your rule 200 to rule 5 and see if you start to see packets hit it.

That’s my guess anyway, looking at your config. Either that or you don’t have traffic matching the defined rule.

4

GRP-PT-SERVICES is empty, GRP-PT-SERVERS isn’t used. Should this be a single group?
Test connectivity by trying to open tcp connection using telnet to ports 139 or 445. Which probably won’t work.

Note: established/related will only match after 1st packet is allowed by another rule. It can’t match “new.”

5

GRP-PT-SERVICES isn’t actually empty, it inherits other port-groups like GRP-PT-SERVERS, so its just the op-mode output that is incorrect. The op-mode output probably needs to be updated to account for inheritance of other groups. The sets within nftables should be correct.

6

Thanks everyone for your feedback, here’s the output of the nftables command (I just created a couple new groups to account for some containers I set up):

table ip vyos_filter {
    set A_GRP-ADR-TRUENAS {
            type ipv4_addr
            flags interval
            auto-merge
            elements = { 10.24.30.2 }
    }


    set A_GRP-ADR-UNTRUST-TO-SERVER {
            type ipv4_addr
            flags interval
            auto-merge
            elements = { 10.24.40.5, 10.24.40.7 }
    }

    set N_GRP-NET-CONTAINERS {
            type ipv4_addr
            flags interval
            auto-merge
            elements = { 172.16.0.0/24 }
    }

    set N_GRP-NET-LAN {
            type ipv4_addr
            flags interval
            auto-merge
            elements = { 10.24.10.0/29, 10.24.20.0/26,
                         10.24.30.0/26, 10.24.40.0/26,
                         172.16.0.0/24 }
    }

    set N_GRP-NET-MGMT {
            type ipv4_addr
            flags interval
            auto-merge
            elements = { 10.24.10.0/29 }
    }

    set N_GRP-NET-PROVIDERS {
            type ipv4_addr
            flags interval
            auto-merge
            elements = { 10.24.30.0/26, 172.16.0.0/24 }
    }

    set N_GRP-NET-SERVERS {
            type ipv4_addr
            flags interval
            auto-merge
            elements = { 10.24.30.0/26 }
    }

    set N_GRP-NET-TRUSTED {
            type ipv4_addr
            flags interval
            auto-merge
            elements = { 10.24.20.0/26 }
    }

    set N_GRP-NET-UNTRUSTED {
            type ipv4_addr
            flags interval
            auto-merge
            elements = { 10.24.40.0/26 }
    }

    set P_GRP-PT-DNS {
            type inet_service
            flags interval
            auto-merge
            elements = { 53 }
    }

    set P_GRP-PT-MGMT {
            type inet_service
            flags interval
            auto-merge
            elements = { 22, 80, 443 }
    }

    set P_GRP-PT-SERVERS {
            type inet_service
            flags interval
            auto-merge
            elements = { 139, 445 }
    }

    set P_GRP-PT-SERVERS-UDP {
            type inet_service
            flags interval
            auto-merge
            elements = { 53 }
    }

    set P_GRP-PT-SERVICES {
            type inet_service
            flags interval
            auto-merge
            elements = { 22, 53, 80-81, 139, 443,
                         445, 3001 }
    }

    set P_GRP-PT-WEB {
            type inet_service
            flags interval
            auto-merge
            elements = { 80-81, 443, 3001 }
    }

    set I_GRP-IF-LAN {
            type ifname
            flags interval
            auto-merge
            elements = { "eth2.10",
                         "eth2.20",
                         "eth2.30",
                         "eth2.40" }
    }

    set I_GRP-IF-WAN {
            type ifname
            flags interval
            auto-merge
            elements = { "eth1" }
    }

    chain VYOS_FORWARD_filter {
            type filter hook forward priority filter; policy accept;
            ct state { established, related } counter packets 19244 bytes 119117991 accept comment "ipv4-FWD-filter-10"
            ct state { established, related, new } meta l4proto icmp counter packets 5 bytes 260 accept comment "ipv4-FWD-filter-11"
            ip saddr @N_GRP-NET-LAN oifname @I_GRP-IF-WAN counter packets 648 bytes 171403 accept comment "ipv4-FWD-filter-100"
            ip daddr @N_GRP-NET-PROVIDERS tcp dport @P_GRP-PT-SERVICES ip saddr @N_GRP-NET-TRUSTED log prefix "[ipv4-FWD-filter-200-A]" counter packets 9 bytes 540 accept comment "ipv4-FWD-filter-200"
            ip daddr @N_GRP-NET-SERVERS udp dport @P_GRP-PT-SERVERS-UDP ip saddr @N_GRP-NET-TRUSTED log prefix "[ipv4-FWD-filter-201-A]" counter packets 12 bytes 854 accept comment "ipv4-FWD-filter-201"
            ip daddr @N_GRP-NET-MGMT tcp dport @P_GRP-PT-MGMT ip saddr @N_GRP-NET-TRUSTED counter packets 0 bytes 0 accept comment "ipv4-FWD-filter-202"
            ip daddr @A_GRP-ADR-TRUENAS tcp dport @P_GRP-PT-WEB ip saddr @A_GRP-ADR-UNTRUST-TO-SERVER log prefix "[ipv4-FWD-filter-400-A]" counter packets 0 bytes 0 accept comment "ipv4-FWD-filter-400"
            counter packets 0 bytes 0 log prefix "[ipv4-FWD-filter-default-D]" drop comment "FWD-filter default-action drop"
    }

    chain VYOS_INPUT_filter {
            type filter hook input priority filter; policy accept;
            ct state { established, related } iifname @I_GRP-IF-WAN counter packets 179 bytes 34243 accept comment "ipv4-INP-filter-10"
            iifname @I_GRP-IF-LAN log prefix "[ipv4-INP-filter-1000-A]" counter packets 392 bytes 56108 accept comment "ipv4-INP-filter-1000"
            counter packets 55 bytes 4092 log prefix "[ipv4-INP-filter-default-D]" drop comment "INP-filter default-action drop"
    }

    chain VYOS_OUTPUT_filter {
            type filter hook output priority filter; policy accept;
            counter packets 415 bytes 50815 log prefix "[ipv4-OUT-filter-default-A]" accept comment "OUT-filter default-action accept"
    }

    chain VYOS_OUTPUT_raw {
            type filter hook output priority raw; policy accept;
            counter packets 415 bytes 50815 accept comment "OUT-raw default-action accept"
    }

    chain VYOS_PREROUTING_raw {
            type filter hook prerouting priority raw; policy accept;
            counter packets 20544 bytes 119385491 accept comment "PRE-raw default-action accept"
    }

    chain VYOS_FRAG_MARK {
            type filter hook prerouting priority -450; policy accept;
            ip frag-off & 0x3fff != 0x0 meta mark set 0x000ffff1 return
    }
}
7

You now have hits on rule 200, so you just didn’t generate any traffic that would hit that rule when you ran the op-mode command.

The same is likely true for your other rules, or your addressing is wrong. Just generate traffic that would match those rules. You can use tcpdump on VyOS to verify the packets are arriving and verify the addressing is what you think it is.

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.