Messages

Hi, static NAT ports for UDP are a godsend for real-time protocols. Anyone who has troubleshooted WebRTC knows this: they're worth their weight in gold. They cost nothing, except to acknowledge that port "randomization" in UDP is not a security feature.

pass out quick on igc0 inet proto udp from igc1:network nat-to (igc0) static-port
pass out on igc0 inet from igc1:network nat-to (igc0)

Hi, the best option for redirecting DNS is to use rdr on the same interface.

rdr pass in quick on $if_lan proto { udp tcp } from any to any port domain -> lo0 port domain

I use it on OpenBSD

pass in quick on $if_lan proto { udp tcp } from any to any port domain rdr-to lo0 port domain

One solution for distributing blocklists across your networks is to use RPZ.
The problem is that you have to do it manually in /usr/local/etc/unbound.opnsense.d
https://unbound.docs.nlnetlabs.nl/en/latest/topics/filtering/rpz.html

This protocol isn't allowed for security reasons. It's fine, but it's obsolete nowadays. I'm referring to the blocking implemented by FreeBSD. It was vulnerable in MLDv1, but now it's more secure in MLDv2. This protocol is normally only used for MLDv2. It could be allowed in FreeBSD.

RFC 3810 & RFC 9777 (MLDv2) Section 7.4:
Upon reception of an MLD message that contains a Report, the router checks if the source address of the message is a valid link-local address, if the Hop Limit is set to 1, and if the Router Alert option is present in the Hop-by-Hop Options header of the IPv6 packet. If any of these checks fail, the packet is dropped.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290407

Denny Page:
IPv6 Multicast Listener Discovery packets, specifically Multicast Listener Reports, do not contain a Router Alert option as required by the Multicast Listener Discovery RFCs. The lack of a Router Alert option causes Listener Report packets to be discarded by receivers.

Packets that come in do have that option, you can see it in a log. The problem is that Freebsd doesn't recognize the Hop-by-Hop Options Header, and this packet is dropped.

I really appreciate the response.
I have no problems, Opnsense works perfectly.
I receive Hop-by-Hop packets and the firewall rejects them, but it doesn't affect the connection.
Thanks for everything.

Yes, I'm asking if it's affected and that's why the protocol isn't allowed.
I know that protocol has been a vulnerable point.
I think it's necessary for MLD to function properly.

Hello everyone, just one question, why is this protocol not allowed in Opnsense

RFC2710
MLD message types are a subset of the set of ICMPv6 messages, and MLD messages are identified in IPv6 packets by a preceding Next Header value of 58. All MLD messages described in this document are sent with a link-local IPv6 Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option [RTR-ALERT] in a Hop-by-Hop Options header.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290407

Hello everyone, I'm trying to configure WireGuard using the IPv6 prefix I received to avoid NAT for IPv6 traffic. I created a WireGuard instance with the assigned prefix and a unique IP address, and automatically, in the Dnsmasq leases, the connected devices switch from LAN to VPN (strange).
VPN is the name of the WireGuard interface.

You cannot view this attachment.

You cannot view this attachment.

You cannot view this attachment.  <--- From LAN to VPN

What am I doing wrong?

Thanks

If it is relevant, I only request the prefix and size.
And manually I configure prefix ID, interface ID

You cannot view this attachment.

I'm sorry, I've done what I could, I don't have much knowledge

It's not working for you yet?

I have it with CIDR /32

it's complicated

If it doesn't work for you, use this for the IPv6 PTR

https://www.whatsmydns.net/reverse-dns-generator?q=

my configuration

I still see lan.internal

I still see lan.internal

and change it here also to Internal