1
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
2
General Discussion / Re: Why can't I install plugins when there is an update available?
« on: June 12, 2024, 07:55:45 pm »
Thanks. Very helpful!
I had to tweak it a bit. The actual one is
I had to tweak it a bit. The actual one is
Code: [Select]
24.1/MINT/24.1.8/latestso then it can find the meta.txz file properly
3
General Discussion / Re: Why can't I install plugins when there is an update available?
« on: June 12, 2024, 07:36:33 pm »thanks for confirming the flavour is the way to go to install other version.
What's the actual syntax to use in the Settings? I don't see any documentation.
Trying the URL "https://pkg.opnsense.org/FreeBSD:13:amd64/24.1/MINT/24.1.8/" or "FreeBSD:13:amd64/24.1/MINT/24.1.8" didn't work.
4
General Discussion / Re: Why can't I install plugins when there is an update available?
« on: June 11, 2024, 08:43:33 pm »
I was actually wondering if it was not the behavior in the past, or at least that it was possible to install the right version of the plugin for the currently installed version of opnsense.
That requirement of being on the exact same minor version of opnsense is definitely cumbersome.
I was expecting that a minor version bump shouldn't be required since it's usually for security and bug fixes and not new features. For instance I have 24.1.6 running now and can't installed ddclient without installing 24.1.8 and rebooting.
It's not a big deal at home, I will just have to find a time when my teenager will be ok losing the internet for 5 minutes
But in an enterprise setup, you would definitely need a HA setup to avoid a downtime.
Unless there is a way to force the installation of a previous version? Is that what the flavour settings is for?
That requirement of being on the exact same minor version of opnsense is definitely cumbersome.
I was expecting that a minor version bump shouldn't be required since it's usually for security and bug fixes and not new features. For instance I have 24.1.6 running now and can't installed ddclient without installing 24.1.8 and rebooting.
It's not a big deal at home, I will just have to find a time when my teenager will be ok losing the internet for 5 minutes
But in an enterprise setup, you would definitely need a HA setup to avoid a downtime.
Unless there is a way to force the installation of a previous version? Is that what the flavour settings is for?
5
Hardware and Performance / Re: Topton N5105 based system
« on: March 11, 2024, 05:56:16 pm »
Forgot to answer... sorry.
so just for info, the issue was a mix of the user (me) and opnsense drivers (I guess).
The interfaces show up in a different order if I remember correctly.
so just for info, the issue was a mix of the user (me) and opnsense drivers (I guess).
The interfaces show up in a different order if I remember correctly.
6
General Discussion / Re: example of how you use Categories
« on: March 11, 2024, 05:51:03 pm »
Thanks all for sharing.
7
General Discussion / example of how you use Categories
« on: March 04, 2024, 11:21:25 pm »
HI,
I've never used Categories before and would like to see how people use those in their aliases and firewall rules.
It is probably very personal how you put things under different categories and even the color choices
Getting some ideas would be helpful to avoid me to change those too often at the beginning while I make up my mind...
Thanks for any input.
I've never used Categories before and would like to see how people use those in their aliases and firewall rules.
It is probably very personal how you put things under different categories and even the color choices
Getting some ideas would be helpful to avoid me to change those too often at the beginning while I make up my mind...
Thanks for any input.
8
Virtual private networks / Wireguard over 2 WAN connections for failover
« on: January 31, 2024, 07:59:22 pm »
Hello,
I am looking into replacing our IPSec VPN to Google Cloud with Wireguard. The reason is that we are running into reliability issues with our primary ISP. I want a failover solution for specific workload that spans over on-premise and the cloud. We have a 4G connection that doesn't provide static IPs, so IPSec can't be used (AFAIK).
The use case is the following:
- use 2 WAN connections, one over Fiber (primary) and one on 4G/LTE (secondary)
- 2 Wireguard tunnels one on each connection
- Wireguard server in a VM in GCP
- prefer to use static routing, but ok with using BGP if required
I know it's feasible.
I am looking for opinions and ideas on what can be the differet approaches for:
- handling the failover on the on-premise side in OPNSense
- handling the failover on the GCP side.
on OPNsense, I would use a gateway group including the 2 wireguard gateways.
on the GCP side, I looked into using Linux with wireguard. I am not completely clear yet on how to configure the failover though (at layer 2 or 3, bgp or not?). It seems it would have to be done with BGP because the bonding of the wireguard interfaces would not consider the daughter interface down when the connection is down. I haven't tested this yet, not sure...
I am considering using OPNsense also in GCP to handle the failover the same way as on-premise with a gateway group. Or do I have to use BGP to update the routes too there? Any experience using OPNsense in a VM on GCP?
Thanks for any input.
I am looking into replacing our IPSec VPN to Google Cloud with Wireguard. The reason is that we are running into reliability issues with our primary ISP. I want a failover solution for specific workload that spans over on-premise and the cloud. We have a 4G connection that doesn't provide static IPs, so IPSec can't be used (AFAIK).
The use case is the following:
- use 2 WAN connections, one over Fiber (primary) and one on 4G/LTE (secondary)
- 2 Wireguard tunnels one on each connection
- Wireguard server in a VM in GCP
- prefer to use static routing, but ok with using BGP if required
I know it's feasible.
I am looking for opinions and ideas on what can be the differet approaches for:
- handling the failover on the on-premise side in OPNSense
- handling the failover on the GCP side.
on OPNsense, I would use a gateway group including the 2 wireguard gateways.
on the GCP side, I looked into using Linux with wireguard. I am not completely clear yet on how to configure the failover though (at layer 2 or 3, bgp or not?). It seems it would have to be done with BGP because the bonding of the wireguard interfaces would not consider the daughter interface down when the connection is down. I haven't tested this yet, not sure...
I am considering using OPNsense also in GCP to handle the failover the same way as on-premise with a gateway group. Or do I have to use BGP to update the routes too there? Any experience using OPNsense in a VM on GCP?
Thanks for any input.
9
General Discussion / Re: Apply changes, but where is the revert changes?
« on: January 31, 2024, 06:49:00 pm »
thanks for the implementation details!
Makes total sense that each module handles how it is reconfigured.
Maybe having a "To be applied" summary on a dedicated screen or the dashboard could be an option?
It would list which modules/namespaces have pending applies and if possible also the actual changes.
Regarding the config.xml file, can't there be a concept of a temporary config.xml.new?
It makes me think of how proxmox deals with pending network interfaces configuration with a .new file that is used to generate the diff in the UI, and then gets swapped on Apply and ifreload is called accordingly.
Makes total sense that each module handles how it is reconfigured.
Maybe having a "To be applied" summary on a dedicated screen or the dashboard could be an option?
It would list which modules/namespaces have pending applies and if possible also the actual changes.
Regarding the config.xml file, can't there be a concept of a temporary config.xml.new?
It makes me think of how proxmox deals with pending network interfaces configuration with a .new file that is used to generate the diff in the UI, and then gets swapped on Apply and ifreload is called accordingly.
10
23.7 Legacy Series / Vlan naming inconsistency between Console and GUI.
« on: January 29, 2024, 06:48:46 pm »
Hi,
I've noticed that when using the text console to create vlan interfaces, it uses the "old" convention of interfacename_vlanXXX and it can't be set by the user, while the GUI is using the newer version of vlanXX.X.XX by default that's meant to be compatible with QinQ, and gives the impression the old convention is not a thing anymore (even if the code still allows it under the hood).
I tested that in 23.7.12 and it's still happening.
That's the line in the code responsible for this.
https://github.com/opnsense/core/blob/9f8a23a1daf5ad58f2cb7489834c1ed73837229b/src/etc/inc/console.inc#L645
I would have to understand better the PHP code to see if other functions in the Vlan.php code could be reused here, but it seems the code is meant for the GUI and not the text UI.
Like this one for instance https://github.com/opnsense/core/blob/9f8a23a1daf5ad58f2cb7489834c1ed73837229b/src/opnsense/mvc/app/models/OPNsense/Interfaces/Vlan.php#L40
There is nothing blocking the user to use the old convention in the GUI.
It's done here : https://github.com/opnsense/core/blob/9f8a23a1daf5ad58f2cb7489834c1ed73837229b/src/opnsense/mvc/app/models/OPNsense/Interfaces/Vlan.php#L63
But it's not stated anywhere in the GUI/help, and that's why I personally feel like it leads to inconsistency if you end up creating vlans in both the text console and GUI.
I may be an outlier here requiring to set vlan interfaces right away in the text console during the installation, otherwise I can't access the GUI because of the way our physical interfaces are set.
Furthermore, looking at the code, I find that the real prefix enforced is not vlan or qinq, but vlan0 or qinq0 (which makes total sense to look like other interfaces).
I believe the expected naming scheme is vlan0.XXXX or vlan0.XXXX.XXXX and qinq.XXXX.XXXX
Is that right?
the GUI error message when using the wrong name doesn't include the 0, which is misleading.
I've seen our routers ended up being configured with interfaces names vlan01, vlan02 or vlan0.1.100 (with 1 being meaningless in our case), because people misunderstood naming scheme.
I don't have a perfect solution for this.
- Adding more explicit documentation in the UI would be helpful.
- Enforcing more strict validation of names in the GUI would be nice with the risk though to break compatibility with existing deployments that didn't follow the format perfectly. I have some more fancy regex/if-else causes that I am testing if interested.
- Making the Console and GUI behave the same would be nice too, by offering the option to type a custom name, and use the default old format if none is provided.
It's all for discussion more than an actual feature request. I am now aware of the behavior, so I understand what to do. Just had to go deeper than expected to understand
I've noticed that when using the text console to create vlan interfaces, it uses the "old" convention of interfacename_vlanXXX and it can't be set by the user, while the GUI is using the newer version of vlanXX.X.XX by default that's meant to be compatible with QinQ, and gives the impression the old convention is not a thing anymore (even if the code still allows it under the hood).
I tested that in 23.7.12 and it's still happening.
That's the line in the code responsible for this.
https://github.com/opnsense/core/blob/9f8a23a1daf5ad58f2cb7489834c1ed73837229b/src/etc/inc/console.inc#L645
I would have to understand better the PHP code to see if other functions in the Vlan.php code could be reused here, but it seems the code is meant for the GUI and not the text UI.
Like this one for instance https://github.com/opnsense/core/blob/9f8a23a1daf5ad58f2cb7489834c1ed73837229b/src/opnsense/mvc/app/models/OPNsense/Interfaces/Vlan.php#L40
There is nothing blocking the user to use the old convention in the GUI.
It's done here : https://github.com/opnsense/core/blob/9f8a23a1daf5ad58f2cb7489834c1ed73837229b/src/opnsense/mvc/app/models/OPNsense/Interfaces/Vlan.php#L63
But it's not stated anywhere in the GUI/help, and that's why I personally feel like it leads to inconsistency if you end up creating vlans in both the text console and GUI.
I may be an outlier here requiring to set vlan interfaces right away in the text console during the installation, otherwise I can't access the GUI because of the way our physical interfaces are set.
Furthermore, looking at the code, I find that the real prefix enforced is not vlan or qinq, but vlan0 or qinq0 (which makes total sense to look like other interfaces).
I believe the expected naming scheme is vlan0.XXXX or vlan0.XXXX.XXXX and qinq.XXXX.XXXX
Is that right?
the GUI error message when using the wrong name doesn't include the 0, which is misleading.
I've seen our routers ended up being configured with interfaces names vlan01, vlan02 or vlan0.1.100 (with 1 being meaningless in our case), because people misunderstood naming scheme.
I don't have a perfect solution for this.
- Adding more explicit documentation in the UI would be helpful.
- Enforcing more strict validation of names in the GUI would be nice with the risk though to break compatibility with existing deployments that didn't follow the format perfectly. I have some more fancy regex/if-else causes that I am testing if interested.
- Making the Console and GUI behave the same would be nice too, by offering the option to type a custom name, and use the default old format if none is provided.
It's all for discussion more than an actual feature request. I am now aware of the behavior, so I understand what to do. Just had to go deeper than expected to understand
11
General Discussion / Re: Apply changes, but where is the revert changes?
« on: December 16, 2023, 01:12:58 am »
Oh I would love a Cancel feature before an Apply too.
That would be handy indeed for mistakes, or when somebody else on the team left something in the middle of being configured...
I sometimes sweat bullets when pressing that Apply (Nuke) button being blind.
Seeing what the apply is going to do is also something that would be useful.
(seeing the diff before it's applied for instance).
Same concept as the git stage/commit basically:
- see the diff
- can rollback the commit before the push
That would be handy indeed for mistakes, or when somebody else on the team left something in the middle of being configured...
I sometimes sweat bullets when pressing that Apply (Nuke) button being blind
.Seeing what the apply is going to do is also something that would be useful.
(seeing the diff before it's applied for instance).
Same concept as the git stage/commit basically:
- see the diff
- can rollback the commit before the push
12
High availability / Re: Second WAN but just for some devices
« on: April 12, 2023, 08:55:08 pm »
thanks for all those details.
I don't use policy routing yet, still have a basic one WAN link.
Thanks for the reminder to consider it.
I don't use policy routing yet, still have a basic one WAN link.
Thanks for the reminder to consider it.
13
High availability / Second WAN but just for some devices
« on: April 10, 2023, 07:27:18 pm »
Hello,
I am looking at adding a second WAN connection on our OPNSense router, using 4G LTE.
It is just for emergency use when power is down, to send metrics and alerts for a few minutes to our cloud based alerting system.
I would like this link to be only useable:
- when the main link is down (so failover mode)
- only by some devices on the network (don't want to overload the small uplink with traffic from some devices that are also still running on batteries during an outage).
The failover I believe is straight forward, following the documentation.
For the second requirement, is it just a list of firewall/routing rules or there is more to it?
I've never used 4G LTE as a WAN on a router. Not sure of how static is the gateway/route setup on those.
The plan would come from T-Mobile, AT&T or Verizon in the US.
Thanks for any insights you can share.
I am looking at adding a second WAN connection on our OPNSense router, using 4G LTE.
It is just for emergency use when power is down, to send metrics and alerts for a few minutes to our cloud based alerting system.
I would like this link to be only useable:
- when the main link is down (so failover mode)
- only by some devices on the network (don't want to overload the small uplink with traffic from some devices that are also still running on batteries during an outage).
The failover I believe is straight forward, following the documentation.
For the second requirement, is it just a list of firewall/routing rules or there is more to it?
I've never used 4G LTE as a WAN on a router. Not sure of how static is the gateway/route setup on those.
The plan would come from T-Mobile, AT&T or Verizon in the US.
Thanks for any insights you can share.
14
General Discussion / Re: Authentication LDAP
« on: March 23, 2023, 05:21:57 pm »
I reply here. Hopefully it doesn't create too much noise since it's still LDAP related.
I successfully made OPNSense talk to Google Secure LDAP for authentication of OPNSense UI users via a local auth server, OpenVPN users via the same local auth server, but not for 802.1x authentication via Radius for a Unifi Wifi network.
The idea is to:
- activate LDAP App in Google Workspace. Create a certificate and credentials.
- create a stunnel between OPNSense to Google to secure the communication to their LDAP service. You have to install the optional stunnel plugin for that on OPNSense. The tunnel will port forward a local port to Google. ex: port 1636. You will need the certificate you create on Google for that. Ad this certificate in the OPNSense Trust/Certificates.
- create a LDAP auth server using that stunnel-ed port forward. so 127.0.0.1:1636. You provide all the credentials you create/get from google here. As well as all the LDAP DN etc...
- use that auth server in your VPN and User authentication setup
For Radius, it didn't work for me so far (if you know how to do it let me know...)
- set LDAP in Radius to inner-tunnel mode
- entered all the Google credentials etc... (It connects fine to Google LDAP in the logs)
- enabled LDAP in the Radius General settings
- Use Radius on our Wifi (it works fine with the local radius user on OPNSense)
- I see OPNSense getting the credentials from the wifi but rejecting them
I hope it helps.
Note that LDAP doesn't use any second factor (2FA) in that case. Only the main password was needed to be sent to Google in my tests, even when 2FA was forced on all user accounts in Google Workspace. I believe it's a known limitation of Secure LDAP on Google.
I successfully made OPNSense talk to Google Secure LDAP for authentication of OPNSense UI users via a local auth server, OpenVPN users via the same local auth server, but not for 802.1x authentication via Radius for a Unifi Wifi network.
The idea is to:
- activate LDAP App in Google Workspace. Create a certificate and credentials.
- create a stunnel between OPNSense to Google to secure the communication to their LDAP service. You have to install the optional stunnel plugin for that on OPNSense. The tunnel will port forward a local port to Google. ex: port 1636. You will need the certificate you create on Google for that. Ad this certificate in the OPNSense Trust/Certificates.
- create a LDAP auth server using that stunnel-ed port forward. so 127.0.0.1:1636. You provide all the credentials you create/get from google here. As well as all the LDAP DN etc...
- use that auth server in your VPN and User authentication setup
For Radius, it didn't work for me so far (if you know how to do it let me know...)
- set LDAP in Radius to inner-tunnel mode
- entered all the Google credentials etc... (It connects fine to Google LDAP in the logs)
- enabled LDAP in the Radius General settings
- Use Radius on our Wifi (it works fine with the local radius user on OPNSense)
- I see OPNSense getting the credentials from the wifi but rejecting them
I hope it helps.
Note that LDAP doesn't use any second factor (2FA) in that case. Only the main password was needed to be sent to Google in my tests, even when 2FA was forced on all user accounts in Google Workspace. I believe it's a known limitation of Secure LDAP on Google.
15
22.7 Legacy Series / IPSec tunnel not surviving a reboot nor a network restart
« on: March 23, 2023, 05:02:40 pm »
Hello,
I run the latest version of 22.7 but the same problem happened in the recent 22.x versions
I use an IPSec tunnel from OPNSense to Google GCP Cloud VPN.
The setup works fine typically.
It just doesn't survive a reboot of the router. The configuration is still there, the IPSec interface, the gateway, the static route. It says it's up. The packets show up on the IPSec interface via tcpdump. But the packets are actually not sent to GCP at all. They end up in a blackhole somewhere in OPNSense.
The only way I found to fix this is to stop IPSec, delete phase 2 and phase 1 setup, recreate everything.
I don't have to recreate the GCP side at all.
I observed yesterday the same issue but not after a reboot this time but just because we had lost our internet connection for 2h because of the ISP.
I am considering using another IPSec tunnel software instead of OPNSense if it proves it is a known issue that is not fixed in 22.7 or 23.1 But maybe there is some possible tweak that can be done in OPNSense to make it more reliable?
Thanks for any tips you may have
I run the latest version of 22.7 but the same problem happened in the recent 22.x versions
I use an IPSec tunnel from OPNSense to Google GCP Cloud VPN.
The setup works fine typically.
It just doesn't survive a reboot of the router. The configuration is still there, the IPSec interface, the gateway, the static route. It says it's up. The packets show up on the IPSec interface via tcpdump. But the packets are actually not sent to GCP at all. They end up in a blackhole somewhere in OPNSense.
The only way I found to fix this is to stop IPSec, delete phase 2 and phase 1 setup, recreate everything.
I don't have to recreate the GCP side at all.
I observed yesterday the same issue but not after a reboot this time but just because we had lost our internet connection for 2h because of the ISP.
I am considering using another IPSec tunnel software instead of OPNSense if it proves it is a known issue that is not fixed in 22.7 or 23.1 But maybe there is some possible tweak that can be done in OPNSense to make it more reliable?
Thanks for any tips you may have
Pages: [1] 2