Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Ametite

#1
Hi, I'm pretty sure that is the same issue here, I posted a screenshot of the WAN->LAN rule (+divert-to Suricata, and DNAT rule).

Here you can see the screenshot, the same rule is blocking and passing the traffic.
https://forum.opnsense.org/index.php?topic=52395.0
#2
Quote from: dseven on July 14, 2026, 10:00:49 AMA quick bit of research reveals that MAP-E uses the ICMP client identifier in place of a source port for tracking. The MAP-E CPE would normally rewrite the client ID to a number within your assigned port range. If your ping client supports it, try specifying a client ID within your range. On modern Linux, the '-e' option should work...

Interesting... but I tried with ping -e [value] from PVE, no one was getting anywhere. Normal ping 1:4 succeed.
#3
Same as me, but if you choose in NAT rule --> options ->> firewall rule (pass) it works again, so I think there's something wrong in the fw rules(?).

P.s. The rules was already migrated to DNAT and they were working with the last 26.1 version.

Here the firewall log, I can see the allow rule and a block one. The fw rule is now "allow from WAN to LAN dst IP + DST port", the DNAT rule is "from WAN port to LAN dst IP + DNAT port".

EDIT:
I's the combination of DNAT & divert-to rule (Suricata).
https://github.com/opnsense/src/issues/303
#4
I wanted to report that my previous statement is partially incorrect.

I did further testing and, with this hybrid SNAT configuration, only 1:4 of the ICMP pings are successful, exactly the same as the ratio of the IPv4 range port assigned to me by my provider.

Granted, there's no source port for ICMP, but I think some sort of "random port" is generated somewhere, something that is independent by the operating system I'm testing from (whether Linux or Windows makes no difference).

Just to be clear, now I have hybrid NAT, a manual rule that intercept TCP/UDP traffic and force the exit port range 24576:32767 and the other one generated by auto-conf LAN->WAN with any protocol and * as source NAT port.
#5
Quote from: dseven on July 08, 2026, 03:49:04 PMWhat does "pfctl -s nat" show?

Now it seems works, but only if I choose Hybrid rules and not manual. The rule I created should works even without auto generated rules.

root@fw-fe:~ # pfctl -s nat
no nat proto carp all
nat on vtnet0 inet proto tcp from (vtnet1:network) to any -> (vtnet0:0) port 24576:32767
nat on vtnet0 inet proto udp from (vtnet1:network) to any -> (vtnet0:0) port 24576:32767
nat on vtnet0 inet from (vtnet1:network) to any -> (vtnet0:0) port 1024:65535
nat on vtnet0 inet proto tcp from <LAN_udine> to any -> (vtnet0:0) port 24576:32767
nat on vtnet0 inet proto udp from <LAN_udine> to any -> (vtnet0:0) port 24576:32767
nat on vtnet0 inet proto tcp from (self) to any -> (vtnet0:0) port 24576:32767
nat on vtnet0 inet proto udp from (self) to any -> (vtnet0:0) port 24576:32767
nat on vtnet0 inet proto tcp from 192.168.1.50 to any -> (vtnet0:0) port 1024:65535
nat on vtnet0 inet proto udp from 192.168.1.50 to any -> (vtnet0:0) port 1024:65535
nat on vtnet0 inet from (vtnet1:network) to any port = isakmp -> (vtnet0:0) static-port
nat on vtnet0 inet from (lo0:network) to any port = isakmp -> (vtnet0:0) static-port
nat on vtnet0 inet from (ipsec10:network) to any port = isakmp -> (vtnet0:0) static-port
nat on vtnet0 inet from 127.0.0.0/8 to any port = isakmp -> (vtnet0:0) static-port
nat on vtnet0 inet from (vtnet1:network) to any -> (vtnet0:0) port 1024:65535
nat on vtnet0 inet from (lo0:network) to any -> (vtnet0:0) port 1024:65535
nat on vtnet0 inet from (ipsec10:network) to any -> (vtnet0:0) port 1024:65535
nat on vtnet0 inet from 127.0.0.0/8 to any -> (vtnet0:0) port 1024:65535
no rdr proto carp all
no rdr on vtnet1 proto tcp from any to (vtnet1) port = ssh
no rdr on vtnet1 proto tcp from any to (vtnet1) port = 24600
rdr on vtnet0 inet proto tcp from <Trusted_EXT> to (vtnet0) port = 24806 -> 192.168.2.5 port 8006
rdr on enc0 inet proto tcp from 192.168.1.254 to (self) port = domain -> 192.168.2.254 port 53530
rdr on enc0 inet proto udp from 192.168.1.254 to (self) port = domain -> 192.168.2.254 port 53530
rdr on vtnet1 inet proto tcp from any to ! (self) port = domain -> 127.0.0.1 port 53
rdr on vtnet1 inet proto udp from any to ! (self) port = domain -> 127.0.0.1 port 53
rdr on vtnet1 inet proto tcp from any to ! (self) port = domain-s -> 127.0.0.1 port 853
rdr on vtnet1 inet proto udp from any to ! (self) port = domain-s -> 127.0.0.1 port 853
rdr on vtnet1 inet6 proto tcp from any to ! (self) port = domain-s -> ::1 port 853
rdr on vtnet1 inet6 proto udp from any to ! (self) port = domain-s -> ::1 port 853
rdr on vtnet1 inet6 proto tcp from any to ! (self) port = domain -> ::1 port 53
rdr on vtnet1 inet6 proto udp from any to ! (self) port = domain -> ::1 port 53
#6
Quote from: Monviech (Cedrik) on July 08, 2026, 09:29:23 AMI don't understand, only UDP and TCP do have port numbers. ICMP has types. Other protocols don't have port numbers or use different schematics.

