Home vyos configuration review & feedback

Hey, I am mostly done configuring my vyos router. I have to add IPv6 tunnel & IPv6 firewall rule and improve monitoring. I would like to collect feedback on my config so far and improve what I can. Thank you for reviewing it!

I also have another question. I have VLAN150 & VLAN160. VLAN150 is WAN1 only and VLAN160 is WAN2 only. How do achieve this? Rest of the VLANs use WAN with failover where as with these two, traffic either goes through the respective WANs or it doesn’t go at all. How do I achieve this? I did see traffic-policy but I am a little bit confused on how do I set this up?

conf.txt (45.1 KB)

I have destination nat rules to allow incoming traffic on 80, 443, 9001, 51411, 51413 ports and yet I can not reach any thing on these ports from outside.

I added a firewall rule on input chain(this is new rule #3)

 action accept
 destination {
     group {
         port-group OPEN_PORTS
     }
 }
 protocol tcp_udp

and still nothing

I had to add this rule in forward chain and now it works

You may use connection-status in forward chain to allow all dnat connections.
Check this post for example:

You may add similar rules on base chain forward, at the top, next to state rules

2 Likes

Awesome, thank you! I’ll add this instead then

Made the suggested changes and included a new revision of my config in this post.
conf.txt (48.9 KB)

Now just a few more things left.

  1. Selective routing of WAN traffic from some hosts over a VPN tunnel.
  2. IPv6 firewall
  3. IPv6 tunnel either within wireguard or 6in4

Please let me know if there is any thing else I can improve, thank you!

Version 3 of my config!

Selective routing is done, IPv6 firewall and tunnel is pending.

For selective routing, I use route policy and a black hole route to make sure it’s either WAN1(or WAN2) or nothing!

All the local traffic, Traffic touched by DNAT rules or route policies has to excluded in load-balancing system.

In Load balancing rules, I can not specify groups so I have to add a rule like this :confused:

        rule 6 {
            description "Exclude WAN4 traffic"
            destination {
                address "0.0.0.0/0"
            }
            exclude
            inbound-interface "br0+"
            source {
                address "10.0.50.21"
            }
       }

WAN4 only clients are not in a single chunk and luckily there are a small number of such clients so I can add a few rules like this and move on.
conf.txt (51.8 KB)

Im not following what that (connection-status example) would do, care to elaborate? :slight_smile:

That is:

set firewall name wan-in rule 10 action accept
set firewall name wan-in rule 10 connection-status nat destination
set firewall name wan-in rule 10 state new 'enable'

It’s part of the metadata that conntrack handles for each tracked connection.
In this case, we are using such metada to catch during filtering all connections that were successfully dnat (the very first packet), and we are allowing them.
Information regarding metada handled by conntrack: Matching connection tracking stateful metainformation - nftables wiki

1 Like

Wouldnt we do that already by specific rule regarding < srcip > < dnated ip > action:accept in filter forward?

That is this is just a shortcut to avoid doing the above for all DNATed rules?

As in you only have to specify the DNAT and automatically that will be allowed without also having to add a specific rule for the DNATed traffic?

That is this is just a shortcut to avoid doing the above for all DNATed rules?

Yep, this is it. I didn’t want to add DNAT rule for all the port mappings and then a forward:accept rule for all of them. This was easier :sweat_smile:

Check, will implement that in my template aswell - thanks! :slight_smile:

The NAT rule shared here is not quite right and it causes problems.

I have the following dnat rules.

 rule 1 {
     destination {
         group {
             address-group !dns_servers
         }
         port 53
     }
     protocol tcp_udp
     source {
         group {
             address-group !dns_servers
         }
     }
     translation {
         address 10.0.99.14
         port 53
     }
 }
 rule 2 {
     description "Caddy 443"
     destination {
         port 443
     }
     inbound-interface pppoe0
     protocol tcp_udp
     source {
         group {
             network-group web_traffic_allowlist
         }
     }
     translation {
         address 10.0.50.3
         port 443
     }
 }
 rule 3 {
     description "Caddy 9001"
     destination {
         port 9001
     }
     inbound-interface pppoe0
     protocol tcp
     source {
         group {
             network-group web_traffic_allowlist
         }
     }
     translation {
         address 10.0.50.3
         port 9001
     }
 }
 rule 4 {
     description "Caddy 80"
     destination {
         port 80
     }
     inbound-interface pppoe0
     protocol tcp
     source {
         group {
             network-group web_traffic_allowlist
         }
     }
     translation {
         address 10.0.50.3
         port 80
     }
 }
 rule 5 {
     description "Pranjal transmission"
     destination {
         port 51413
     }
     inbound-interface pppoe0
     protocol tcp_udp
     translation {
         address 10.0.20.5
         port 51413
     }
 }
 rule 6 {
     description "Ishan QBit"
     destination {
         port 51411
     }
     inbound-interface pppoe0
     protocol tcp_udp
     translation {
         address 10.0.50.14
         port 51411
     }
 }

And then I have a rule to allow DNAT’ed traffic

 action accept
 connection-status {
     nat destination
 }
 description "Accept DNATed"
 inbound-interface {
     interface-group WAN
 }
 state {
     new enable
 }

The end result is, The following ports become accessible from public!

  1. 51413
  2. 51411
  3. 80
  4. 443
  5. 9001
  6. 53 (!! This rule is just to redirect local dns traffic to local resolver. Opening it up to public is unexpected)

The right rule should have this additional constraint on the rule with port 53. inbound-interface interface-group LAN but I can’t select a group here so I’ll be adding 7-8 similar rules with different inbound interfaces for each inbound interface.

br0.+ or br0+ syntax also does not work in this context.

Followup question regarding your config at Home vyos configuration review & feedback - #7 by ishan

I assume the vif defined in br0 are tagged 802.1Q?

But how will you define untagged traffic for a interface, will that go as IP address config on the physical interface or somewhere in the br0 setup?

Also which syntax would be used for other services that will bind to an interface?

I assume “br0.123” to select the vlan123 interface of the br0 (which then is mapped to whatever physical interfaces)?

I assume the vif defined in br0 are tagged 802.1Q?

Correct

But how will you define untagged traffic for a interface, will that go as IP address config on the physical interface or somewhere in the br0 setup?

If the interface is part of the bridge, You can specify a native vlan(or pvid). All incoming untagged traffic on that port will be tagged with pvid.

If you want to maintain the completely untagged traffic on the network and the port is a member of the bridge, then you can specify an address, dhcp server on the bridge but this is a little bit weird or uncommon setup.

Also which syntax would be used for other services that will bind to an interface?

I assume “br0.123” to select the vlan123 interface of the br0

Yep

Sorry for continue to hijacking this thread :slight_smile:

When it comes to Mikrotik but also other cases where brX are being used… any drawback of setting one bridge per zone?

Like looking at your config from Home vyos configuration review & feedback - #7 by ishan you use a single br0 for everything.

But the same could be setup with one brX per zone and then define member interfaces and which vlan id’s to be used at each physical interface.

When it comes to Mikrotik but also other cases where brX are being used… any drawback of setting one bridge per zone?

I am not sure how well adding the same ethernet interface to multiple bridges will work? I think you may run into errors like this if you try to add a physical interface to multiple bridges. This might be okay if you have discrete set of interfaces in each bridge

Its more that each physical interface will of course only exist in a single bridge with that design.

But a better one is probably to configure one bridge per vrf.

2 Likes