1
General Discussion / Re: Unofficial OPNSense Discord - Link
« on: May 03, 2024, 10:25:38 am »
Great initiative, and I see that a whole bunch has already started to join 
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.
Pages: [1]
2
General Discussion / Re: OPNsense Discord
« on: April 07, 2024, 08:51:18 pm »[...] Who do you want to interrupt for random discussions [...]
Did I come off as looking to interrupt someone? Then something got lost in translation, or we have different experience and expectation to instant messaging. I'm talking about 'chat rooms' (like forum sections) and not private/direct messages. If you feel interrupted, then there are some great privacy and notification settings.
[...] and why do you think it's a productive solution?
Productivity isn't necessarily the aim; instead, foster a communications channel for like-minded (OPNsense community members) that necessarily don't think a forum is the primary means of communication for all subjects and/or is not looking to be productive, or actually to be productive.
It's not like SMF screams productivity compared to alternative forums, just like IRC not screams productivity compared to Discord or Slack.
3
General Discussion / Re: OPNsense Discord
« on: April 04, 2024, 06:18:35 pm »[...] since the business model exists and impromptu scenrario is not part of it unless you pay lots of mooolas.Not sure I follow. Can you elaborate?
[...] discord is fun place to hang out with folks and chat...This would be my idea of said server, where "impromptu and random discussions, and generally connecting with community members" would be "Hang out with folks and chat".
4
General Discussion / Re: OPNsense Discord
« on: April 04, 2024, 02:12:09 pm »
My preference would be to have a Discord server for impromptu and random discussions, and generally connecting with community members through instant messaging. I'm not overly excited about returning to IRC for that purpose.
Expectations of immediate answers to questions should be ignored, as people need to understand that the vast majority of the community as a whole are operating on a best-effort capacity. The 'real' discussions should still be deferred to the official forums imo.
If the OPNsense team or maintainers have no objections to this proposal, I would be happy to setup, maintain and moderate such a (unofficial) server. If it proves to be beneficial, it wouldn't be a large leap to transfer ownership and make it official. However, if it causes divisions within the community, I would restrict everything to read-only and, once again, deferred to the official forums.
Expectations of immediate answers to questions should be ignored, as people need to understand that the vast majority of the community as a whole are operating on a best-effort capacity. The 'real' discussions should still be deferred to the official forums imo.
If the OPNsense team or maintainers have no objections to this proposal, I would be happy to setup, maintain and moderate such a (unofficial) server. If it proves to be beneficial, it wouldn't be a large leap to transfer ownership and make it official. However, if it causes divisions within the community, I would restrict everything to read-only and, once again, deferred to the official forums.
5
General Discussion / Re: Terminate state on gateway change
« on: December 05, 2023, 03:31:35 pm »
Bump. If there's any part of my explanation that seems unclear, let me know, and I'll try to express it differently. Thanks again!
6
General Discussion / Terminate state on gateway change
« on: November 22, 2023, 04:11:14 pm »
Hello everyone,
I'm currently dealing with a setup involving two gateways: the primary gateway (WAN1) is a wired unmetered connection, while the secondary gateway (WAN2) is a metered LTE connection. The failover to the LTE connection works seamlessly when the primary gateway (WAN1) goes down, but I'm facing a specific challenge.
The issue I'm encountering is that persistent connections (SSH, RDP, etc.) continue to use WAN2 even after the primary gateway is restored following a period of downtime. This results in unnecessary latency and, naturally, unwarranted traffic on the metered connection.
I'm wondering if there's a method to terminate states associated with a specific WAN interface when an active gateway changes. Essentially, I'm seeking a way to terminate WAN2 states when WAN1 becomes active. Alternatively, I'm open to discovering a more graceful approach to dropping secondary connections, prompting clients to reconnect/reestablish with the now active WAN1.
Any insights or suggestions on how to address this would be greatly appreciated.
Thanks!
I'm currently dealing with a setup involving two gateways: the primary gateway (WAN1) is a wired unmetered connection, while the secondary gateway (WAN2) is a metered LTE connection. The failover to the LTE connection works seamlessly when the primary gateway (WAN1) goes down, but I'm facing a specific challenge.
The issue I'm encountering is that persistent connections (SSH, RDP, etc.) continue to use WAN2 even after the primary gateway is restored following a period of downtime. This results in unnecessary latency and, naturally, unwarranted traffic on the metered connection.
I'm wondering if there's a method to terminate states associated with a specific WAN interface when an active gateway changes. Essentially, I'm seeking a way to terminate WAN2 states when WAN1 becomes active. Alternatively, I'm open to discovering a more graceful approach to dropping secondary connections, prompting clients to reconnect/reestablish with the now active WAN1.
Any insights or suggestions on how to address this would be greatly appreciated.
Thanks!
Pages: [1]