Recent posts

#1
Private Girls In Your Town - No Selfie - Anonymous Casual Dating
https://privatedates.live
 
Private Girls In Your Town - Anonymous Casual Dating - No Selfie
 
NEW GIRLS
Bella Rose
Luxury Girl
Carolina
Kate Dew
Adriana Chechik
Mia
Yumi
Dovia
Kate Katysha
CANDY SMILE
Alexis Texas
KATIE PEARL
Mia Gag
#2
26.1, 26,4 Series / Re: WAN interface passing to p...
Last post by lmoore - Today at 05:07:00 AM
Quote from: glenb2 on June 30, 2026, 03:00:03 AMcould someone explain why my WAN interface is passing outward traffic to these networks?

Thinking about this a little more, I expect the IP addresses you are seeing are from your Apple devices and they are trying to communicate with devices they have connected to in the past.

I have seen something similar on my network with an app installed on a visitors smart phone and it wanting to communicate with the streaming media service on the owners home network. That traffic was appearing in my logs as blocked inbound traffic destined for a RFC-1918 network not in my environment.



Note, my "in" and "out" rules are set to Last match. This is so I can create new rules which include RFC-1918 addresses without having to worry about these rules interfering with them.

I have access to my DSL modem's interface which is on my WAN interface, however, I  have implemented access differently to @meyergru's excellent document, and do not have any exclusions in my RFC1918 alias to access it, and yes, my WAN interface is set to block private networks - image provided earlier in this thread.
#3
26.1, 26,4 Series / Re: 2 WAN Uplinks split routin...
Last post by lmoore - Today at 02:51:24 AM
Quote from: paul5012 on June 30, 2026, 09:57:00 PM
Quote
Quote1) what is the sense of "no RDR (NOT)" (Enabling this option will disable redirection for traffic matching this rule.) Wouldn't make this the rule itself pointless?
For a single port forwarding rule, it does.
I guess, this can make sense if you forward multiple / all ports. So using this option you can define an exception.
Still not quite clear to me.

OPNsense uses "no rdr" by default on the LAN interface to prevent redirects away from OPNsense management ports, i.e. SSH, HTTP & HTTPS and for CARP.



HTH.
#4
General Discussion / Periodic NIC issues (?) with P...
Last post by fornax - Today at 02:09:53 AM
I'm working on troubleshooting an issue that's been popping up irregularly since deploying OPNSense on a Protectli VP3210 (both new to me). The device is set up to perform all DHCP, DNS, firewall, and routing duties for the home network behind it.

Approximately every 1-7 days the network starts acting up. The symptoms aren't always consistent, but so far have tended to fall into one of three categories:

1. Something that looks like a DNS issue. Attempts to resolve an address will usually time out first try, but then succeed immediately a few seconds later. If I connect to the upstream router and use the same resolver, everything is normal.

2. DHCP will stop working for some/all devices.

3. An online game I play regularly has trouble connecting to the game servers.

Regardless of the symptom, the workaround that resolves it (temporarily) is the same. Go to Interfaces -> Settings, uncheck "Disable hardware checksum offload", Apply, recheck the box, Apply again. Everything immediately starts working as it should. (This is why I assume this is a NIC issue.)

Doing some research, I see that it's not uncommon for people to have issues with the Intel i226-V NICs, something I missed when I chose the hardware. Based on what I read I've been playing with various tunables, rebooting as necessary:

dev.igc.0.fc=0
dev.igc.1.fc=0
dev.igc.0.eee_control=0
dev.igc.1.eee_control=0
net.isr.bindthreads=1
net.isr.maxthreads=-1
net.isr.dispatch=deferred
net.inet.ip.intr_queue_maxlen=3000
hw.pci.enable_aspm=0

So far nothing has made a difference. The other thing that seems to be done commonly with these NICs is to upgrade the NVM firmware, which I'll try if I have to but that's a bit intimidating. Anyone have any other ideas before I go that route?
#5
26.1, 26,4 Series / Re: Problem with shutdown/rebo...
Last post by mrzaz - Today at 12:20:15 AM
Quote from: franco on June 25, 2026, 09:52:03 PMCan you confirm this only happens with divert? It may be an open file descriptor / socket that the kernel doesn't yield.


Cheers,
Franco

Hi Franco,
I have now tested with Divert (IPS), then Netmap (IPS) and then back to Divert (IPS) again.

Result is that with "Netmap (IPS)" I do not get this hangings and it could run for hours and
every time I tried a reboot it shutdown clean and restarted as normal.

But when I reverted back to "Divert (IPS) and let it run for a few hours and then try
a reboot it hangs waiting for suricata PID to die. I then tried "kill TERM <pid>"
but did not help.  I then had to go for the big gun with "term -9 <pid>" and then
it continued the shutdown and rebooted OK.

I do have some trace printouts that I could send if someone wants to review ?

//Dan Lundqvist
#6
Quote from: thelittleblackbird on June 27, 2026, 12:42:34 AMhere you have it, in the attached file.

I tried to implement the tunnable described in the opnsense documentation about performance:
https://docs.opnsense.org/troubleshooting/performance.html

if you need something else just ask

thanks


