Topics

[except]

This is probably an OS issue rather than an OPNsense issue but here goes...

I have 8 OPNsense firewalls (4 pairs, 2 in each location). The firewalls are Deciso hardware. They are connected together via a layer 3 cloud (think MPLS/VPLS type service). Presentation to the firewalls is GBE copper as a tagged VLAN. This service uses a /24 for IP addressing, each firewall has its own IP and each pair shares a CARP IP. Layout is :

10.x.x.1  Site 1 VIP
10.x.x.2  Site 1 FW 1
10.x.x.3  Site 1 FW 2
10.x.x.4  Site 2 VIP
10.x.x.5  Site 2 FW 1
10.x.x.6  Site 2 FW 2
10.x.x.10 Site 3 VIP
10.x.x.11 Site 3 FW 1
10.x.x.12 Site 3 FW 1
10.x.x.13 Site 4 VIP
10.x.x.14 Site 4 FW 1
10.x.x.15 Site 5 FW 2

Each firewall has a firewall rule on the interface for this zone that permits all ICMP. Each firewall can ping (either from the CLI or dpinger via gateway monitoring) each other individual firewall. Each firewall can ping each other individual VIP except the one ending in .1, where pinging this address results in 128 duplicate packets being sent. The number 128 seems significant to me.

I did a packet capture on Site 3 FW 1 and what I see is the below:

Code Select Expand

14:14:35.094594 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097248 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097250 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097520 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097566 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097813 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097815 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097816 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097817 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097817 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097846 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.097847 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098106 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098107 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098108 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098109 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098110 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098111 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098112 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098112 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098135 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098387 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098389 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098389 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098390 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098391 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098392 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098393 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098394 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098394 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098708 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098710 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098711 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098712 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098713 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098713 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098714 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098715 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098743 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098744 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.098791 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099046 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099047 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099048 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099049 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099050 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099051 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099051 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099052 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099053 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099083 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099084 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099341 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099342 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099343 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099344 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099345 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099346 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099347 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099348 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099348 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099349 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099376 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099618 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099619 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099620 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099621 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099622 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099623 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099624 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099624 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099625 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099626 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099627 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099686 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099913 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099914 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099915 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099916 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099917 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099918 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099918 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099919 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099920 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.099957 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100211 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100212 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100213 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100214 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100215 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100216 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100217 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100218 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100218 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100219 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100220 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100221 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100222 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100253 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100532 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100533 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100534 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100535 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100536 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100537 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100537 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100538 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100539 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100568 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100826 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100827 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100828 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100829 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100830 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100830 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100831 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100832 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100833 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100834 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100869 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.100870 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.101140 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.101142 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.101143 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.101144 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.101145 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9
14:14:35.101145 IP 10.x.x.11 > 10.x.x.1: ICMP echo request, id 42659, seq 26, length 9


Important observations, same sequence number on all 128 pings, and these are being sent from the firewall initiating the ping. These are duplicate requests being generated by the device I run tcpdump on, they are not duplicate responses. This capture was performed on the device ending .11. Both CLI/OS ping command and dpinger exhibit the same response (I expect dpinger is just executing ping behind the scenes). All other firewalls connected to this service exhibit the same behaviour when pinging .1, and only .1.

WTF?!

We run an environment with several business edition Deciso hardware OPNsense firewalls. There are strong compliance and vulnerability requirements in the environment, as it is CNI adjacent. SLA requires vulnerabilities to be mitigated or patched within days not weeks, which goes against the patching ethos of business edition.

At the time of writing, there is CVE-2025-26466 affecting OpenSSH < 9.9p2 and CVE-2025-27516 affecting Jinja2. Is there a (supported?) way the updated versions of these packages can be pulled and installed to satisfy my SLA requirements around timely remediation of vulnerabilities? SSH just comes from ports (I think?) so I think that could be trivial, not so sure about Jinja2. The exposure is obviously reduced as these services are not exposed anywhere other than an internal management network, but that doesn't stop the vulnerability scanner sending big red warnings to the security team...

I've made a load of improvements to a plugin but have hit a blocker. The plugin in question has to write the IP address for a service to listen on, into a config file. I can use the templates structure for the plugins, e.g.

Code Select Expand

{%     if helpers.exists('interfaces.'+int+'.ipaddr') %}
{%       set interface_ip = helpers.getNodeByTag('interfaces.'+int+'.ipaddr') %}
{%       if '.' in interface_ip %}
--- do stuff here ---
{%       endif %}
{%     endif %}


