Messages

Hi,
I would like to query for some background information about the __optX_network and __optX_address objects/aliases/thingies. They are either inconsistently handled in the Web UI or I am missing something in my limited Knowledge.

Here is what I know:

• It looks like they are implicitly created with putting an IP address on an Interface in Interfaces > Interface.
• __optX_network seems to contain the proper network/prefix object that can be used to cover the IP address range on the Interface
• __optX_address looks like designed to contain the IP address of the OPNsense machine.
• The object name is one of the few places where the internal identifier of the Interface seems exposed to the user, which is a major source of confusion since the number in optX usually neither matches the physical interface name nor the VLAN id. It's just another incremented number that one cannot seem to be able to influence but has to grok in rules.
• It seems to be possible to use both variants directly in the Source/Destination field of a Firewall Rule (old interface) by scrolling down aaaaaaaaaalll the way to "Networks" and searching for the "Description" of the Interface, not the identifier.
• __optX_network shows up in Firewall > Aliases as "Internal(Automatic)" with the Interface Description as "Description". The Content doesn't show, but I can also see them in Firewall > Diagnostics > Aliases and I can build network groups from them. In the "Edit Alias" dialog, I can add them to a network list, but I need to do so by searching for the __optX_network string and not for the description.
• __optX_address does not show up in Aliases at all, neither in the Alias list, nor in Firewall > Diagnostics > Aliases, nor can I add those objects to a host or entwork list.
• I also cannot see which addresses __optX_address expands to. What happens to that object when I have multiple IP addresses and/or virtual IP addresses no the Interface? Can I rely on that object always being correct?

I would appreciate if someone could elaborate on this or maybe even lead me towards existing documentation, or maybe even issues (in the case that I am correct and that OPNsense indeed handles this suboptimally).

In the current state of me not understanding and not finding documentation, those automatic network objects add confusion while being of quite limited usefulness for me.

Greetings
Marc

Hi,

I have OPNsense 25.7.8. To keep legacy telephones running, I have a number of GRE tunnels that terminate on devices that are behind OpenVPN on the remote side, and on a system in my internal network. The traffic from the internal network to the OpenVPN link is blocked by the built-in "Default deny / state violation rule":

You cannot view this attachment.

I have both a bidirectional floating rule without state tracking:

You cannot view this attachment.
You cannot view this attachment.

and corresponding directional rules in both the OpenVPN and the internal rule list.

The traffic is still blocked.

How can I get that GRE traffic to pass?

Greetings
Marc

Usually, you can avoid the problem by using <a href="https://..." rel="noreferrer">" in your link.

That is the short term solution that I liked the most. Those links look different in the Wiki, but i can live with that.

Thank you!

Greetings
Marc

I tend to agree. This seems to be one of those features from the pre-fork era which hasn't been touched ever since.
Since this only is an issue if you link to OPNsense from a different website, this probably never bothered too many users.

Feel welcome to open an issue (or pull request) on GitHub.

Will Do. I think it is a rather common thing to have a Link page on a company wiki for daily work.

Greetings
Marc

Some of the older Forum Threads suggest that I should enter the name of the wiki as another alternate hostname in OPNsense. That CAN'T be correct advice, can it?

Would it make sense to have separate fields for DNS rebinding hostnames and HTTP_REFERER hostnames? Maybe.

Absolutely. Entering a hostname that positively belongs to a different host as an "alternate" hostname makes my toes curl, and not in pleasure.

Alternatively, write something like "also enter hostnames that are allowed to link to your OPNsense Web interface here" in the info text.

Greetings
Marc

You need to add the rule to the interface, which the traffic is going out.

If you want to access the LAN IP of the secondary, the packets will go out on the LAN interface. If you access the SYNC interface, the packets go out on SYNC.
Its wise to use ever the same IP to access the firewall. So you need the rule only on a single interface.

And of course you should limit the rule to the admin source and to the secondary as destination.
Best to use an alias, which includes both, the IP of the primary and secondary, so you can sync the rules to the secondary and it will also work in case it has the master role.

Thanks for your advice, that's what I'll do.

I did that with an outbout rule on the Management Interface, so that I don't have a NAT rule on the production network. Seems to work fine, no side effects noticed yet.

Hi,
this has been discussed a number of times, but a few years ago, and OPNsense has continued to be developed. And, frankly, I didn't understand the explanations.

