"Recent posts
#1
General Discussion / Re: NAT64 Support via af-to
Last post by excavator fidelity - Today at 07:16:16 AMQuote from: Monviech (Cedrik) on Today at 06:52:03 AMhttps://github.com/opnsense/core/issues/10570
Thanks! I'll be sure to follow the technical discussion there
#2
General Discussion / Re: NAT64 Support via af-to
Last post by Monviech (Cedrik) - Today at 06:52:03 AM #3
General Discussion / NAT64 Support via af-to
Last post by excavator fidelity - Today at 06:50:56 AMOPNsense 26.7 is now on FreeBSD 15.1, which means pf now supports the af-to option (manpage).
Currently the only way to perform NAT64 is to use Tayga, but that runs in userspace via TUN.
It would be great if OPNsense would add the ability to configure af-to rules in the OPNsense firewall > NAT page.
That would allow users to migrate off of Tayga and hopefully improve the speed of translation.
Possibly relevant prior discussion: https://forum.opnsense.org/index.php?topic=50096.msg256170#msg256170
Currently the only way to perform NAT64 is to use Tayga, but that runs in userspace via TUN.
It would be great if OPNsense would add the ability to configure af-to rules in the OPNsense firewall > NAT page.
That would allow users to migrate off of Tayga and hopefully improve the speed of translation.
Possibly relevant prior discussion: https://forum.opnsense.org/index.php?topic=50096.msg256170#msg256170
#4
Zenarmor (Sensei) / Re: Important Announcement for...
Last post by dinguz - Today at 06:30:24 AMAre you still using Elasticsearch 5? It's deprecated and no longer supported. You should switch to Elasticsearch 8 which is the currently supported version.
#5
General Discussion / Re: Lost GUI and "Media discon...
Last post by AlexOd - Today at 04:27:30 AMJust want to add more.
Interface status: Confirmed that Lan2 is enabled in the interface configuration settings.
DHCP service: Set up the Kea DHCPv4 (192.168.2.10 - 192.168.2.100) for the 192.168.2.0/24 subnet on Lan2.
Firewall rules: Cloned and applied a pass rule for the Lan2 interface to allow traffic.
Interface status: Confirmed that Lan2 is enabled in the interface configuration settings.
DHCP service: Set up the Kea DHCPv4 (192.168.2.10 - 192.168.2.100) for the 192.168.2.0/24 subnet on Lan2.
Firewall rules: Cloned and applied a pass rule for the Lan2 interface to allow traffic.
#6
26.7 Series / Small bug in Dashboard layout ...
Last post by rreiner3 - Today at 04:17:32 AMA small bug in the dashboard layout engine. When I edit the dashboard as per attached image 1, and save t per attached image 2; then go to some other screen and then come back to the dashboard, the Disk widget now has erroneous spacing, as per image 3.
#7
General Discussion / Out of Box Expieriance is Brok...
Last post by tuaris - Today at 04:06:35 AMI've noticed a degradation in quality with the user experience in OPNSense. The poorly designed (new) GUI's around IPSec, NAT, and now the DHCP server are one thing. However, now I've also noticed that in the last few versions that just going through the setup wizard no longer results in a functioning system. At least when it comes to using a static WAN address.
Just try it, download an image, assign your interfaces using the CLI, then open up a web browser. Go through the setup wizard and experience how you get no internet connectivity on your client machines. The OPNsense device it self can connect, but nothing behind it can.
You have to 'know' to go into your WAN interface and select your gateway because it defaults to "disabled", despite you being asked to enter it in the setup wizard.
I've been able to reproduce this multiple times, so please don't come back and say to me you that it works for you. :)
Just try it, download an image, assign your interfaces using the CLI, then open up a web browser. Go through the setup wizard and experience how you get no internet connectivity on your client machines. The OPNsense device it self can connect, but nothing behind it can.
You have to 'know' to go into your WAN interface and select your gateway because it defaults to "disabled", despite you being asked to enter it in the setup wizard.
I've been able to reproduce this multiple times, so please don't come back and say to me you that it works for you. :)
#9
Chinese - 中文 / Re: 增加阿里云和腾讯云动态域名解析支持
Last post by mebe - Today at 03:45:15 AM你这个蛮不错的。可惜我没有早点看到，我现在使用的是DDNS-go作为动态域名的服务。是根据github上开源的项目，然后自己小改了一下。嵌入到opnsense的GUI里的。
#10
26.7 Series / Re: MTU settings for wireguard...
Last post by OPNenthu - Today at 03:38:31 AMAlso not an expert but I am a WG user and this is what works for me.
I think everything hinges on what your WAN MTU is, as that is the basis for WG MTU and MSS clamping. If your modem wants MTU 1500 then you don't need to touch MTU settings anywhere (in theory) as the defaults are already 1500 for WAN and 1420 (= 1500 - 80) for WG instances. I suspect that's where the 80 bytes for the "mobile connections" comes from; they are probably referring to the road warrior peers.
The thing you need to set is MSS clamping for TCP traffic. You can do it in the interface settings if you are using separate "wgX" interfaces, but for the default "WireGuard (group)" you should use a Normalization rule as per https://docs.opnsense.org/manual/how-tos/wireguard-client.html#step-5a-create-normalization-rules. 1360 is a safe default MSS value that covers both IPv4 and IPv6.
If you instead set the MSS value in the "wgX" interface settings then use 1420 there. As the helptext explains, it automatically deducts 40 for IPv4 and 60 for IPv6. I think you may not need to even set it manually in that case because the interface should inherit the correct value already from the WG instance.
If I'm wrong about something then I hope to be corrected and learn something new as well.
I think everything hinges on what your WAN MTU is, as that is the basis for WG MTU and MSS clamping. If your modem wants MTU 1500 then you don't need to touch MTU settings anywhere (in theory) as the defaults are already 1500 for WAN and 1420 (= 1500 - 80) for WG instances. I suspect that's where the 80 bytes for the "mobile connections" comes from; they are probably referring to the road warrior peers.
The thing you need to set is MSS clamping for TCP traffic. You can do it in the interface settings if you are using separate "wgX" interfaces, but for the default "WireGuard (group)" you should use a Normalization rule as per https://docs.opnsense.org/manual/how-tos/wireguard-client.html#step-5a-create-normalization-rules. 1360 is a safe default MSS value that covers both IPv4 and IPv6.
If you instead set the MSS value in the "wgX" interface settings then use 1420 there. As the helptext explains, it automatically deducts 40 for IPv4 and 60 for IPv6. I think you may not need to even set it manually in that case because the interface should inherit the correct value already from the WG instance.
If I'm wrong about something then I hope to be corrected and learn something new as well.
