Group alias "OpenVPN net" do not match in ruleset

[tobiasstein]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [ ✓] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [✓ ] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Description

With OPNsense 21.7+ an 22.1+
the (group) alias "OpenVPN net" does not match,
when it is used in the firewall ruleset.

To Reproduce

Steps to reproduce the behavior:

1. Setup a working OpenVPN server.
   1. Assign a Tunnel network of 192.168.249.0/24
   2. The OpenVPN assistent adds a default allow rule to the firewall ruleset "OpenVPN (group)".
2. Add an network alias "OpenVPN_net_custom" 192.168.249.0/24
3. Add some ACEs to the ruleset "OpenVPN (group)"
   1. Rule that with builtin dynamic alias
      • Proto: IPv4+6 ICMP
      • Src: "OpenVPN net"
      • Src_Port: any
      • Dst: "This Firewall"
      • Dst_Port: any
      • Gateway: any
      • Schedule: -
      • Description: "Allow ICMP"
      • Log packets that are handled by this rule: true
   2. Rule that match with custom alias
      • Proto: IPv4+6 ICMP
      • Src: "OpenVPN_net_custom"
      • Src_Port: any
      • Dst: "This Firewall"
      • Dst_Port: any
      • Gateway: any
      • Schedule: -
      • Description: "Allow ICMP custom alias"
      • Log packets that are handled by this rule: true
4. Login to the OpenVPN
5. Watch the live log
6. while sleep 1; do ping -c4 -W1 192.168.1.1; done
7.  See matching rule is labeled with "Allow ICMP custom alias"

Expected behavior

The expected label/rule is: "Allow IMCP"
The previous rule with the builtin dynamic alias should have matched.

Describe alternatives you considered

