Assistance with Firewall rules regarding Wireguard

Hi everyone,

I’ve had Wireguard configured and working fine on VyOS 1.3.
However I’ve migrated to 1.4 and I’m still learning nftables rules and chaining.

While following the documentation seems to not have been updated regarding the firewall rules, since it still mentions IPTables concepts, specifically:

set firewall ipv4 name OUTSIDE_LOCAL rule 10 action accept
set firewall ipv4 name OUTSIDE_LOCAL rule 10 description 'Allow established/related'
set firewall ipv4 name OUTSIDE_LOCAL rule 10 state established enable
set firewall ipv4 name OUTSIDE_LOCAL rule 10 state related enable
set firewall ipv4 name OUTSIDE_LOCAL rule 20 action accept
set firewall ipv4 name OUTSIDE_LOCAL rule 20 description WireGuard_IN
set firewall ipv4 name OUTSIDE_LOCAL rule 20 destination port 51820
set firewall ipv4 name OUTSIDE_LOCAL rule 20 log enable
set firewall ipv4 name OUTSIDE_LOCAL rule 20 protocol udp
set firewall ipv4 name OUTSIDE_LOCAL rule 20 source
set interfaces ethernet eth0 firewall local name 'OUTSIDE-LOCAL'

https://docs.vyos.io/en/sagitta/configuration/interfaces/wireguard.html#firewall-exceptions

This config path technically doesn’t exist in 1.4, as such I’m looking if you can assist me in understanding what I might be missing on my configuration.

I’m only using IPv4 (I’m dropping IPv6 packets and set anything ipv6 as disabled in the global options).
My firewall configuration is mostly the quick started guide.

ipv4 {
     forward {
         filter {
             rule 10 {
                 action jump
                 jump-target CONN_FILTER
             }
             rule 100 {
                 action jump
                 destination {
                     group {
                         network-group NET-INSIDE
                     }
                 }
                 inbound-interface {
                     group WAN
                 }
                 jump-target OUTSIDE-IN
             }
         }
     }
     input {
         filter {
             default-action drop
             rule 10 {
                 action jump
                 jump-target CONN_FILTER
             }
             rule 15 {
                 action jump
                 inbound-interface {
                     group WAN
                 }
                 jump-target WAN-IN-INPUT
             }
         }
     }
     name CONN_FILTER {
         default-action return
         rule 10 {
             action accept
             state established
             state related
         }
         rule 20 {
             action drop
             state invalid
         }
     }
     name OUTSIDE-IN {
         default-action drop
     }
     name WAN-IN-INPUT {
         default-action drop
         rule 100 {
             action accept
             description "Wireguard WG01"
             destination {
                 port <My_wireguard_port>
             }
             log
             protocol udp
         }
     }

Then I have a NAT Source Masquerade rule:

 source {
     rule 100 {
         outbound-interface {
             group WAN
         }
         source {
             group {
                 network-group NET-INSIDE
             }
         }
         translation {
             address masquerade
         }
     }
     rule 200 {
         outbound-interface {
             group WAN
         }
         source {
             group {
                 network-group WIREGUARD
             }
         }
         translation {
             address masquerade
         }
     }
 }

Under operation mode, when I run show interfaces wireguard detail I only have a few dropped packets, which I assumed was due to me enabling persistent-keepalive 15 on the server (VyOS) to test.

wg01: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 172.16.10.1/24 brd 172.16.10.255 scope global wg01
       valid_lft forever preferred_lft forever
    inet6 fe80::fd4c:baff:feba:b8c6/64 scope link
       valid_lft forever preferred_lft forever
    Description: Wireguard Home Personal

    RX:  bytes  packets  errors  dropped  overrun       mcast
             0        0       0        0        0           0
    TX:  bytes  packets  errors  dropped  carrier  collisions
             0        0       0        3        0           0

Doing show log firewall name WAN-IN-INPUT rule 100 I get nothing.

Considering that Wireguard is running on VyOS, I assumed that the traffic would be considered as “input”, is this correct?

I also assumed that “forward” traffic coming from WAN, will only happen for connections that suffer NAT, which in my case I don’t have any destination NAT rules as I didn’t need them to have Wireguard work in 1.3.

Any ideas what I’m I missing?

Thanks.

1 Like

Ok, after spending a couple hours around this I found out the following so far:

  • Adding the Chain name “WAN-IN-INPUT” to the forward chain made no difference.
  • Checking Firewall logs in VyOS doesn’t seem to follow the names of the chains and not having auto-complete suggestions makes it more difficult.
    Still, after some trial and error, I figure it out more a less.
    Starts with ipv4 (for ipv4 chains), than has the chain name. For example:
    • ipv4-CONN_FILTER shows log lines for ipv4-CONN_FILTER-default-R. Example: Apr 20 01:50:39 vyos kernel: [353555.582300] [ipv4-CONN_FILTER-default-R]IN=eth1 OUT=eth0.2 ...
    • ipv4-NAM-WAN-IN-INPUT shows lines for ipv4-NAM-WAN-IN-INPUT-100-A, e.g.: Apr 20 02:04:09 vyos kernel: [354365.674855] [ipv4-NAM-WAN-IN-INPUT-100-A]IN=eth0.2 OUT= ...
  • I added to WAN-IN-INPUT rule 100, state new.

So now I have further questions.

  1. When something is logged, does it mean the action defined on that rule is applied? For example, the line ipv4-NAM-WAN-IN-INPUT-100-A seems to correspond to firewall ipv4 name WAN-IN-INPUT which has Action accept.
  2. What is the meaning of the last letter on the log name?
    For example, ipv4-NAM-WAN-IN-INPUT-100-A rule is Accept, and ipv4-CONN_FILTER-default-R is Return. Is this accurate?
  3. On the log entries for the traffic reaching VyOS from the WAN, doesn’t have an “OUT=” value. What does this mean? Is it due to being on the Input traffic path of the Firewall?

Thanks

Answer to question 1: yes.
Answer to question 2: yes. See Syslog questions.
Answer to question 3: IN is the incoming interface. For inbound traffic hitting VyOS for the first time that is not routed elsewhere (meaning: router itself is the destination) you will not see an entry for OUT. Traffic traversing firewall (that is: being routed) you will always see both the IN and OUT fields populated.

1 Like

Thanks for the clarifications.

I can see the traffic hitting my Wireguard rules that accept it.
However, I don’t see any packets hit the wg01 interface.
Do you have any idea why no traffic is reaching Wireguard?

Type sudo wg to see the wireguard underlay statistics. What do you see under transfer? You should have non-zero values for received and sent if the tunnel underlay is functioning.

It only shows the current configuration:
image

Alright, I’ve figured it out and was a really dumb mistake.

I messed up the public-key on the peer configuration, hence any response from Wireguard would never work.

Fixing the peer public-key, the connection was established successfully.

1 Like