However that gets the IP address out of the config file. If an interface is set to DHCP, or SLAAC (for the ipaddrv6 property) there is no IP address in that field. How do we cope with that in a plugin, is there an event handler for an IP address change that can update config files for running services?

The net-snmpd plugin has an option to expose the version of OPNsense under a specific OID. This is a tickbox in the GUI provided by this plugin:



This adds the following line to the snmpd config file:

Code Select Expand

extend    version   /usr/local/sbin/opnsense-version


This has the effect of putting whatever the output is of that command, into that OID. LibreNMS, a 3rd party network monitoring system, is aware of OPNsense. Libre, and I would assume other NMS-type products, look in this OID to figure out the OS and version, using this regex:

Code Select Expand

(?<version>[\d._]+) \((?<hardware>[^)]+)\)

However at some point the output of the opnsense-version command has changed, and it no longer outputs the arch by default. This means the string in the OID no longer matches the regex the NMS is using to identify the OS version.

Old output:

Code Select Expand


root@x-y-z:~ # ./opnsense-version
OPNsense 24.10_7 (amd64/OpenSSL)


New output:

Code Select Expand


root@x-y-z:~ # /usr/local/sbin/opnsense-version
OPNsense 24.10_7


Current opnsense-version with parameters to replicate old behaviour:

Code Select Expand


root@x-y-z:~ # /usr/local/sbin/opnsense-version -NvA
OPNsense 24.10_7 amd64


Believe it or not, this was caused by a commit from 2019! Commit id c1f839e in relation to issue #4500 changed the default output of the command, by introducing the DEFAULTS variable and setting this to include product_name and product_version.

There are a number of ways this could be addressed:

• Modify the default output of the opnsense-version command so it behaves as it did in the past
• Modify the template for the snmpd.conf file so that it adds -NvA as a parameter to opnsense-version, restoring the original functionality
• Add more tickboxes to the net-snmp plugin to further customise what information is presented in that OID
• Submit a PR to LibreNMS to change their regular expression

What do we collectively think is the correct way to approach this? Fundamentally, a change was introduced in OPNsense which inadvertently changed the way a plugin worked. Is the correct fix to modify the plugin, modify OPNsense to restore the original intended behaviour, or accept it is how it is and fix the 3rd party tool? I'll do the PR, would just like some guidance as to the correct way to fix it.

Hi,

I am porting the scan agent for phpIPAM into OPNSense so you can perform subnet scans directly from the firewall/gateway/DHCP server/whatever role OPNSense has in your network. The agent itself is a threaded (using prctl) CLI PHP application from https://github.com/phpipam/phpipam-agent

I have written a plugin to perform GUI configuration of the agent and add scanning tasks as cron jobs in the web gui which all works fine and as expected. However there are some packaging questions I have:

• The phpipam-agent needs to reside somewhere. It is essentially a php script so there is no FreeBSD port of it for example. In my dev setup I have put it in /usr/local/share/phpipam-agent - where would be the appropriate place for this to live on the filesystem in production, and how would I package it into my plugin for it to live somewhere outside of the /usr/local/opnsense tree? I suspect I am going about this part incorrectly. Will I need to package the agent and the OPNsense plugin separately and somehow make both available?


• The phpipam-agent requires quite a few PHP packages that are not in the OPNsense ports collection but are in the FreeBSD ports collection, namely php82-gmp php82-pdo_mysql php82-iconv php82-posix. I have seen that one can request these ports be made available for OPNsense by opening a git issue - is that still the right approach?

Then, some possible bugs! I think there may be a couple of mistakes in the documentation regarding building. Several times in the build documentation the package vim-console is referenced, but this does not appear to be installable anymore. 

I believe there is a line of code in the example for the settingscontroller jquery which is incorrect. By this I mean the code shown in the documentation at https://docs.opnsense.org/development/examples/helloworld.html - the file in the github repo is correct. There is a line:

Code Select Expand

$result["validations"]["general.".$msg->getField()] = $msg->getMessage();
Which I think should be:

Code Select Expand

$result["validations"]["helloworld.".$msg->getField()] = $msg->getMessage();

The original code results in an object being returned called general.general.fieldname when I think it should be helloworld.general.fieldname?

Additionally it does not appear possible to have an entry in the menu.xml file for a plugin where the tag name starts with php

This did not work in my testing:

Code Select Expand