I considered the alias only to be filled, if a corresponding interface has been assigned.
This assumption also turned out to be wrong.
To verify this I logged in via backup-path,
assigned an OPNsense interface "OpenVPN_RA" to the device ovpns1
(without IP configuration, because it's forbidden on a tunnel interface).
Then I restarted the OpenVPN server to assign the defined tunnel-ip to the interface.
Now I'm able to select the Interface in Livelog,
but the alias "OpenVPN net" as well as the alias "OpenVPN_RA net" still don't match.

Screenshots

Ruleset:

Livelog:

Relevant log files

I attached a grep of rules.debug (of the OS with 21.7)

[tstein@office-gw1 /tmp]$ grep -i openvpn rules.debug
table <OpenVPN_Netzwerk>  persist  
OpenVPN_Netzwerk = "<OpenVPN_Netzwerk>"
# block in log quick on openvpn inet from {<bogons>} to {any} label "27cd8f64c4465679bd478bd7aec8646a" # Block bogon IPv4 networks from OpenVPN
# block in log quick on openvpn inet6 from {<bogonsv6>} to {any} label "e62999aed0dede04f378432b2c8b7fa7" # Block bogon IPv6 networks from OpenVPN
# block in log quick on openvpn inet from {10.0.0.0/8,127.0.0.0/8,100.64.0.0/10,172.16.0.0/12,192.168.0.0/16} to {any} label "d7a184385814e3ee66552f7d862ed84a" # Block private networks from OpenVPN
# block in log quick on openvpn inet6 from {fc00::/7} to {any} label "e830e03cba3eda2f1fcd764e40d33f4e" # Block private networks from OpenVPN
# block in log quick on ovpns1 inet from {<bogons>} to {any} label "f00de6dec0ab85718cf9d3b1f55e779b" # Block bogon IPv4 networks from OpenVPN_RA
# block in log quick on ovpns1 inet6 from {<bogonsv6>} to {any} label "5b9a139f0c4bf75c66b9813b65c42060" # Block bogon IPv6 networks from OpenVPN_RA
# block in log quick on ovpns1 inet from {10.0.0.0/8,127.0.0.0/8,100.64.0.0/10,172.16.0.0/12,192.168.0.0/16} to {any} label "c0d421255b497947d886f48078cbe505" # Block private networks from OpenVPN_RA
# block in log quick on ovpns1 inet6 from {fc00::/7} to {any} label "c3615c91fec4e91c5596a2d395813abc" # Block private networks from OpenVPN_RA
pass in log quick on openvpn inet proto icmp from {(openvpn:network)} to {(self)} keep state label "59afbad818092cbc7fad74bde3b16e33" # : Allow ICMP
pass in log quick on openvpn inet6 proto ipv6-icmp from {(openvpn:network)} to {(self)} keep state label "59afbad818092cbc7fad74bde3b16e33" # : Allow ICMP
pass in log quick on openvpn inet proto icmp from {(ovpns1:network)} to {(self)} keep state label "79deaeede7686e15104e69f13e2ff437" # : Allow ICMP RA
pass in log quick on openvpn inet6 proto ipv6-icmp from {(ovpns1:network)} to {(self)} keep state label "79deaeede7686e15104e69f13e2ff437" # : Allow ICMP RA
pass in log quick on openvpn inet proto icmp from $OpenVPN_Netzwerk to {(self)} keep state label "9b529f0b232623b7d52374a34169c60e" # : Allow ICMP custom alias
pass in log quick on openvpn inet6 proto ipv6-icmp from $OpenVPN_Netzwerk to {(self)} keep state label "9b529f0b232623b7d52374a34169c60e" # : Allow ICMP custom alias
pass in quick on openvpn from {any} to {any} label "fd79154f94fefd7c688691d08c1786ab" # : OpenVPN Office Remote Access VPN Assistent
pass in quick on ix1 inet proto {tcp udp} from {any} to {(self)} port {1194} keep state label "49f9b11b7927d422c7e0e844e7de0938" # : Allow incomming OpenVPN traffic
pass in quick on ix1 inet6 proto {tcp udp} from {any} to {(self)} port {1194} keep state label "49f9b11b7927d422c7e0e844e7de0938" # : Allow incomming OpenVPN traffic
# pass in quick on ##any## proto udp from {any} to {{"network":"anyip","port":"1194"}} port {1194} label "0f9806fdebb796369e646267896c1372" # : OpenVPN Office Remote Access VPN Assistent
# pass in quick on ovpns1 reply-to ( ovpns1 192.168.249.2 ) inet from {any} to {any} keep state label "f74d456b13ce3a28f2cbfb9a3ad8bb75" # : OpenVPN Office Remote Access VPN Assistent

Additional context

It would be nice to have a little hint "(group)"
attached to the OpenVPN group rules to make this clear to the user
as the Wireguard (group) ruleset has recently been received.
But this is a topic for a separete feature request.

Where can I take a look to the builtin, predefined and dynamically created
aliases like ports and networks? Firewall: Diagnostics: Aliases
only provides a very limited subset.

Environment

OPNsense 22.1.1_3-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1m 14 Dec 2021

as well as:

OPNsense 21.7.8-amd64
FreeBSD 12.1-RELEASE-p22-HBSD
OpenSSL 1.1.1m  14 Dec 2021

Thanks a lot for OPNsense! :-D

[fichtner]

Hi @tobiasstein,

It looks like "(ovpns1:network)" doesn't do the right thing on the kernel side. I'm not sure if it can derive a network from a tunnel setup.

Can you share the ifconfig ovpns1 output?

Cheers,
Franco

[AdSchellevis]

to show the current contents of ovpns1:network, the following command could help:

/sbin/pfctl -t my_test_alias -T replace ovpns1:network && /sbin/pfctl -t my_test_alias -T show

[tobiasstein]

Hi @fichtner, Hi @AdSchellevis,

thanks for your response and as requested:

$ ifconfig ovpns1
ovpns1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet6 fe80::3eec:efff:fee9:8b00%ovpns1 prefixlen 64 scopeid 0x11
        inet 192.168.249.1 --> 192.168.249.2 netmask 0xffffffff
        groups: tun openvpn
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        Opened by PID 60388

I haven't assigned a IPv6 ULA, yet - so it's bare IPv4.

I swear I've configured 192.168.249.0/24 in the WebGUI. :-)

ovpns1:network is not empty, but also not what I would have expected.

$ /sbin/pfctl -t my_test_alias -T replace ovpns1:network && /sbin/pfctl -t my_test_alias -T show
1 table created.
1 addresses added.
   192.168.249.1

SNM is missing maybe because the interface is /32?

Just for the sake of completeness the content of "OpenVPN_Netzwerk"

$ pfctl -t OpenVPN_Netzwerk -T show
   192.168.249.0/24

[fichtner]

Ok, as expected there is no way for pf(4) to expand the tunnel network since the kernel never had this information. I'm not even sure if this can be fixed.

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.