Messages

Hi there,

I tested the free plugin and it works according to plan, thanks!

A few items though:
- I guess that with the Community - Self-Provisioned licensing scheme, the provided threat feeds include OSINT only. Are you intending to list what is included within your OSINT package? I.E: all the Q-Feeds triggering threats here were part of my next in line ingress policy object which is the IPSUM_L1 threat intelligence feed.

- I may think that the plugin does not release/give control back to OPNsense once the inactive administrative session timeout has been reached. One may still click on the three Q-Feeds menus. Although, while nothing refreshes within the Q-Feeds menus, once you click anywhere else within the GUI, you're routed to the usual OPNsense login page, which is the normal behavior under these circumstances.

- Why the "Security" new menuitem? why not simply within the "Services > Q-Feeds Connect" menu directly? Perhaps there are other unknown to me plugins that uses the "Security" menuitem although if you're the only one, I don't see the point TBH.

Let me know,
Thanks

Hi all,

I'd cut a long story short, I need (for lack of better solution) to restart an LTE router everyday. Without this, latencies just gets higher and higher and higher up until it's not operating no more. I couldn't yet nail the main issue down.

That LTE WAN uplink is seated within a dedicated VLAN on a DMZ switch (along a 2nd wan uplink on it's own dedicated VLAN etc etc..)

My issue at OPNsense was that once the device would be auto-rebooted once a day, that VLAN interface ip & gateway wouldn't be updated at the OPNsense level (the LTE router permit's a so called "passthrough" feature where a backend device would get the LTE bond IP address, in my case OPNsense, handy..).

So here is what I've cobbled, please read carefully what the main script does before blindly copy/paste/run.

The main script: (saved in /usr/local/bin/dhcp-renew)

Code Select Expand

#!/bin/sh

set -e

ENABLE_LOGGING=true
INTERFACE=$1

# Logging function
log_message() {
  if [ "$ENABLE_LOGGING" = "true" ]; then
    echo "$(date +%Y-%m-%d.%H:%M:%S) - $1" >> /var/log/dhcp-renew.log
  fi
}

# Function DHCP Renew
dhcp_renew() {
  /sbin/ifconfig $INTERFACE down
  /sbin/ifconfig $INTERFACE up
  /bin/rm -f /var/db/dhclient.leases.$INTERFACE
  /sbin/dhclient $INTERFACE
}

# Function Renew WAN
renew_wan() {
  /usr/local/etc/rc.newwanip $INTERFACE
  /usr/local/sbin/configctl interface reconfigure $(/sbin/ifconfig $INTERFACE | grep description | awk '{print $3}' | tr -d '()')
}

# Main script logic
main() {
  curtime=$(date +%s)
  uptime=$(sysctl kern.boottime | awk -F'sec = ' '{print $2}' | awk -F',' '{print $1}')
  uptime=$((curtime - uptime))

  log_message "========================"
  log_message "==== Process START ====="
  log_message "Interface given as parameter : '$INTERFACE'"
  log_message "System uptime: $uptime seconds"

  dhcp_renew
  log_message "DHCP Renew on interface '$INTERFACE' : DONE"

  renew_wan
  log_message "NEWWANIP & Interface Reconfigure on interface '$INTERFACE' : DONE"

  log_message "==== Process END ====="

}

# Run the main script logic
main

Making it executable:

Code Select Expand

chmod +x /usr/local/bin/dhcp-renew

The actions.d companion script: (saved in /usr/local/opnsense/service/conf/actions.d/actions_dhcp_renew.conf)

Code Select Expand

[start]
command:/usr/local/bin/dhcp-renew
parameters:%s
type:script
message:DHCP-RENEW on interface
description:DHCP-RENEW on specified interface

Restarting the configd service is needed:

Code Select Expand

service configd restart

And a quick log extract: (/var/log/dhcp-renew.log)

Code Select Expand

2025-12-08.12:33:00 - ========================
2025-12-08.12:33:00 - ==== Process START =====
2025-12-08.12:33:00 - Interface given as parameter : 'vlan0.8.888'
2025-12-08.12:33:00 - System uptime: 309327 seconds
2025-12-08.12:33:00 - DHCP Renew on interface 'vlan0.8.888' : DONE
2025-12-08.12:33:06 - NEWWANIP & Interface Reconfigure on interface 'vlan0.8.888' : DONE
2025-12-08.12:33:06 - ==== Process END =====

You can then edit your System>Settings>Cron jobs and schedule a specific interface forced renewal:
You cannot view this attachment.