If you have set RSS for that performance, it might need revisiting. Maybe it does not help and is detrimental in your case.
#7
26.1, 26,4 Series / Re: Problem with shutdown/rebo...
Last post by mrzaz - Today at 12:13:33 AM
Hello,
I had it running for 1-2 days using "Netmap (IPS)" and did a few manual reboots and it shuts down/reboot OK.
I then reconfig it to "Divert (IPS)" and then after a while I got the same hard lock.

I did a lot of debug printouts that I could send if someone is interested.
I tried first "kill -TERM 73697" but that did nothing.  process still hanging.
I then did a "kill -9 73697" and then it continued all the way to reboot and then up again.

Seems like it is happening in relative short time on "Divert (IPS)".

//Dan Lundqvist
Stockholm, Sweden
#8
Hardware and Performance / Re: latencyspikes of seconds ...
Last post by pfry - June 30, 2026, 11:37:34 PM
Quote from: thelittleblackbird on June 30, 2026, 09:50:29 PM[...]some other idea? honestly unless somebody is coming with something i am starting to think like a bsd problem, because i can not really udnerstand what is going on...

I wouldn't trust stress-ng to uncover issues, but that's up to you. mprime doesn't stress non-hyperthreading Coffee Lakes much, for instance.

How about the PCI query?

It could be a software issue. My experience is limited to a couple FreeBSD and a couple OPNsense machines, all bare-metal. Recent/relevant experience, that is. Most of the pf messages could point to really wacky network issues, but (in particular) I wouldn't expect a duplicate flow ID to be a soft issue (within the scope of a standard OPNsense install). I just don't have enough experience poking into pf to say with certainty.
#9
Hardware and Performance / Re: Slow DNS above 7K sessions...
Last post by rudiservo - June 30, 2026, 11:35:46 PM
State tables are at ~7K

Max State setting is currently at 1000000

Resolving DNS is the issue, I learned that torrents make a lot of DNS requests, that is probably making unbound very laggy.
#10
26.1, 26,4 Series / Re: 2 WAN Uplinks split routin...
Last post by paul5012 - June 30, 2026, 09:57:00 PM
Quote from: viragomann on June 30, 2026, 04:21:15 PM
Quote from: paul5012 on June 30, 2026, 03:38:23 PMI was not aware that "Rules [new]" section is possibly not (yet) stuffed with all features of the old system.
It is already, as far as I know.

However, it's not recommended to use both, old and new rules.
You should migrate your rule at some point.
I had done this.

Quote from: viragomann on June 30, 2026, 04:21:15 PM
Quote from: paul5012 on June 30, 2026, 03:38:23 PMSo far I had tried to live with destination NAT rules and the option "Firewall rule": "Register rule".
With "Register rule" OPNsense creates the firewall rule for you and you're able to modify it later. But I'd rather create rule manually instead.
what I did, finally.
Quote from: viragomann on June 30, 2026, 04:21:15 PM
Quote from: paul5012 on June 30, 2026, 03:38:23 PM1) what is the sense of "no RDR (NOT)" (Enabling this option will disable redirection for traffic matching this rule.) Wouldn't make this the rule itself pointless?
For a single port forwarding rule, it does.
I guess, this can make sense if you forward multiple / all ports. So using this option you can define an exception.
Still not quite clear to me.
Quote from: viragomann on June 30, 2026, 04:21:15 PM
Quote from: paul5012 on June 30, 2026, 03:38:23 PM2) "NAT reflection"
NAT reflection mirrors a NAT rule to internal interface in short.
So if you define a NAT rule on WAN for the WAN IP to forward port 443 to webserver 1 in DMZ. NAT reflection enable you to access the webserver using the WAN IP also from LAN.
got this. seemed to help me alot, but gave me other troubles when a forward from port 25 to [dmz-server] port 25 suddenly hat a redirection from the DMz system to itself.
Could not get rid of this afterwards, what led to the fresh install eventually.
Quote from: viragomann on June 30, 2026, 04:21:15 PM
Quote from: paul5012 on June 30, 2026, 03:38:23 PM3) "Set tag" I suspected to be what I should use.
No, this is for custom tagging.
With this you can instruct OPNsense to tag connection and use this tag by following rule, e.g. outbound rules.

Quote from: paul5012 on June 30, 2026, 03:38:23 PMNow the packets flow as expected, I can reach my services with both published IP addresses.
Fine.

Quote from: paul5012 on June 30, 2026, 03:38:23 PMSo I have to define such a rule for every port forwarding for each of the two upstream interfaces?
You only need this for incoming traffic from the internet (from source addresses, which OPNsense has no specific route for. This could also be a remote client accessing your resources over VPN).
You can also use aliases for forwarded ports or destination IPs. So don't need one for each NAT rule.
I use these aliases excessively.
Quote from: viragomann on June 30, 2026, 04:21:15 PM
Quote from: paul5012 on June 30, 2026, 03:38:23 PMI'd expect this to be default behaviour, that return packets go back the interface they came in.
Yes, it is. But possibly this doesn't work together with a load balancing gateway group.

I do (not currently) make use of any loadbalancing gateway group.

When you said, "new rules" should be able to replace the old style completely: I could not find a way to define the back path as needed.
Could it be possible that there is a bug or a to-be-implemented feature somewhere around in this version?