Yes, that's what I know too from the theory, but I think the old config works for a reason I don't know.

Quote from: dseven on July 08, 2026, 10:18:12 AMI guess the issue is that the new interface won't allow specifying a target port range when the protocol is "any", so I suppose you'd have to create one rule for TCP/UDP (with port range) and another rule for "any", and use sequence numbers to ensure that the TCP/UDP one comes first? Seems kindof unnecessarily cumbersome?

Curiously PF shows a port range even for ICMP-specific rules:

root@opntest1:~ # pfctl -s nat | grep icmp
nat on igc1 inet proto icmp from (igc0:network) to any -> (igc1:0) port 1024:65535
root@opntest1:~ #

Exactly, now I'trying to, I just configured SNAT with two rules, one TCP/UDP with the specific ports and the other with the generic one below the first one, but it doesn't seem to work.
Do you know what the command is to reload the NAT rules? I'm not sure if they are reloaded when the settings are saved.
#7
Good morning all, I'm here to report a missing configuration from old outbound rules to new one. I know it's something that is my specific need/implementation but I put here some contest.

My ISP (Iliad Italia) uses MAP-E (not supported from OPNsense), but I use a trick and I connect the ISP router LAN ("router mode, no NAT") to the OPNSense WAN, then I know from ISP router GUI the port range (1:4) that is assigned to me (eg 24576:32767).
That range port was configured in the old outbound NAT, that allowed to set outbound interface WAN (with its IP address) AND the port range. The new Source NAT does not allow you to set the port range without choosing the TCP/UDP option, but - in this way - every protocol that is not TCP/UDP will not work (ICMP, etc...).
Now I have to roll back to old rules and all is working again.

Do you know if this can be implemented, or if I'm missing something?

Thanks a lot.
#8
26.1, 26,4 Series / Re: Suricata - Divert (IPS)
February 03, 2026, 04:11:12 PM
Quote from: szix96 on February 03, 2026, 03:07:59 PMHello,

sorry having a hard time understanding this DIVERT parameter.
So if i set FW rules to allow ports 443/80/5520 and then i create an additional FW rule with the same SRC/DST IP's then the 1ST rule would allow only the traffic on the ports defined and the second would send the traffic to the IPS?
or how is it possible to filter with DIVERT IPS?

as in the pic if i allow the 2 DIVERT rules?

Thank you all for the awesome work on this.


I think you confused protocol divert with Advanced Options -> divert to. Or I miss something..
#9
26.1, 26,4 Series / Re: Suricata - Divert (IPS)
February 03, 2026, 12:49:51 PM
Hi, regarding the Suricata crash issue with IPS Divert mode (https://github.com/opnsense/core/issues/9712), is anyone else affected by the same problem?
#10
26.1, 26,4 Series / Re: Upgrade to RC1 successful
January 23, 2026, 02:27:29 PM
From my side all seems working well, upgraded from 25.7.11_2 to 26.1-RC1.
I've already tested IPSEC, BIND, unbound, BGP with FFR, Wiregard, OVPN, Crowdsec, Suricata, and other plugins less deeply.
FW rules migrated completely.
The only thing that I noticed is that the auto-generated floating rules are visible correctly only on old rules, in the new section I see some blank rules.

I would also ask the diff between NAT outbound rules and SNAT.
Thanks :)

⚠️EDIT: it seems that floating rules apparently blank was in fact a very dangerous "any to any" and I rolled back to snapshot this time for being sure 100% that all is properly blocked as before
#11
Good morning, everyone. I apologize if this is not the correct section; I'm relatively new here.
This morning, I received a CVE report from our cybersecurity agency regarding CVE on Kea DHCP. I checked the packet version in OPNsense, and it appears to be affected in the latest available version of OPNsense.

https://www.acn.gov.it/portale/en/w/aggiornamenti-di-sicurezza-per-prodotti-isc

https://www.cve.org/CVERecord?id=CVE-2025-32801

This is just as report :)
#12
Same message here, latest version installed
#13
Yes, it has gone. Thanks.
#14
Hi, I noticed a black empty widget (I cannot remove it because I cannot see the "x" button) after upgrading to the latest version.



I don't remember exactly what there was there before the upgrade.
#15
Thanks it works! But, my question is: could´t be easier to add this possibility to "pass" all the system notification to Monit and send them via email? On pfSense it was sufficient to install apcupsd, then in system embedded setting enable system email notification (not only apcupsd) and you will get the email when power goes down, immediately without polling time, in the same instant you see the message via SSH...