Messages

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

I configured another OpenVPN instance and had the same issue again. It solved itself after a while though.

It looks like the CRL for the CA for that new OpenVPN instance didn't get synced to the backup, at least OpenVPN on the backup complained about /var/etc/openvpn/server-SOMETHING that wasnt there on the backup but on the master despite having hit "Synchronize and reconfigure all" multiple times. Ten minutes later after a coffee the file was suddenly there.

Is it possible that hitting the "Synchronize and reconfigure all" button accidentally on the backup box helped?