<menu>
    <Services>
        <PhpIpamAgent visibleName="phpIPAM Agent" cssClass="fa fa-list-ol fa-fw">
            <Settings url="/ui/phpipamagent" />
        </PhpIpamAgent>
    </Services>
</menu>


This does work:

Code Select Expand

<menu>
    <Services>
        <ipamAgent visibleName="phpIPAM Agent" cssClass="fa fa-list-ol fa-fw">
            <Settings url="/ui/phpipamagent" />
        </ipamAgent>
    </Services>
</menu>


Thanks!

Hi!

I have 6 OPNsense firewalls which all share IPv4 routes via OSPF. I am part way through upgrading them all from 23.1.11_1 to 23.7.2. No configuration changes have taken place other than upgrading, however I am aware this upgrade moves to FRR 8. What I am seeing is that OSPF on the upgraded firewalls does not redistribute kernel, or static routes despite having the options set in the configuration.

e.g. from inside vtysh

Code Select Expand

fw-1# sh run
Building configuration...

Current configuration:
!
frr version 8.5.2
frr defaults traditional
hostname fw-1
log syslog notifications
!
interface openvpn
ip ospf passive
exit
!
interface vmx0
ip ospf passive
exit
!
interface vmx2
ip ospf cost 200
exit
!
interface vmx3
ip ospf passive
exit
!
interface vmx4
ip ospf passive
exit
!
interface vmx5
ip ospf passive
exit
!
router ospf
ospf router-id 7.0.1.1
redistribute kernel
redistribute connected
redistribute static
network 1.2.3.4/16 area 1.1.1.1
network 10.1.1.0/30 area 1.1.1.1
network 10.2.2.0/30 area 1.1.1.1
exit
!
end


My kernel routing table:

Code Select Expand

root@fw-1:/var/log # netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            x.x.x.x        UG1        vmx1
10.0.0.0/16        127.0.0.1          USB         lo0
10.1.0.0/24        127.0.0.1          USB         lo0
-- snip --
10.2.2.0/24      127.0.0.1          USB         lo0
10.2.3.0/24      127.0.0.1          USB         lo0


My routing table in FRR - note there are only OSPF and Connected routes in the table. Also note I have had to substitute the IP addresses but they are not relevant to the problem:

Code Select Expand

fw-1# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, T - Table,
       v - VNC, V - VNC-Direct, A - Babel, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

O>* 0.0.0.0/0 [110/1] via 1.1.1.1, vmx1, weight 1, 00:23:35
O>* 1.1.1.1/28 [110/20] via 1.1.1.1, vmx1, weight 1, 00:23:35
O   1.1.1.1/24 [110/10] is directly connected, vmx0, weight 1, 00:23:51
C>* 1.1.1.1/24 [0/1] is directly connected, vmx0, 00:23:51
O   1.1.1.1/24 [110/10] is directly connected, vmx3, weight 1, 00:23:51
C>* 1.1.1.1/24 [0/1] is directly connected, vmx3, 00:23:51
O   1.1.1.1/24 [110/10] is directly connected, vmx4, weight 1, 00:23:51
C>* 1.1.1.1/24 [0/1] is directly connected, vmx4, 00:23:51
O>* 1.1.1.1/28 [110/120] via 1.1.1.1, vmx1, weight 1, 00:23:36
O   1.1.1.1/26 [110/10] is directly connected, ovpns1, weight 1, 00:23:51
C>* 1.1.1.1/26 [0/1] is directly connected, ovpns1, 00:23:51
O   1.1.1.1/30 [110/10] is directly connected, vmx5, weight 1, 00:23:51
C>* 1.1.1.1/30 [0/1] is directly connected, vmx5, 00:23:51
O>* 1.1.1.1/30 [110/20] via 1.1.1.1, vmx1, weight 1, 00:23:35
O   1.1.1.1/30 [110/10] is directly connected, vmx1, weight 1, 00:23:51
C>* 1.1.1.1/30 [0/1] is directly connected, vmx1, 00:23:51
O>* 1.1.1.1/30 [110/210] via 1.1.1.1, vmx1, weight 1, 00:23:36
O   1.1.1.1/30 [110/200] is directly connected, vmx2, weight 1, 00:23:51
C>* 1.1.1.1/30 [0/1] is directly connected, vmx2, 00:23:51
O>* 1.1.1.1/30 [110/400] via1.1.1.1, vmx2, weight 1, 00:23:36
O>* 1.1.1.1/30 [110/20] via 1.1.1.1, vmx1, weight 1, 00:23:36
O>* 1.1.1.1/30 [110/210] via 1.1.1.1, vmx1, weight 1, 00:23:36
O>* 1.1.1.1/30 [110/210] via 1.1.1.1, vmx2, weight 1, 00:23:36
O>* 1.1.1.1/30 [110/400] via 1.1.1.1, vmx2, weight 1, 00:23:36
O>* 1.1.1.1/32 [110/20] via 1.1.1.1, vmx1, weight 1, 00:23:35