Since I've put this in place, my specific interface gateway is now correctly set on OPNsense after each router restart and it's almost transparent if not for the router reboot cycle needed time. As said, the main issue has nothing to do with OPNsense itself. Finally, in my case, I'm also cycling any WireGuard instances that may use this path after the forced daily renewal.

Please do not hesitate to correct any mistake or provide any insight.
I.E:

• I did not took the needed time to completely understand what this does exactly : /usr/local/etc/rc.newwanip
• I'm not sure that the /usr/local/bin path may be advisable for user made scripts.

Hope this may help,
Cheers,
m.

For OpnSense, you define the WAN interface IP with a netmask of /32 and set the "IPv4 gateway rules" to your gateway, in which you check both "Upstream Gateway" and "Far Gateway" and select the WAN interface and gateway IP.

Thanks a lot, I'll try to set that up as well..
Kind regards,

hi all,

A quick question onto scheduling both of these commands:

Code Select Expand

System>Settings>Cron>+>ZFS pool scrub
System>Settings>Cron>+>ZFS pool trim
How often shall these run as a best practice?

Thanks,
Regards,

The difference is I've changed them both to DHCP, instead of static IP. I read it somewhere on this forum, that it allows the same gateway IP added via DHCP, but not manually.

Hi there, thanks for the tip -- was struggling to find out how to inject the same gateway over both WAN uplinks within OPNsense !! this solved it

If you see traffic that is not destined to your IPv4, it might be so-called "unknown unicasts". Their forwarding is a normal function of an L2 switch.

Yes that is the case here.

It will not help if you configure your interface as /32 and set up a pointopoint route to your gateway ip - although that could/should also be done regardless (I do that). Otherwise, you might not get traffic to your "subnet neighbors".

Could you give me more information as to how you enable the "pointtopoint route" to the /26 subnet gateway using /32 on your WAN uplink?

If you want to block such traffic before it even hits your OpnSense, you can use Hetzner's Robot Firewall to filter against your own IPv4 (I do that, too, and it works).

Yes that clear's up a massive amount of pure noise, best practices indeed.

Thanks!

Hi there,

Trying to understand your setup, the VPS1/2 as well as any WG "clients/road warriors" are tied to the same WG instance on your new OPNsense NGFW ?

I'm not acquainted with the overlay "tool" you may be using (tailscale or such I'd guess) although I would separate things, one WG instance for your meshed network (VPS1 + VPS2 + OPNsense) and I'd do another instance terminating any WG road warriors ingressing connections at the OPNsense level.

Hope this help's a bit.
Regards,
m.

Hi there,

In fact, you'd want to avoid a tunnel down from "remote office", although what are the risks:
1 -- "Remote Office" ISP line/hardware down/bricked.
2 -- OPNsense cluster down.
3 -- local Layer2 devices (switches etc) down.
4 -- "Home Office" unreachable.

In the occurrence of either 1, 2, 3 (and/or); there won't be any connectivity to anything at all from "Remote Office" anyways.
Hence, how many times a year is the "Home Office" unreachable?

If I'd be in your shoes, I'd raise a few questions and would try to get their real answers:
-- do we really "need" all the "remote office" traffic to "break out" at "home office" ? Wouldn't internal resources be enough I.E: 10.0.0.0/8
-- Connectivity behind a FW typically means Layer3, does it make sense to cross a tunnel to get the needed Layer3 remote endpoints setup (DHCP over IPsec)?
-- what is the "remote office" sustained bandwidth need at an average ?
-- what about adding a cheap LTE 4G/5G local break out at "remote office" ?

I would go for a backup "line" with LTE 4G/5G if sustainable.
Also, is IPsec a compliance tied item? WireGuard tunnels would come up extremely fast from which ever source IP coming from your "Remote Office".

Hope this helps a bit.
Cheers

Hi team,

Been wondering if matching hosts from the host header in HTTP would be possible in order to address different upstream servers, obviously serving different purposes.

so the idea would be:
nginx:443 --> host header = host1.domain.suffix --> upstream_1
nginx:443 --> host header = host2.domain.suffix --> upstream_2
and so on.

The backend is not using TLS, so TLS is terminated at the NGINX level. In my testings, it seems that within the "location" I can match URL but not the requested hostname, maybe i'm missing something really obvious here. I succeeded at such a config using caddy but if ever possible I'd like to couple that with NGINX + Naxsi WAF.

Let me know,
regards,
m.

