Recent posts

#1
25.7, 25.10 Series / Re: Firewall Rule using ports ...
Last post by pfry - Today at 03:53:35 AM
Looks OK offhand. Unless someone else has a better idea, look at the live view again and hit the "i" to the right - I'd look initially at TCP flags (if the value is not "S", it's a session issue). I'd also activate logging for the pass rules so you can see them as well - seeing only blocks can be misleading. Personal preference, of course.
#2
General Discussion / Re: Need some guidance in how ...
Last post by passeri - Today at 03:11:22 AM
Get another AP. Attach one to each of the two LAN ports, configured as described by Coffeecup25. Run the IoT one on the 2.4 GHz band as a completely separate network from your primary LAN devices on a 5 GHz band.  Usually IoT devices do not need much data so bandwidth is unlikely to be an issue. You can find APs with a few ethernet ports at low cost.

It is possible to run multiple wireless networks off a single AP but that does not solve your upstream problems as easily as whacking on another AP on a distinct network.
#3
25.7, 25.10 Series / Re: Firewall Rule using ports ...
Last post by LisaMT - Today at 01:51:37 AM
IPv4 TCP/UDP   LAN net   *   *   SafePorts    *   *      Allow Safe Ports (80, 443)      
           
IPv4 TCP/UDP   TVs    *   *   TVPorts    *   *      Allow TV's to their ports(Bunch of ports) Including 80 and 443      
              
IPv4 *   *   *   *   *   *   *      Block LAN Traffic      

TV's are on .63-.65

I added the t65tv temporarly to allow to anywhere.  I'll check the logs and see if it shows.


LANIn2025-12-12T17:35:30-07:00TCP192.168.10.63:5512963.34.182.173:443 blockBlock LAN Traffic
LANIn2025-12-12T17:35:30-07:00TCP192.168.10.63:5512963.34.182.173:443 blockBlock LAN Traffic
LANIn2025-12-12T17:27:34-07:00TCP192.168.10.63:3911434.160.212.185:443 blockBlock LAN Traffic
LANIn2025-12-12T17:27:34-07:00TCP192.168.10.63:3911434.160.212.185:443 blockBlock LAN Traffic
LANIn2025-12-12T16:57:35-07:00TCP192.168.10.63:57909174.129.18.38:443 blockBlock LAN Traffic
#4
Virtual private networks / WG Multi Tunnel GW setup...
Last post by jcditto - Today at 01:24:48 AM
Ok, I've been working at this for about a week now.  I am trying to do a setup were I have 4 WG tunnels and all traffic is routed through those tunnels or not at all, if the tunnels are down.  I have the basic connectivity working, but only if I just allow all on the traffic.  Once I put in a "Route to VPN only/Kill Switch" rule set, I cannot route on any client.  The good news is, even with allow all on, traffic seems to stick to the tunnels, but since I can't force it there or nothing, I can't be sure it will stay that way.  We could fall off the VPN at any point and not notice.  I dont' know what you need or want to see on the setup, just let me know and I can provide the info.  I don't want to toss info on here without a request of it, as that may confuse the issue.

Summary of Goals:
4 VPN tunnels setup in a group, all T1, just aggregating for speed
Ability to force traffic through that GW setup and if no VPN tunnel, block till working again.

Currently:
Tunnels are in, working and flowing fine however, if I disable them traffic just falls back to the open WAN connection, instead of failing
I have build a tunnel rule and a killswitch rule, but when enabled and allow all is off, no routing works.
#5
Quote from: m256 on December 03, 2024, 03:13:12 PMSo, good news: I have tried with custom configs- created custom config file in swanctl\conf.d
I made a completely new connection with unique id and full settings. It worked - even with deprecated ciphers.
I also tried adding just an update to settings made in GUI like this:
connections {
    con1 {
        children {
            con1 {
                esp_proposals = aes128-sha1
            }
        }
    }
}
this worked fine as well.

What does not work is 3des for ESP. This is not done by strongswan, but kernel. Adding 3des support to freebsd would likely mean kernel recompiling.
Hello,

thanks for the helpful post, it already clarified a lot. I still have a few short follow-up questions:

Which exact path did you use for the custom config? Does any file under /usr/local/etc/swanctl/conf.d/*.conf (for example custom.conf) work, or did you specifically use override.conf?

Was the connection also created in the GUI, or was it defined entirely via the custom config file?

In the partial override example using connections { con1 { children { con1 { ... }}}: do both the connection name and the child name have to match exactly the names shown by swanctl --list-conns?

After modifying the file, did you only run swanctl --load-all, or did you also click "Apply" in the GUI?

I'm asking because on OPNsense 25.1.6_4 I do not see any changes when using either /usr/local/etc/swanctl/conf.d/custom.conf or override.conf (verified with swanctl --list-conns).

Thanks for a short clarification.
#6
General Discussion / Re: PSA: recent Comcast firmwa...
Last post by allan - Today at 12:45:57 AM
Quote from: really_lost on December 05, 2025, 04:47:29 AMIf you are affected by this, you'll want to get a ticket opened and request a firmware rollback.

I really want to emphasize this to anyone reading. IPv6-PD is not commonly used and it is not actively monitored-at least by Tier 1 support since they told me their diagnostics all show green. It takes everyone affected to call and open a ticket before someone notices. The call volume has to be enough to show up in their reports. Otherwise, our issue stays below their radar and they consider us "isolated issues".
#7
General Discussion / Re: PSA: recent Comcast firmwa...
Last post by allan - Today at 12:27:15 AM
Thanks for telling me about this thread, Franco. I spoke to someone in their corporate escalations group on Nov 10. Even he had to find a way to get it escalated into their engineering group. By Dec 1st, they rolled back my firmware at my request and I confirmed that fixed the problem (again). They then started rolling everyone back on Dec 5th and expected to complete that process by Dec 8th. He was going to update me if things change and I was going to reach out if the rollback caused issues. Thankfully, all went well.

Sadly, this is not the first time firmware updates affected my IPv6. My previous event triggered the modem's firewall and *block all incoming IPv6 connections* even though it is set to "disabled". Port forwarding, IPSec, client VPNs all went down. Similar to this time, I found someone who was able to relay it into engineering.

Btw, the one I am eagerly awaiting news on is the CheckPoint vs StrongSwan 6.0.3 CHILD_CREATE issue we had (#9382). The latest info I received today was their R&D discussed my case in their meeting and they will investigate my issue before making a decision. I set up a lab to gather logs and sent it all in along with Tobias' comments and links to the RFCs. I hope it was convincing enough.

#8
Hardware and Performance / Re: DEC750 Questions
Last post by ProximusAl - December 12, 2025, 11:57:29 PM
Device received.....
Nice bit of kit...

I decided to ride the lightning and ignored previous advice and:

1. Updated the BIOS to .35 (Was on 33)
2. Formatted the NVMe and installed Community 25.7 from serial image (ZFS)
3. Added the AMD microcode plugin
4. Updated to 25.7.9_7
5. Did *not* enable HyperThreading in BIOS.

I ran out of time, so will play with importing (after modifying interfaces) my existing config.

If it runs stable and nice, I'll order another 3 to replace other Chinese devices :)

The only oddity I found, was when updating from 25.7 to 25.7.9, I did get an error throw on the screen to check the log (blueish background popup), but I found nothing and it installed and rebooted as expected anyway with no intervention. (This wasn't the original pkg update error...I got that first as expected)

Health checks all pass after the reboot.

Really looking forward to getting this into prod..
#9
25.7, 25.10 Series / Re: Firewall Rule using ports ...
Last post by Patrick M. Hausen - December 12, 2025, 10:37:12 PM
Please show both rules in their entirety.
#10
Virtual private networks / Re: OPNsense 25.7.9 | OpenVPN ...
Last post by glgontijo - December 12, 2025, 10:23:42 PM
Just to update.
I've found this to be a specific behavior of NetworkManager.

How to solve:
In NetworkManager, within the imported connection, IPV4 tab > Routes, select the "Ignore routes obtained automatically" option. So the connection will only create the route to the VPN IP subnet. No default routes.
It is also possible to use another OpenVPN client, in case I tested with "OpenVPN Gui Connect" successfully, without having to ignore routes.

On Windows systems, you are not expected to have errors. But I'll still test. If you have a problem, I'll report it here.

I appreciate the space and then leave the resolution.

***
Sorry for poor translation