Yet here is the routing table from within FRR/vtysh on a firewall which has NOT been upgraded, running the same configuration. As it has not been upgraded it runs FRR 7.5.1

Code Select Expand

fw-2# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, T - Table,
       v - VNC, V - VNC-Direct, A - Babel, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

O>* 0.0.0.0/0 [110/1] via 1.1.1.1, vmx1, weight 1, 00:23:35
O>* 1.1.1.1/28 [110/20] via 1.1.1.1, vmx1, weight 1, 00:23:35
O   1.1.1.1/24 [110/10] is directly connected, vmx0, weight 1, 00:23:51
C>* 1.1.1.1/24 [0/1] is directly connected, vmx0, 00:23:51
O   1.1.1.1/24 [110/10] is directly connected, vmx3, weight 1, 00:23:51
C>* 1.1.1.1/24 [0/1] is directly connected, vmx3, 00:23:51
O   1.1.1.1/24 [110/10] is directly connected, vmx4, weight 1, 00:23:51
C>* 1.1.1.1/24 [0/1] is directly connected, vmx4, 00:23:51
O>* 1.1.1.1/28 [110/120] via 1.1.1.1, vmx1, weight 1, 00:23:36
O   1.1.1.1/26 [110/10] is directly connected, ovpns1, weight 1, 00:23:51
C>* 1.1.1.1/26 [0/1] is directly connected, ovpns1, 00:23:51
O   1.1.1.1/30 [110/10] is directly connected, vmx5, weight 1, 00:23:51
C>* 1.1.1.1/30 [0/1] is directly connected, vmx5, 00:23:51
O>* 1.1.1.1/30 [110/20] via 1.1.1.1, vmx1, weight 1, 00:23:35
O   1.1.1.1/30 [110/10] is directly connected, vmx1, weight 1, 00:23:51
C>* 1.1.1.1/30 [0/1] is directly connected, vmx1, 00:23:51
O>* 1.1.1.1/30 [110/210] via 1.1.1.1, vmx1, weight 1, 00:23:36
O   1.1.1.1/30 [110/200] is directly connected, vmx2, weight 1, 00:23:51
C>* 1.1.1.1/30 [0/1] is directly connected, vmx2, 00:23:51
O>* 1.1.1.1/30 [110/400] via1.1.1.1, vmx2, weight 1, 00:23:36
O>* 1.1.1.1/30 [110/20] via 1.1.1.1, vmx1, weight 1, 00:23:36
O>* 1.1.1.1/30 [110/210] via 1.1.1.1, vmx1, weight 1, 00:23:36
O>* 1.1.1.1/30 [110/210] via 1.1.1.1, vmx2, weight 1, 00:23:36
O>* 1.1.1.1/30 [110/400] via 1.1.1.1, vmx2, weight 1, 00:23:36
O>* 1.1.1.1/32 [110/20] via 1.1.1.1, vmx1, weight 1, 00:23:35
K>* 10.0.0.0/16 [0/0] unreachable (blackhole), 01:32:28
K>* 10.1.0.0/24 [0/0] unreachable (blackhole), 01:32:28
K>* 10.2.2.0/24 [0/0] unreachable (blackhole), 01:32:28
K>* 10.2.3.0/24 [0/0] unreachable (blackhole), 01:32:28


Same config file, different version of FRR, different result. Does FRR 8 no longer redistribute blackhole/unreachable routes? I use this to inject routes to policy-based VPN tunnels into the OSPF process.

Hi all,

I have a problem with something I am trying to do with OSPFv2 under FRR/OPNsense and would appreciate some assistance from those who know more than I do...

Unfortunately I cannot share my configs due to the nature of the business they are installed in, but I am doing some psuedo configs and diagrams that will hopefully explain what I am trying to do.

Attached is a diagram of one of our sites running multiple OPNsense firewalls.