Hey there,

Not an extreme specialist onto multi-wan, though have a few of these in my setup.

Onto your modem uplink, have a check on the followings when connected to OPNsense:
-- interfaces>overview --> you'll directly check if an IP stack is bound to your vtnetX "wan2" interface.
-- system>gateways>configuration --> you need a gateway per uplinks, one for your WAN2 should be present.
-- system>gateways>group --> you'll need a GW group to pool your uplinks (I do this in Tier1 + weight if needed (asymmetrical uplink bandwidth etc..)

As for NAT, obviously depending on what is behind the OPNsense wan2 port, you either need to do NAT at the OPNsense level or you can leave it to the upstream device if it does NAT. IE: LTE modems are usually per default doing NAT in between their LAN port and the LTE uplink.. However, I do prefer to have NAT under my control, so whenever addressing an entity labeled as WAN within OPNsense, I'd apply NAT and in a old school manner: Manual outbound NAT rule generation.

Hope this helps a bit.
Cheers,

Yes, same experience here, just actually wanted to donate again (did so last year) and saw PayPal and card payments with a form that looked like my resume (although just empty) --> backpedaled as well. I won't say anything bad about PayPal though, my only concern is that I can logon that thing once out of ten attempts, effectively locking my own account, needing a landline, a mobile phone, my grand mother ID on top of mine and god knows what else.. This is in fact technology that doesn't work and I prefer to spend my time on things that does; work. An alternative would be welcome, yes

Hi there,

I'm trying to figure out how could I conditionally redistribute static routes (present on ONS_2 in my uploaded representation) within BGP.
The static routes at ONS_2 are tied to a gateway entry (=host ip_forward=1 in my representation), gateway entry which has a Monitor IP set.

You cannot view this attachment.

My goal would be to possibly redistribute these routes within BGP only and if the Monitored IP is up.
Any hints at enabling this?

Thanks a lot,
Regards

I guess that one explanation would be that the adjacent switch DOES NOT have the MAC entries from the involved local subnet IP's (host down/decommissioned etc) and is in fact flooding these frames to all other port except the receiving port.

The witnessed destinations are always the same set of destination IPs with the annoyance that some of the given frames involved seems to trigger Suricata with: ET EXPLOIT Possible VXWORKS Urgent11 RCE Attempt - Illegal Urgent Flag...

Not much I can do I guess..

[not]

Hi all,

I have tested a root server @Hetzner with opnsense and I have the feeling that I'm witnessing all the traffic within the given /26 of the root server assigned public IP address... Had anyone seen this as well? Have I perhaps missed any "opnsense" settings on my WAN interface?

In example:

Code Select Expand

Interface     Time                       Source             Destination             Proto     Label
-------------------------------------------------------------------------------------------------------------------
WAN1        2025-09-20T09:42:11      65.109.83.177:51040    xx.xx.xx.14:9060    tcp    WAN1_DENY_ALL   
WAN1        2025-09-20T09:42:11      65.109.83.177:41840    xx.xx.xx.14:9901    tcp    WAN1_DENY_ALL   
WAN1        2025-09-20T09:42:11      65.109.83.177:51246    xx.xx.xx.14:9100    tcp    WAN1_DENY_ALL   
WAN1        2025-09-20T09:42:11      45.142.193.63:56217    xx.xx.xx.13:22363    tcp    CrowdSec (IPv4) in   
WAN1        2025-09-20T09:42:11      65.109.83.177:44502    xx.xx.xx.14:9113    tcp    WAN1_DENY_ALL   
WAN1        2025-09-20T09:42:11      65.109.83.177:38206    xx.xx.xx.14:9903    tcp    WAN1_DENY_ALL   
WAN1        2025-09-20T09:42:11      65.109.83.177:37934    xx.xx.xx.14:5054    tcp    WAN1_DENY_ALL   
WAN1        2025-09-20T09:42:11      65.109.83.177:37532    xx.xx.xx.14:9902    tcp    WAN1_DENY_ALL   

I do not own any of the destination IP listed above...

Let me know,
Kind regards,
m.

EDIT: the OPNsense wan interface is not in promiscuous mode / IPS is enabled on the interface in IPS mode

Hi,

Sorry to necrobump this one but there are only a very few WG/BGP posts. If possible could you share anonymized sharing of the setup you've enabled here? I also would like to know if each of your distinct local WG instances are listening on a dedicated UDP port, which according to my current testings seems to be the case.

Thanks,
regards,
m.