Messages

I'm using surfshark on the opnsense, basically wireguard the kernel plugin doesnt work well. Switch to the wireguard-go - in the firmware/plugins.

mtu = 1420
mss = 1420

ip configuration = none

See attached my config - keys marked off for security reasons

I'm hoping the new 24.x release will work with the built in kernel, otherwise mmmm

Then in the unbound 'General section', 'Custom options', add the 'local-zone' of the PTR records

Code Select Expand

local-zone: "10.168.192.in-addr.arpa" transparent

Then the PTR record will be queried to the forwarding dns server aka the wifiap router.

When I add this after adding the overrides, the service no longer starts, I'm on OPNsense v21.

Mine looks like this

Code Select Expand

server:
rrset-roundrobin: yes
local-zone: "10.168.192.in-addr.arpa" transparent

Works fine for me. You have no space between "transparent"

So had a similiar issue, I wanted to use my wifiap router to resolve the wifi clients PTR records back to the opnsense.

opnsense > wifiap > wifi client ptr

Turns out unbound blocks by default any local-zone that it does not know about.

So in opnsense 20.7 and later, you need to setup the domain overrides:

as an example:

wifi being the domain forwarded to the wifiap router
and then the PTR address record so to pick up the wifi clients records.

Code Select Expand

wifi 192.168.10.3 wifi domain on AP
10.168.192.in-addr.arpa 192.168.10.3 WIFIAP LAN2G PTR 192.168.10

Then in the unbound 'General section', 'Custom options', add the 'local-zone' of the PTR records

Code Select Expand

local-zone: "10.168.192.in-addr.arpa" transparent

Then the PTR record will be queried to the forwarding dns server aka the wifiap router.

Just to revist this thread:

The following issue 6. is due to some task doing a capture task - i.e. netmap, tcpdump etc.

Its not a new issue and has been around for freebsd for a while - its not really an issue, its just telling you that packet capture is happening.

6. Seeing log spam just like https://forum.opnsense.org/index.php?topic=18480.msg84175#msg84175 constantly in the log.  Not sure if this is cause of issue #1 or not.

Code: [Select]
kernel: pflog0: promiscuous mode enabled
kernel: pflog0: promiscuous mode disabled

In terms of random disconnects, having run the latest 20.7.5 version of opnsense that is based on the freebsd 12.1, there is some tweaking required for the sysctl kernel settings and nic settings.

For my router, i've disabled mostly known issues - LRO, TSO, HWCHKSUM for nics, the 'EEE' energy settings to off. Tweaked the network stack

Also be aware there is some sort of driver transition going on with intel drivers in the newer freebsd releases, so old tweaks need updating based on the latest freebsd man pages i.e. https://www.freebsd.org/cgi/man.cgi?query=iflib

Pfsense 2.5 is suffering from the same teething issues and reason its not released yet.

Could you run

'sysctl -A | grep *your network card driver* - i.e. 'sysctl -A | grep em or igb'

Also 'sysctl -A | grep lacp' - lets see your lacp settings

And post output of each command, em or igb is the intel driver

eee is an energy efficient feature can cause issues on freebsd for nics. By setting 'hw.em.eee_setting = 0' in the tunables will turn this off for all nics.

Also what is your lagg settings on your opnsense? - have you tried loadbalance mode?

also on opnsense, lets see the lacp debugging

'sysctl net.link.lagg.lacp.debug=1' - then share the system log - 'clog /var/log/system.log'


IMAHO: It seems someone else has the same issue as you on pfsense - https://forum.netgate.com/topic/158534/lacp-not-working/79 - and thats a brocade switch.

To help along further with this, there is some possible issues occuring:

1. Have you turned of all offloading options on opnsense? - TSO, LRO? - make sure with the ifconfig
2. Port flap dampening configuration is worth looking at on this switch?
3. Energy saving features of the nics on the server - i.e. hw.em.eee_setting = 0

Maybe do a 'sysctl -A | grep *your network card driver* - 'sysctl -A | grep em or igb'

Also sysctl -A | grep lacp - lets see your lacp settings

IPS works best when set to the WAN interface - to capture inbound traffic coming to you clients on the lan side.

If you want to monitor LAN clients outbound usage for malware etc, then set a limited rule set to track what they are up to, then selectivly enable specific ruleset.

You probably find you have too many rules enabled and your poor router is getting overwhelmed, sucrita is very cpu and memory intensive if you have alot of rules enabled. Remember, even if the rules are not set to drop, it still tracks each rule - using up cpu and memory usage.

How many IDS rules do you have enabled?

If you have too many, then IDS will be checking regardless and consuming lots of memory to do this.

Its best to have minimal list first then grow as you understand the lists you need and not enable all of them.

Also, why do you have it enabled on LAN?, usually its best to enable on WAN and check incoming issues rather than tracking outbound, lan clients can be very noisy and unless you have specific reasons to check you lan clients, best limit to rules that you want not parsing.

So start off with posting what machine is running your opensense? what version of opnsense?

ssh to it and grab the a dmesg output and look at any errors?

find freebsd commands to diagnose network related issues

There is a cool plugin - os-netdata , you can install this and let it run, it actually tells you any issues and graphs whats going on easier.

This should be a good start

VPN -> OpenVPN -> Clients -> Don't pull routes

Incase anyone else stumbles upon having this issue.

The way the opnsense firewall works with openvpn and gateways, it uses the route_vpn_gateway environment variable to set the dynamic gw address - this requires that the 'Dont pull  routes' is unticked (enabled) and the 'Dont add/remove routes' option is disabled (ticked).

'Dont add/remove routes' option if enabled will override your global routing table to use the vpn gw as the default for all internet traffic.

so the opposite of what this picture is showing.

Otherwise what happens is the vpn client ip address is set as the gw, which wont allow the nat to send traffic from the clients via the vpn connection - as it has no way of routing traffic across.

You dont need to set the dynamic gateway in the interface of the vpn as the openvpn client program will set the correct gw address for you.