Some notes:
FW A has its default gateway statically defined. FW B and C learn this default route via OSPF
FWs B & C have multiple private subnets/interfaces (in the diagram these are the clouds at the bottom). They are facing 'dumb' equipment so the interfaces are configured as passive in FRR. In real life there are many more than shown on the diagram. FW B learns the routes through FW A to the networks attached to FW C, and vice versa.
FRR on FW C redistributes static routes as there are some IPSEC tunnels from here where the 3rd party on the other end does not run a routing protocol. FRR redistributes these so that FWs A and B can route to them.
The firewalls have the /30 networks defined as 'Networks' in the OSPFv2 page in OPNsense. Nothing is defined in interfaces.

Everything written above up to now works OK and as intended.

I now have to connect another 3rd party via IPSEC into FW C. This will be a routed/VTI connection. In my testing, if I make this VTI interface part of area 1.1.1.1 (and the 3rd party configures their end to also be area 1.1.1.1) they will receive every little route even though I enter area summarisation as 192.168.0.0/16. There are hundreds of routes this way and the routing table becomes unworkable. If I make this VTI interface a new area, they only get the routes that OSPF in area 1.1.1.1 considers to be external/E2, which are the default route via FW A, and the static routes defined on FW C. None of the 192.168.1.x routes are shared with the new area connecting into FW C.

I do not seem to be able to configure FRR in such a way that it sends a summary route to 192.168.0.0/16 over the new IPSEC connection in to FW C. My gut feeling from my loose understanding of OSPF is that the new connection should be treated as a new area as it is fundamentally separate and the routing information shared that way should be summarised.  But I cannot get FRR to summarise the information it exchanges with that new, separate area.

As the same OSPF process will be sharing summarised route(s) with this new area over the IPSEC/VTI interface, as well as processing internal routes for the pre-existing area, will a route-map or some other prefix-list be needed?

Cheers!

Is there are 'correct' way to set environment variables in OPNSense which persist across upgrades? At the moment I am adding them to the [environment] section of /usr/local/opnsense/service/conf/configd.conf but this gets wiped out with every upgrade.

If not, once this .conf file is edited is there a way to process/apply settings added without a reboot?

Hi,

I found this thread from 2018 which is still valid in the current version https://forum.opnsense.org/index.php?topic=9759.0

I experience exactly these symptoms. I understand that static routes would take precedence over learned dynamic routes from FRR. I have 1 defined gateway, with 1 static route present for a small CIDR. Everything else is OSPF. What I don't understand is that my defined gateway does not have "Upstream Gateway" checked. From the documentation, this means that OPNSense should not consider it a candidate for a default gateway. Yet every time I reboot this gateway is back to being a default gateway, when it should not be. The gateway in question is actually over an IPSEC link, so selecting it as the default gateway is a catch-22. Surely if there is no suitable "Upstream Gateway" then OPNSense should not just arbitrarily pick a gateway which does not have this option checked, it should just continue with no default gateway?

Welcome your thoughts

Hi all,

I am troubleshooting some issues I have always had with PPPoE via OPNsense and I have some questions about the logic in the code. Wonder if anyone else experiences this also and agrees with what I'm seeing.

1. The code that generates the mpd_{iface}.conf file always forces IPv6 / ipv6cp regardless of settings in OPNsense. My ISP's RADIUS server or DSLAM or whatever is doing the DSL authentication for my PPPoE connection rejects ipv6cp. So I have to manually edit the code to take this out. I have a patch for this against the current version which only includes the ipv6cp config line if the interface IPv6 address is set to something

2. The negotiation with my ISP for my static IP address via PPPoE is weird. It looks like the device at the ISP end allows me to request an IP address, so mpd requests an IP, the authentication server then rejects it and supplies my correct static IP and gateway. There doesn't seem to be a method in OPNsense for me to provide my static IP and gateway IPs and skip this request/reject step - it looks like the code only stores local IP and gw IP if you are using L2TP or PPTP but not PPPoE. It seems to me like I have a use case for this here (even if it is only to stop my log files filling with errors).

3. For some reason the code that generates the config file does this:

  set link disable chap pap
  set link accept chap pap eap

and I cannot see the logic of that in the slightest. Surely you don't need the first line?

4. The resulting file contains a password in plaintext but is world readable. That probably isn't right.

The overall issue I have is that I seem to have to reconnect about 15 times before I get a connection that works. I think this is an issue between the ISP auth server or some routing setup they have for their static IPs and my reconnectiong, like they are not removing a static route when I disconnect and it remains in place at their end until a timeout is reached. But eliminating these PPPoE errors might make the issues clearer for me.

What do the community think?