I think that I am not the only person who has a web page on an internal Wiki that contains the link to the administration pages of the managed devices. I therefore have links to my OPNsense Web UI machines there. The hostname that is part of those links is entered in System > Settings > Administration (multiple host names, for both nodes, as a space separated list, all spelled correctly).

One of the hostnames I have listed there, for example is opnsense2.mgt.ka51.zugschlus.de. That host name is correctly in the local DNS and maps to a primary IP address of the OPNsense installation.

The Link in my Wiki page points to https://opnsense2.mgt.ka51.zugschlus.de/

And still, when I click on the link, I _sometimes_ get the message that OPNsense doesn't like my referer.  Sometimes, but not every time. I guess that depends on whether I am already logged in to the device in another tab of that browser.  The exact error message is "The HTTP_REFERER "http://mywiki.example.com/" does not match the predefined settings. You can disable this check if needed under System: Settings: Administration"

When does this happen? Why does this happen? I think I have everything configured correctly. Can this possibly have to do with the fact that the wiki is (still, don't ask) an unencrypted http server?

What is the referer check supposed to protect me from? Currently it is protecting me from easily accessing my devices. Is there any trick I can use to have working links AND referer protection? Is there a (hidden?) setting that allows me to set allowed referers?

Some of the older Forum Threads suggest that I should enter the name of the wiki as another alternate hostname in OPNsense. That CAN'T be correct advice, can it?

Greetings
Marc

Hi,

what are the recommendations for filter rules on the pfsync interface? Some person has dropped an allow all rule there on "my" cluster and I don't feel very comfortable with that.

Greetings
Marc

You need to add the rule to the interface, which the traffic is going out.

If you want to access the LAN IP of the secondary, the packets will go out on the LAN interface. If you access the SYNC interface, the packets go out on SYNC.
Its wise to use ever the same IP to access the firewall. So you need the rule only on a single interface.

And of course you should limit the rule to the admin source and to the secondary as destination.
Best to use an alias, which includes both, the IP of the primary and secondary, so you can sync the rules to the secondary and it will also work in case it has the master role.

Thanks for your advice, that's what I'll do.

How bad do you find the idea of NATting the Home Office addresses of the admins to the active nodes' internal address when accessing the passive node?

This is the recommended way to workaround this issue.

I'd rather not do that on the productive internal network link, did anybody ever try doing that on the PFSYNC link? Can anyone please share their experience with this issue? I guess it's a rather common setup, and the solution is likely to have well hidden pitfalls, and I'd like to use a wheel that was already invented.

Greetings
Marc

Hi,
given an OPNsense HA installation in a datacenter that only protects servers. The administrators use OpenVPN to connect to the site that terminates on the OPNsense cluster as well¹. This works for the active node, but the passive node cannot be access since the passive node has OpenVPN running as well with the routes to the OpenVPN clients pointing into the (inactive) tunnel. Thus, there is no reverse route and communication cannot happen.

Is there a gold standard to solve this? How bad do you find the idea of NATting the Home Office addresses of the admins to the active nodes' internal address when accessing the passive node? Or is it just recommended to always use the management network?

Greetings
Marc

¹ there is out of band access and a dedicated management network that can be accessed through a different channel, but that's clumsy to access.

Thank you. Will look for available plugins in the future.

Hi,

just to make sure before I suggest building just another dedicated DNS server: OPNsense can only do forwarding and cannot run as slave DNS server having the zone actually loaded? At a site I need a DNS server that can still resolve the internal names when the connection to the DNS servers holding the actual zone is not available.

Greetings, Marc Haber

1. System > HA > Settings --> the config sync IP address must be empty on the backup node
2. System > HA > Settings --> enable syncing of certificates

I actually didnt have the sync IP address empty on the backup node. I didn't build that. Removed the IP address.

And I kind of expected that for everything listed in "Services" in ui/core/hasync there would be a corresponding Entry i /ui/core/hasync_status. That is not the case.

I have learned something from you. Thank you. Have a nice weekend.

Greetings
Marc

Most certainly not - I hope you did not configure a synchronise config IP address on the backup node?

I dont quite understand that. What do you mean?

So the only thing I can picture is wrong timing - sync and restart OpenVPN first, then certificates, so OpenVPN cannot start on the backup. Syncing twice should fix that. But ten minutes ... no idea.

I did it more than twice. And there is nothing explicitly syncing certificates and CAs in the config:

You cannot view this attachment.

Greetings
Marc