Menu
▾
▴
astlinux-devel — The AstLinux development environment, compilation, etc
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(41) |
Apr
(35) |
May
(18) |
Jun
(5) |
Jul
(4) |
Aug
(37) |
Sep
(9) |
Oct
(20) |
Nov
(50) |
Dec
(217) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(212) |
Feb
(76) |
Mar
(113) |
Apr
(88) |
May
(130) |
Jun
(54) |
Jul
(208) |
Aug
(223) |
Sep
(112) |
Oct
(63) |
Nov
(131) |
Dec
(103) |
| 2010 |
Jan
(247) |
Feb
(130) |
Mar
(43) |
Apr
(92) |
May
(40) |
Jun
(43) |
Jul
(43) |
Aug
(80) |
Sep
(44) |
Oct
(74) |
Nov
(21) |
Dec
(46) |
| 2011 |
Jan
(36) |
Feb
(11) |
Mar
(21) |
Apr
(33) |
May
(4) |
Jun
(12) |
Jul
(5) |
Aug
(20) |
Sep
|
Oct
(64) |
Nov
(26) |
Dec
(71) |
| 2012 |
Jan
(13) |
Feb
(24) |
Mar
(11) |
Apr
(2) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(7) |
Sep
(26) |
Oct
(22) |
Nov
(17) |
Dec
(16) |
| 2013 |
Jan
(6) |
Feb
(6) |
Mar
(6) |
Apr
(8) |
May
(20) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(18) |
Oct
(3) |
Nov
(14) |
Dec
(33) |
| 2014 |
Jan
(26) |
Feb
(6) |
Mar
(69) |
Apr
(10) |
May
|
Jun
(8) |
Jul
(18) |
Aug
(22) |
Sep
(19) |
Oct
(17) |
Nov
|
Dec
(4) |
| 2015 |
Jan
(14) |
Feb
(18) |
Mar
|
Apr
|
May
(26) |
Jun
(8) |
Jul
(9) |
Aug
(10) |
Sep
(15) |
Oct
(2) |
Nov
(30) |
Dec
(33) |
| 2016 |
Jan
(1) |
Feb
(24) |
Mar
(19) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(20) |
Oct
(5) |
Nov
(14) |
Dec
(4) |
| 2017 |
Jan
(15) |
Feb
(35) |
Mar
(10) |
Apr
(9) |
May
(14) |
Jun
(33) |
Jul
(1) |
Aug
(27) |
Sep
(7) |
Oct
|
Nov
(10) |
Dec
(15) |
| 2018 |
Jan
(29) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(9) |
Dec
(13) |
| 2019 |
Jan
(1) |
Feb
(7) |
Mar
(3) |
Apr
(21) |
May
(34) |
Jun
(36) |
Jul
(18) |
Aug
(17) |
Sep
(19) |
Oct
(8) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(8) |
Apr
(29) |
May
(50) |
Jun
(8) |
Jul
(2) |
Aug
(10) |
Sep
(1) |
Oct
(7) |
Nov
(9) |
Dec
(19) |
| 2021 |
Jan
(2) |
Feb
(9) |
Mar
(6) |
Apr
(21) |
May
(13) |
Jun
(11) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
(26) |
Nov
(2) |
Dec
(16) |
| 2022 |
Jan
(8) |
Feb
(7) |
Mar
(1) |
Apr
(13) |
May
(1) |
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
(2) |
Feb
(3) |
Mar
(16) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(4) |
Aug
(13) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
|
| 2024 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2025 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
(11) |
May
(1) |
Jun
(9) |
Jul
(18) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lonnie A. <li...@lo...> - 2019-10-31 12:22:01
|
Release Candidate2 pre-1.3.7, please report any issues, ASAP. Same as previous "Release Candidate" except for adding a new feature: AstLinux integrated Wiki https://doc.astlinux-project.org/userdoc:tt_web_interface_wiki (Michael Keuter's idea, and he is using it for his customers) ==== The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development https://www.astlinux-project.org/dev.html "Development" tab feature for desktop browsers: Guest VM x86-64bit ISO: Download Pre-Release Guest VM Install ISO (Video Console) AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2019-10-20 02:16:50
|
Release Candidate pre-1.3.7, please report any issues, ASAP.
The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.
-- Linux Kernel 3.16.74 (version bump), security and bug fixes
-- genx86_64-vm board type, version bump VMware Tools to open-vm-tools 10.3.10
-- Asterisk 13.23.1 ('13se' version)
Older than latest Asterisk 13.x version but more tested, built --without-pjproject
Add json-integer-overflow patches.
Add security patches for: AST-2019-002, AST-2019-003
-- Asterisk 13.29.1 (version bump) and 16.6.1 (version bump)
New modules: app_attended_transfer.so, app_blind_transfer.so
-- OpenSSL, major version bump to 1.1.1d, the new LTS series. The previous 1.0.2 LTS series is EOL at the end of 2019.
Many packages needed version bumps or patches to be compatible with the new OpenSSL 1.1 API.
-- acme-client, version 2.8.1, add upstream patch from 2.8.3 to fix (important) Let's Encrypt CDN changes.
-- php, major version bump to 7.2.23, adds OpenSSL 1.1 compatibility
-- Web Interface Edit tab, add support for CodeMirror text editing.
(Tip: Shift-Reload browser to get the updated CSS style sheet)
Keyboard Actions: (after clicking text edit area)
Note: Windows users, use Ctrl instead of Cmd
Cmd-f -> Find
Cmd-g -> Find Next
Cmd-/ -> Toggle Comment
Cmd-. -> Toggle Comment
Tab -> Toggle between "fullscreen" (full-window) mode and normal
Esc -> Return to normal, "fullscreen" (full-window) mode off
More info: https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map
-- Fossil, major version bump to 2.9, adds numerous enhancements to the look and feel of the web interface
-- arnofw (AIF), reload-blocklist-netset cron script, add new netset types
asterisk: Aggregate multiple Asterisk/SIP/VoIP blacklists, including blocklist_de_sip.
custom: Use variable BLOCKLIST_CUSTOM_URLS containing one or more (space/newline separated) URLs.
customv6: Use variable BLOCKLIST_CUSTOMV6_URLS containing one or more (space/newline separated) URLs.
More info: https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists
-- arnofw (AIF), wireguard-vpn plugin, add support for WG->Local TCP/UDP INPUT policy firewall rules.
More info: https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#wireguard_configuration_options
-- iprange, version 1.0.4, new command, a tool capable of managing sets of IPs
-- WireGuard VPN, version bump to 0.0.20191012
-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt
New Documentation Topics:
Edit tab w/CodeMirror Keyboard Mapping -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map
Updated Documentation Topics:
Firewall External Block List -
- https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists
WireGuard VPN Configuration -
- https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#wireguard_configuration_options
WAN Failover -
- https://doc.astlinux-project.org/userdoc:tt_wan_failover#exit_action_script_optional
Web Interface Display Font -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_font
The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...
AstLinux Project -> Development
https://www.astlinux-project.org/dev.html
"Development" tab feature for desktop browsers:
Guest VM x86-64bit ISO: Download Pre-Release Guest VM Install ISO (Video Console)
AstLinux Team
|
|
From: Michael K. <mic...@ip...> - 2019-10-14 03:52:15
|
Cool thanks Lonnie.
I'm looking forward to trying it out.
Regards
Michael Knill
On 14/10/19, 1:01 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
We added support for a /mnt/kd/wan-failover-exit.script exit action script.
Exit Action Script (optional)
https://doc.astlinux-project.org/userdoc:tt_wan_failover#exit_action_script_optional
Note, this was added after the astlinux-1.3-4409-7d861a pre-release image.
Lonnie
> On Oct 4, 2019, at 3:34 PM, Michael Knill <mic...@ip...> wrote:
>
> Replying to my previous post.
> A wan-failover-track.script would also be handy to determine other conditions where you may to want it to return to the primary link e.g. there are calls in progress.
> This isn’t a problem for Wireguard as its usually quick enough to converge to not affect calls but I may be forced to use other VPN protocols which would.
>
> Regards
> Michael Knill
>
> On 28/9/19, 7:23 am, "Michael Knill" <mic...@ip...> wrote:
>
> Thanks Lonnie (I knew who you meant) and David
>
> Lonnie you are correct and I'm afraid that the old, iffy DSL primary links is in fact our new National Broadband Network on our old copper cabling ☹
> Thanks David, you do make some good points. Actually accessing the system is no problems as I use VPN when on failover to access the Astlinux box and I can ping the Primary test IP Address for testing the Primary link.
>
> I'm afraid that something like no ping failures in the last 10 minutes wouldn't really cut it e.g. there are often bursts of packet loss during the day. Maybe in the last 30 minutes but hmm.
> Could there be a separate wan-failover-track.script which is tested prior to switching back to the Primary. If not there, switch back as normal, if result is 0, switch back as normal, if result is 1 then don't switch back for another Secondary delay? This would allow the checking complexity to be abstracted away from the failover code itself.
>
> Regards
> Michael Knill
>
> On 28/9/19, 5:05 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
>
>
>> On Sep 27, 2019, at 1:49 PM, David Kerr <da...@ke...> wrote:
>>
>> I'm sure that you meant to address that to Michael.
>
> Yes ... egg on face :-)
>
> David, (correct this time) you make good points and why I'm dragging my feet a little on this request.
>
> I think Michal Knill has some old, iffy DSL primary links and 4G/LTE is the secondary failover.
>
> Another thought would be an optional "ping over time" test while on secondary to only return when the primary has been clean (like no ping failures in last 10 minutes). Though looking at the code my head hurt thinking about implementing something like this. :-)
>
> Lonnie
>
>>
>> But to add my two cents here... I am very nervous about switching the network over to Secondary/Failover without an automatic mechanism to switch back. It may be fine 99% of the time but what if the secondary link fails? Even if the primary link was working fine, without a way to switch back automatically you could find yourself unable to connect from remote site.
>>
>> • If the secondary link is more reliable than the first, then why not swap them (make EXTIF eth1, EXT2IF eth0)?
>> • If you do want to switch over to Secondary for extended period then you would need some fancy firewall rules to make sure you could still at least login by ssh or get to the web interface from the Primary interface. This is necessary to make sure replies go back to the interface that incoming request arrived on, and not the default route. It is doable but non-trivial. I have implemented something similar to ensure that I can always get to my box over the Secondary link, even if Primary is the default route.
>> • Or, when you switch to Secondary link you move the "do I have internet connection" test from the primary to the secondary... in other words switch back to the primary not when the primary is back up again, but rather when the secondary fails. So the switch to failover is active until such time as the failover fails.
>>
>> David.
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2019-10-14 02:01:24
|
Hi Michael, We added support for a /mnt/kd/wan-failover-exit.script exit action script. Exit Action Script (optional) https://doc.astlinux-project.org/userdoc:tt_wan_failover#exit_action_script_optional Note, this was added after the astlinux-1.3-4409-7d861a pre-release image. Lonnie > On Oct 4, 2019, at 3:34 PM, Michael Knill <mic...@ip...> wrote: > > Replying to my previous post. > A wan-failover-track.script would also be handy to determine other conditions where you may to want it to return to the primary link e.g. there are calls in progress. > This isn’t a problem for Wireguard as its usually quick enough to converge to not affect calls but I may be forced to use other VPN protocols which would. > > Regards > Michael Knill > > On 28/9/19, 7:23 am, "Michael Knill" <mic...@ip...> wrote: > > Thanks Lonnie (I knew who you meant) and David > > Lonnie you are correct and I'm afraid that the old, iffy DSL primary links is in fact our new National Broadband Network on our old copper cabling ☹ > Thanks David, you do make some good points. Actually accessing the system is no problems as I use VPN when on failover to access the Astlinux box and I can ping the Primary test IP Address for testing the Primary link. > > I'm afraid that something like no ping failures in the last 10 minutes wouldn't really cut it e.g. there are often bursts of packet loss during the day. Maybe in the last 30 minutes but hmm. > Could there be a separate wan-failover-track.script which is tested prior to switching back to the Primary. If not there, switch back as normal, if result is 0, switch back as normal, if result is 1 then don't switch back for another Secondary delay? This would allow the checking complexity to be abstracted away from the failover code itself. > > Regards > Michael Knill > > On 28/9/19, 5:05 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > > >> On Sep 27, 2019, at 1:49 PM, David Kerr <da...@ke...> wrote: >> >> I'm sure that you meant to address that to Michael. > > Yes ... egg on face :-) > > David, (correct this time) you make good points and why I'm dragging my feet a little on this request. > > I think Michal Knill has some old, iffy DSL primary links and 4G/LTE is the secondary failover. > > Another thought would be an optional "ping over time" test while on secondary to only return when the primary has been clean (like no ping failures in last 10 minutes). Though looking at the code my head hurt thinking about implementing something like this. :-) > > Lonnie > >> >> But to add my two cents here... I am very nervous about switching the network over to Secondary/Failover without an automatic mechanism to switch back. It may be fine 99% of the time but what if the secondary link fails? Even if the primary link was working fine, without a way to switch back automatically you could find yourself unable to connect from remote site. >> >> • If the secondary link is more reliable than the first, then why not swap them (make EXTIF eth1, EXT2IF eth0)? >> • If you do want to switch over to Secondary for extended period then you would need some fancy firewall rules to make sure you could still at least login by ssh or get to the web interface from the Primary interface. This is necessary to make sure replies go back to the interface that incoming request arrived on, and not the default route. It is doable but non-trivial. I have implemented something similar to ensure that I can always get to my box over the Secondary link, even if Primary is the default route. >> • Or, when you switch to Secondary link you move the "do I have internet connection" test from the primary to the secondary... in other words switch back to the primary not when the primary is back up again, but rather when the secondary fails. So the switch to failover is active until such time as the failover fails. >> >> David. > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2019-10-13 13:33:21
|
Announcing Pre-Release Version: astlinux-1.3-4409-7d861a
Latest Asterisk and WireGuard updates.
Important Fix:
-- acme-client, version 2.8.1, add upstream patch from 2.8.3 to fix Let's Encrypt CDN changes.
The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.
-- Linux Kernel 3.16.74 (version bump), security and bug fixes
-- genx86_64-vm board type, version bump VMware Tools to open-vm-tools 10.3.10
-- Asterisk 13.23.1 ('13se' version)
Older than latest Asterisk 13.x version but more tested, built --without-pjproject
Add json-integer-overflow patches.
Add security patches for: AST-2019-002, AST-2019-003
-- Asterisk 13.29.0 (version bump) and 16.6.0 (version bump)
New modules: app_attended_transfer.so, app_blind_transfer.so
-- OpenSSL, major version bump to 1.1.1d, the new LTS series. The previous 1.0.2 LTS series is EOL at the end of 2019.
Many packages needed version bumps or patches to be compatible with the new OpenSSL 1.1 API.
-- php, major version bump to 7.2.23, adds OpenSSL 1.1 compatibility
-- Web Interface Edit tab, add support for CodeMirror text editing.
(Tip: Shift-Reload browser to get the updated CSS style sheet)
Keyboard Actions: (after clicking text edit area)
Note: Windows users, use Ctrl instead of Cmd
Cmd-f -> Find
Cmd-g -> Find Next
Cmd-/ -> Toggle Comment
Cmd-. -> Toggle Comment
Tab -> Toggle between "fullscreen" (full-window) mode and normal
Esc -> Return to normal, "fullscreen" (full-window) mode off
More info: https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map
-- Fossil, major version bump to 2.9, adds numerous enhancements to the look and feel of the web interface
-- arnofw (AIF), reload-blocklist-netset cron script, add new netset types
asterisk: Aggregate multiple Asterisk/SIP/VoIP blacklists, including blocklist_de_sip.
custom: Use variable BLOCKLIST_CUSTOM_URLS containing one or more (space/newline separated) URLs.
customv6: Use variable BLOCKLIST_CUSTOMV6_URLS containing one or more (space/newline separated) URLs.
More info: https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists
-- arnofw (AIF), wireguard-vpn plugin, add support for WG->Local TCP/UDP INPUT policy firewall rules.
More info: https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#wireguard_configuration_options
-- iprange, version 1.0.4, new command, a tool capable of managing sets of IPs
-- WireGuard VPN, version bump to 0.0.20191012
-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt
New Documentation Topics:
Edit tab w/CodeMirror Keyboard Mapping -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map
Updated Documentation Topics:
Firewall External Block List -
- https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists
WireGuard VPN Configuration -
- https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#wireguard_configuration_options
Web Interface Display Font -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_font
The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...
AstLinux Project -> Development
https://www.astlinux-project.org/dev.html
"Development" tab feature for desktop browsers:
Guest VM x86-64bit ISO: Download Pre-Release Guest VM Install ISO (Video Console)
AstLinux Team
|
|
From: Michael K. <mic...@ip...> - 2019-10-04 20:34:40
|
Replying to my previous post.
A wan-failover-track.script would also be handy to determine other conditions where you may to want it to return to the primary link e.g. there are calls in progress.
This isn’t a problem for Wireguard as its usually quick enough to converge to not affect calls but I may be forced to use other VPN protocols which would.
Regards
Michael Knill
On 28/9/19, 7:23 am, "Michael Knill" <mic...@ip...> wrote:
Thanks Lonnie (I knew who you meant) and David
Lonnie you are correct and I'm afraid that the old, iffy DSL primary links is in fact our new National Broadband Network on our old copper cabling ☹
Thanks David, you do make some good points. Actually accessing the system is no problems as I use VPN when on failover to access the Astlinux box and I can ping the Primary test IP Address for testing the Primary link.
I'm afraid that something like no ping failures in the last 10 minutes wouldn't really cut it e.g. there are often bursts of packet loss during the day. Maybe in the last 30 minutes but hmm.
Could there be a separate wan-failover-track.script which is tested prior to switching back to the Primary. If not there, switch back as normal, if result is 0, switch back as normal, if result is 1 then don't switch back for another Secondary delay? This would allow the checking complexity to be abstracted away from the failover code itself.
Regards
Michael Knill
On 28/9/19, 5:05 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> On Sep 27, 2019, at 1:49 PM, David Kerr <da...@ke...> wrote:
>
> I'm sure that you meant to address that to Michael.
Yes ... egg on face :-)
David, (correct this time) you make good points and why I'm dragging my feet a little on this request.
I think Michal Knill has some old, iffy DSL primary links and 4G/LTE is the secondary failover.
Another thought would be an optional "ping over time" test while on secondary to only return when the primary has been clean (like no ping failures in last 10 minutes). Though looking at the code my head hurt thinking about implementing something like this. :-)
Lonnie
>
> But to add my two cents here... I am very nervous about switching the network over to Secondary/Failover without an automatic mechanism to switch back. It may be fine 99% of the time but what if the secondary link fails? Even if the primary link was working fine, without a way to switch back automatically you could find yourself unable to connect from remote site.
>
> • If the secondary link is more reliable than the first, then why not swap them (make EXTIF eth1, EXT2IF eth0)?
> • If you do want to switch over to Secondary for extended period then you would need some fancy firewall rules to make sure you could still at least login by ssh or get to the web interface from the Primary interface. This is necessary to make sure replies go back to the interface that incoming request arrived on, and not the default route. It is doable but non-trivial. I have implemented something similar to ensure that I can always get to my box over the Secondary link, even if Primary is the default route.
> • Or, when you switch to Secondary link you move the "do I have internet connection" test from the primary to the secondary... in other words switch back to the primary not when the primary is back up again, but rather when the secondary fails. So the switch to failover is active until such time as the failover fails.
>
> David.
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Michael K. <mic...@ip...> - 2019-10-03 20:34:15
|
Thanks Lonnie for your work here.
Regards
Michael Knill
On 4/10/19, 12:09 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Announcing Pre-Release Version: astlinux-1.3-4389-0e0e4a
Important Fix:
-- acme-client, version 2.8.1, add upstream patch from 2.8.3 to fix Let's Encrypt CDN changes.
The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.
-- Linux Kernel 3.16.74 (version bump), security and bug fixes
-- genx86_64-vm board type, version bump VMware Tools to open-vm-tools 10.3.10
-- Asterisk 13.23.1 ('13se' version)
Older than latest Asterisk 13.x version but more tested, built --without-pjproject
Add json-integer-overflow patches.
Add security patches for: AST-2019-002, AST-2019-003
-- Asterisk 13.28.1 (version bump) and 16.5.1 (version bump)
New modules: app_attended_transfer.so, app_blind_transfer.so
-- OpenSSL, major version bump to 1.1.1d, the new LTS series. The previous 1.0.2 LTS series is EOL at the end of 2019.
Many packages needed version bumps or patches to be compatible with the new OpenSSL 1.1 API.
-- php, major version bump to 7.2.23, adds OpenSSL 1.1 compatibility
-- Web Interface Edit tab, add support for CodeMirror text editing.
(Tip: Shift-Reload browser to get the updated CSS style sheet)
Keyboard Actions: (after clicking text edit area)
Note: Windows users, use Ctrl instead of Cmd
Cmd-f -> Find
Cmd-g -> Find Next
Cmd-/ -> Toggle Comment
Cmd-. -> Toggle Comment
Tab -> Toggle between "fullscreen" (full-window) mode and normal
Esc -> Return to normal, "fullscreen" (full-window) mode off
More info: https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map
-- Fossil, major version bump to 2.9, adds numerous enhancements to the look and feel of the web interface
-- arnofw (AIF), reload-blocklist-netset cron script, add new netset types
asterisk: Aggregate multiple Asterisk/SIP/VoIP blacklists, including blocklist_de_sip.
custom: Use variable BLOCKLIST_CUSTOM_URLS containing one or more (space/newline separated) URLs.
customv6: Use variable BLOCKLIST_CUSTOMV6_URLS containing one or more (space/newline separated) URLs.
More info: https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists
-- arnofw (AIF), wireguard-vpn plugin, add support for WG->Local TCP/UDP INPUT policy firewall rules.
More info: https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#wireguard_configuration_options
-- iprange, version 1.0.4, new command, a tool capable of managing sets of IPs
-- WireGuard VPN, version bump to 0.0.20190913
-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt
New Documentation Topics:
Edit tab w/CodeMirror Keyboard Mapping -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map
Updated Documentation Topics:
Firewall External Block List -
- https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists
WireGuard VPN Configuration -
- https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#wireguard_configuration_options
Web Interface Display Font -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_font
The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...
AstLinux Project -> Development
https://www.astlinux-project.org/dev.html
"Development" tab feature for desktop browsers:
Guest VM x86-64bit ISO: Download Pre-Release Guest VM Install ISO (Video Console)
AstLinux Team
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2019-10-03 14:09:07
|
Announcing Pre-Release Version: astlinux-1.3-4389-0e0e4a
Important Fix:
-- acme-client, version 2.8.1, add upstream patch from 2.8.3 to fix Let's Encrypt CDN changes.
The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.
-- Linux Kernel 3.16.74 (version bump), security and bug fixes
-- genx86_64-vm board type, version bump VMware Tools to open-vm-tools 10.3.10
-- Asterisk 13.23.1 ('13se' version)
Older than latest Asterisk 13.x version but more tested, built --without-pjproject
Add json-integer-overflow patches.
Add security patches for: AST-2019-002, AST-2019-003
-- Asterisk 13.28.1 (version bump) and 16.5.1 (version bump)
New modules: app_attended_transfer.so, app_blind_transfer.so
-- OpenSSL, major version bump to 1.1.1d, the new LTS series. The previous 1.0.2 LTS series is EOL at the end of 2019.
Many packages needed version bumps or patches to be compatible with the new OpenSSL 1.1 API.
-- php, major version bump to 7.2.23, adds OpenSSL 1.1 compatibility
-- Web Interface Edit tab, add support for CodeMirror text editing.
(Tip: Shift-Reload browser to get the updated CSS style sheet)
Keyboard Actions: (after clicking text edit area)
Note: Windows users, use Ctrl instead of Cmd
Cmd-f -> Find
Cmd-g -> Find Next
Cmd-/ -> Toggle Comment
Cmd-. -> Toggle Comment
Tab -> Toggle between "fullscreen" (full-window) mode and normal
Esc -> Return to normal, "fullscreen" (full-window) mode off
More info: https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map
-- Fossil, major version bump to 2.9, adds numerous enhancements to the look and feel of the web interface
-- arnofw (AIF), reload-blocklist-netset cron script, add new netset types
asterisk: Aggregate multiple Asterisk/SIP/VoIP blacklists, including blocklist_de_sip.
custom: Use variable BLOCKLIST_CUSTOM_URLS containing one or more (space/newline separated) URLs.
customv6: Use variable BLOCKLIST_CUSTOMV6_URLS containing one or more (space/newline separated) URLs.
More info: https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists
-- arnofw (AIF), wireguard-vpn plugin, add support for WG->Local TCP/UDP INPUT policy firewall rules.
More info: https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#wireguard_configuration_options
-- iprange, version 1.0.4, new command, a tool capable of managing sets of IPs
-- WireGuard VPN, version bump to 0.0.20190913
-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt
New Documentation Topics:
Edit tab w/CodeMirror Keyboard Mapping -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map
Updated Documentation Topics:
Firewall External Block List -
- https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists
WireGuard VPN Configuration -
- https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#wireguard_configuration_options
Web Interface Display Font -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_font
The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...
AstLinux Project -> Development
https://www.astlinux-project.org/dev.html
"Development" tab feature for desktop browsers:
Guest VM x86-64bit ISO: Download Pre-Release Guest VM Install ISO (Video Console)
AstLinux Team
|
|
From: Michael K. <mic...@ip...> - 2019-09-27 21:22:59
|
Thanks Lonnie (I knew who you meant) and David
Lonnie you are correct and I'm afraid that the old, iffy DSL primary links is in fact our new National Broadband Network on our old copper cabling ☹
Thanks David, you do make some good points. Actually accessing the system is no problems as I use VPN when on failover to access the Astlinux box and I can ping the Primary test IP Address for testing the Primary link.
I'm afraid that something like no ping failures in the last 10 minutes wouldn't really cut it e.g. there are often bursts of packet loss during the day. Maybe in the last 30 minutes but hmm.
Could there be a separate wan-failover-track.script which is tested prior to switching back to the Primary. If not there, switch back as normal, if result is 0, switch back as normal, if result is 1 then don't switch back for another Secondary delay? This would allow the checking complexity to be abstracted away from the failover code itself.
Regards
Michael Knill
On 28/9/19, 5:05 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> On Sep 27, 2019, at 1:49 PM, David Kerr <da...@ke...> wrote:
>
> I'm sure that you meant to address that to Michael.
Yes ... egg on face :-)
David, (correct this time) you make good points and why I'm dragging my feet a little on this request.
I think Michal Knill has some old, iffy DSL primary links and 4G/LTE is the secondary failover.
Another thought would be an optional "ping over time" test while on secondary to only return when the primary has been clean (like no ping failures in last 10 minutes). Though looking at the code my head hurt thinking about implementing something like this. :-)
Lonnie
>
> But to add my two cents here... I am very nervous about switching the network over to Secondary/Failover without an automatic mechanism to switch back. It may be fine 99% of the time but what if the secondary link fails? Even if the primary link was working fine, without a way to switch back automatically you could find yourself unable to connect from remote site.
>
> • If the secondary link is more reliable than the first, then why not swap them (make EXTIF eth1, EXT2IF eth0)?
> • If you do want to switch over to Secondary for extended period then you would need some fancy firewall rules to make sure you could still at least login by ssh or get to the web interface from the Primary interface. This is necessary to make sure replies go back to the interface that incoming request arrived on, and not the default route. It is doable but non-trivial. I have implemented something similar to ensure that I can always get to my box over the Secondary link, even if Primary is the default route.
> • Or, when you switch to Secondary link you move the "do I have internet connection" test from the primary to the secondary... in other words switch back to the primary not when the primary is back up again, but rather when the secondary fails. So the switch to failover is active until such time as the failover fails.
>
> David.
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2019-09-27 19:05:41
|
> On Sep 27, 2019, at 1:49 PM, David Kerr <da...@ke...> wrote: > > I'm sure that you meant to address that to Michael. Yes ... egg on face :-) David, (correct this time) you make good points and why I'm dragging my feet a little on this request. I think Michal Knill has some old, iffy DSL primary links and 4G/LTE is the secondary failover. Another thought would be an optional "ping over time" test while on secondary to only return when the primary has been clean (like no ping failures in last 10 minutes). Though looking at the code my head hurt thinking about implementing something like this. :-) Lonnie > > But to add my two cents here... I am very nervous about switching the network over to Secondary/Failover without an automatic mechanism to switch back. It may be fine 99% of the time but what if the secondary link fails? Even if the primary link was working fine, without a way to switch back automatically you could find yourself unable to connect from remote site. > > • If the secondary link is more reliable than the first, then why not swap them (make EXTIF eth1, EXT2IF eth0)? > • If you do want to switch over to Secondary for extended period then you would need some fancy firewall rules to make sure you could still at least login by ssh or get to the web interface from the Primary interface. This is necessary to make sure replies go back to the interface that incoming request arrived on, and not the default route. It is doable but non-trivial. I have implemented something similar to ensure that I can always get to my box over the Secondary link, even if Primary is the default route. > • Or, when you switch to Secondary link you move the "do I have internet connection" test from the primary to the secondary... in other words switch back to the primary not when the primary is back up again, but rather when the secondary fails. So the switch to failover is active until such time as the failover fails. > > David. |
|
From: David K. <da...@ke...> - 2019-09-27 18:49:38
|
I'm sure that you meant to address that to Michael. But to add my two cents here... I am very nervous about switching the network over to Secondary/Failover without an automatic mechanism to switch back. It may be fine 99% of the time but what if the secondary link fails? Even if the primary link was working fine, without a way to switch back automatically you could find yourself unable to connect from remote site. - If the secondary link is more reliable than the first, then why not swap them (make EXTIF eth1, EXT2IF eth0)? - If you do want to switch over to Secondary for extended period then you would need some fancy firewall rules to make sure you could still at least login by ssh or get to the web interface from the Primary interface. This is necessary to make sure replies go back to the interface that incoming request arrived on, and not the default route. It is doable but non-trivial. I have implemented something similar to ensure that I can always get to my box over the Secondary link, even if Primary is the default route. - Or, when you switch to Secondary link you move the "do I have internet connection" test from the primary to the secondary... in other words switch back to the primary not when the primary is back up again, but rather when the secondary fails. So the switch to failover is active until such time as the failover fails. David. On Fri, Sep 27, 2019 at 8:52 AM Lonnie Abelbeck <li...@lo...> wrote: > Hi David, comments inline... > > > On Sep 26, 2019, at 10:21 PM, Michael Knill < > mic...@ip...> wrote: > > > > Could we have a checkbox on the failover tab with something like 'Force > Failover to Secondary' and a button to trigger it. > > In failover mode, this parameter could be checked and so the secondary > does not fail back. > > To return to Primary you uncheck the parameter and trigger again. > > What do you think? > > The hardest question is how to implement a "force" failover feature in the > main /usr/sbin/wan-failover script and not cause any unwanted side-effects. > > Setting "Target IPv4 Hosts:" to a known address that does not respond to > ping (apply with Restart Failover) should be a way to force failover. > > I'm wondering how common a force failover would be needed for the user > base. > > > > I could possibly also do this myself in the wan-failover.script I > suspect. > > No, the wan-failover.script can't do that, the main /usr/sbin/wan-failover > script would need to be tweaked to support something like this. > > Lonnie > > > > > > Regards > > Michael Knill > > > > On 25/9/19, 1:23 am, "Lonnie Abelbeck" <li...@lo...> > wrote: > > > > > >> On Sep 23, 2019, at 3:18 PM, Michael Knill < > mic...@ip...> wrote: > >> > >> Hi Devs > >> > >> There have been a number of times where I have an intermittently faulty > link and I want to force a WAN Failover and keep it there until the problem > is restored. > >> The service failover test triggers a failover but its not permanent. > >> Any ideas? > > > > Setting Secondary Delay: to a higher number would keep the switchover > to Failover longer. > > > > Unless you are looking for a CLI command like > > -- > > service failover force > > -- > > but somehow this would need to be reset back to primary. And the > secondary link could also fail while the primary is OK again. > > > > Other than setting Secondary Delay: to 30 minutes or so for notably > bad primary links, I'm not not sure of a true answer. > > > > I suppose we could keep track of the time between switches and > increase the effective Secondary Delay if there are a lot of failover > switches, but that can get complicated. > > > > > >> It would also be really nice to be able to change an ‘External Failover > Destination Route’ without having to reboot the system. There have been a > number of times where I have just wanted to move the VoIP traffic over to > the Secondary link. > > > > Currently your best option is to manually define routes using "ip > route add ..." > > > > > >> Thanks all. Failover is great. > > > > Great to hear, I use it all the time but the good news is my primary > link is very robust (knock on wood) and the failover is seldom triggered. > > > > Lonnie > > > > > >> > >> Regards > >> Michael Knill > >> _______________________________________________ > >> Astlinux-devel mailing list > >> Ast...@li... > >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > > > > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > > > > > > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Lonnie A. <li...@lo...> - 2019-09-27 12:52:32
|
Hi David, comments inline... > On Sep 26, 2019, at 10:21 PM, Michael Knill <mic...@ip...> wrote: > > Could we have a checkbox on the failover tab with something like 'Force Failover to Secondary' and a button to trigger it. > In failover mode, this parameter could be checked and so the secondary does not fail back. > To return to Primary you uncheck the parameter and trigger again. > What do you think? The hardest question is how to implement a "force" failover feature in the main /usr/sbin/wan-failover script and not cause any unwanted side-effects. Setting "Target IPv4 Hosts:" to a known address that does not respond to ping (apply with Restart Failover) should be a way to force failover. I'm wondering how common a force failover would be needed for the user base. > I could possibly also do this myself in the wan-failover.script I suspect. No, the wan-failover.script can't do that, the main /usr/sbin/wan-failover script would need to be tweaked to support something like this. Lonnie > > Regards > Michael Knill > > On 25/9/19, 1:23 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > >> On Sep 23, 2019, at 3:18 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi Devs >> >> There have been a number of times where I have an intermittently faulty link and I want to force a WAN Failover and keep it there until the problem is restored. >> The service failover test triggers a failover but its not permanent. >> Any ideas? > > Setting Secondary Delay: to a higher number would keep the switchover to Failover longer. > > Unless you are looking for a CLI command like > -- > service failover force > -- > but somehow this would need to be reset back to primary. And the secondary link could also fail while the primary is OK again. > > Other than setting Secondary Delay: to 30 minutes or so for notably bad primary links, I'm not not sure of a true answer. > > I suppose we could keep track of the time between switches and increase the effective Secondary Delay if there are a lot of failover switches, but that can get complicated. > > >> It would also be really nice to be able to change an ‘External Failover Destination Route’ without having to reboot the system. There have been a number of times where I have just wanted to move the VoIP traffic over to the Secondary link. > > Currently your best option is to manually define routes using "ip route add ..." > > >> Thanks all. Failover is great. > > Great to hear, I use it all the time but the good news is my primary link is very robust (knock on wood) and the failover is seldom triggered. > > Lonnie > > >> >> Regards >> Michael Knill >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2019-09-27 03:22:12
|
Thanks Lonnie for your response.
Could we have a checkbox on the failover tab with something like 'Force Failover to Secondary' and a button to trigger it.
In failover mode, this parameter could be checked and so the secondary does not fail back.
To return to Primary you uncheck the parameter and trigger again.
What do you think?
I could possibly also do this myself in the wan-failover.script I suspect.
Regards
Michael Knill
On 25/9/19, 1:23 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> On Sep 23, 2019, at 3:18 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Devs
>
> There have been a number of times where I have an intermittently faulty link and I want to force a WAN Failover and keep it there until the problem is restored.
> The service failover test triggers a failover but its not permanent.
> Any ideas?
Setting Secondary Delay: to a higher number would keep the switchover to Failover longer.
Unless you are looking for a CLI command like
--
service failover force
--
but somehow this would need to be reset back to primary. And the secondary link could also fail while the primary is OK again.
Other than setting Secondary Delay: to 30 minutes or so for notably bad primary links, I'm not not sure of a true answer.
I suppose we could keep track of the time between switches and increase the effective Secondary Delay if there are a lot of failover switches, but that can get complicated.
> It would also be really nice to be able to change an ‘External Failover Destination Route’ without having to reboot the system. There have been a number of times where I have just wanted to move the VoIP traffic over to the Secondary link.
Currently your best option is to manually define routes using "ip route add ..."
> Thanks all. Failover is great.
Great to hear, I use it all the time but the good news is my primary link is very robust (knock on wood) and the failover is seldom triggered.
Lonnie
>
> Regards
> Michael Knill
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2019-09-26 18:20:27
|
Announcing Pre-Release Version: astlinux-1.3-4369-fb0226
The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.
-- Linux Kernel 3.16.74 (version bump), security and bug fixes
-- genx86_64-vm board type, version bump VMware Tools to open-vm-tools 10.3.10
-- Asterisk 13.23.1 ('13se' version)
Older than latest Asterisk 13.x version but more tested, built --without-pjproject
Add json-integer-overflow patches.
Add security patches for: AST-2019-002, AST-2019-003
-- Asterisk 13.28.1 (version bump) and 16.5.1 (version bump)
New modules: app_attended_transfer.so, app_blind_transfer.so
-- OpenSSL, major version bump to 1.1.1d, the new LTS series. The previous 1.0.2 LTS series is EOL at the end of 2019.
Many packages needed version bumps or patches to be compatible with the new OpenSSL 1.1 API.
-- php, major version bump to 7.2.22, adds OpenSSL 1.1 compatibility
-- Web Interface Edit tab, add support for CodeMirror text editing.
(Tip: Shift-Reload browser to get the updated CSS style sheet)
Keyboard Actions: (after clicking text edit area)
Note: Windows users, use Ctrl instead of Cmd
Cmd-f -> Find
Cmd-g -> Find Next
Cmd-/ -> Toggle Comment
Cmd-. -> Toggle Comment
Tab -> Toggle between "fullscreen" (full-window) mode and normal
Esc -> Return to normal, "fullscreen" (full-window) mode off
More info: https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map
-- Fossil, major version bump to 2.9, adds numerous enhancements to the look and feel of the web interface
-- arnofw (AIF), reload-blocklist-netset cron script, add new netset types
asterisk: Aggregate multiple Asterisk/SIP/VoIP blacklists, including blocklist_de_sip.
custom: Use variable BLOCKLIST_CUSTOM_URLS containing one or more (space/newline separated) URLs.
customv6: Use variable BLOCKLIST_CUSTOMV6_URLS containing one or more (space/newline separated) URLs.
More info: https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists
-- arnofw (AIF), wireguard-vpn plugin, add support for WG->Local TCP/UDP INPUT policy firewall rules.
More info: https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#wireguard_configuration_options
-- iprange, version 1.0.4, new command, a tool capable of managing sets of IPs
-- WireGuard VPN, version bump to 0.0.20190913
-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt
New Documentation Topics:
Edit tab w/CodeMirror Keyboard Mapping -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_edit_codemirror_key_map
Updated Documentation Topics:
Firewall External Block List -
- https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists
WireGuard VPN Configuration -
- https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#wireguard_configuration_options
Web Interface Display Font -
- https://doc.astlinux-project.org/userdoc:tt_web_interface_font
The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...
AstLinux Project -> Development
https://www.astlinux-project.org/dev.html
"Development" tab feature for desktop browsers:
Guest VM x86-64bit ISO: Download Pre-Release Guest VM Install ISO (Video Console)
AstLinux Team
|
|
From: Lonnie A. <li...@lo...> - 2019-09-24 15:22:55
|
> On Sep 23, 2019, at 3:18 PM, Michael Knill <mic...@ip...> wrote: > > Hi Devs > > There have been a number of times where I have an intermittently faulty link and I want to force a WAN Failover and keep it there until the problem is restored. > The service failover test triggers a failover but its not permanent. > Any ideas? Setting Secondary Delay: to a higher number would keep the switchover to Failover longer. Unless you are looking for a CLI command like -- service failover force -- but somehow this would need to be reset back to primary. And the secondary link could also fail while the primary is OK again. Other than setting Secondary Delay: to 30 minutes or so for notably bad primary links, I'm not not sure of a true answer. I suppose we could keep track of the time between switches and increase the effective Secondary Delay if there are a lot of failover switches, but that can get complicated. > It would also be really nice to be able to change an ‘External Failover Destination Route’ without having to reboot the system. There have been a number of times where I have just wanted to move the VoIP traffic over to the Secondary link. Currently your best option is to manually define routes using "ip route add ..." > Thanks all. Failover is great. Great to hear, I use it all the time but the good news is my primary link is very robust (knock on wood) and the failover is seldom triggered. Lonnie > > Regards > Michael Knill > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2019-09-23 20:18:19
|
Hi Devs There have been a number of times where I have an intermittently faulty link and I want to force a WAN Failover and keep it there until the problem is restored. The service failover test triggers a failover but its not permanent. Any ideas? It would also be really nice to be able to change an ‘External Failover Destination Route’ without having to reboot the system. There have been a number of times where I have just wanted to move the VoIP traffic over to the Secondary link. Thanks all. Failover is great. Regards Michael Knill |
|
From: Michael K. <mic...@ip...> - 2019-09-22 21:00:02
|
Good call!
Regards
Michael Knill
On 23/9/19, 1:58 am, "Lonnie Abelbeck" <li...@lo...> wrote:
BTW, I tweaked the example docs to include allowing DNS for [Pass WG->Local] rules.
https://github.com/astlinux-project/astlinux/commit/d7d8c2fabb3cc16f029f6f85df085fcc444eb9be
It is very common you want to pass/encrypt DNS via the WireGuard tunnel as well as providing local DNS for your WireGuard "cloud".
Lonnie
> On Sep 19, 2019, at 5:15 PM, Michael Knill <mic...@ip...> wrote:
>
> Awesome. Thank you soooo much
>
> Regards
> Michael Knill
>
> From: Lonnie Abelbeck <li...@lo...>
> Reply to: AstLinux Developers Mailing List <ast...@li...>
> Date: Friday, 20 September 2019 at 5:37 am
> To: AstLinux Developers Mailing List <ast...@li...>
> Subject: Re: [Astlinux-devel] Astlinux Firewall
>
>
>
>
>> On Sep 19, 2019, at 3:39 AM, Michael Keuter <li...@mk...> wrote:
>>
>>
>>
>>> Am 18.09.2019 um 12:02 schrieb Michael Keuter <li...@mk...>:
>>>
>>>
>>>>
>>>> Am 18.09.2019 um 00:10 schrieb Lonnie Abelbeck <li...@lo...>:
>>>>
>>>> Michael,
>>>>
>>>> OK, I'll add the new AIF wireguard-vpn plugin config variables outlined below.
>>>>
>>>> Others might find them useful as well.
>>>
>>> Yes, me :-). Your idea looks very promising.
>>
>> Thanks Lonnie for adding this, very useful.
>>
>> Michael
>
> Documented in the WiKi:
>
> https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#wireguard_configuration_options
>
> <image001.png>
>
> Lonnie
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2019-09-22 15:58:14
|
BTW, I tweaked the example docs to include allowing DNS for [Pass WG->Local] rules. https://github.com/astlinux-project/astlinux/commit/d7d8c2fabb3cc16f029f6f85df085fcc444eb9be It is very common you want to pass/encrypt DNS via the WireGuard tunnel as well as providing local DNS for your WireGuard "cloud". Lonnie > On Sep 19, 2019, at 5:15 PM, Michael Knill <mic...@ip...> wrote: > > Awesome. Thank you soooo much > > Regards > Michael Knill > > From: Lonnie Abelbeck <li...@lo...> > Reply to: AstLinux Developers Mailing List <ast...@li...> > Date: Friday, 20 September 2019 at 5:37 am > To: AstLinux Developers Mailing List <ast...@li...> > Subject: Re: [Astlinux-devel] Astlinux Firewall > > > > >> On Sep 19, 2019, at 3:39 AM, Michael Keuter <li...@mk...> wrote: >> >> >> >>> Am 18.09.2019 um 12:02 schrieb Michael Keuter <li...@mk...>: >>> >>> >>>> >>>> Am 18.09.2019 um 00:10 schrieb Lonnie Abelbeck <li...@lo...>: >>>> >>>> Michael, >>>> >>>> OK, I'll add the new AIF wireguard-vpn plugin config variables outlined below. >>>> >>>> Others might find them useful as well. >>> >>> Yes, me :-). Your idea looks very promising. >> >> Thanks Lonnie for adding this, very useful. >> >> Michael > > Documented in the WiKi: > > https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#wireguard_configuration_options > > <image001.png> > > Lonnie > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2019-09-19 22:15:18
|
Awesome. Thank you soooo much Regards Michael Knill From: Lonnie Abelbeck <li...@lo...> Reply to: AstLinux Developers Mailing List <ast...@li...> Date: Friday, 20 September 2019 at 5:37 am To: AstLinux Developers Mailing List <ast...@li...> Subject: Re: [Astlinux-devel] Astlinux Firewall On Sep 19, 2019, at 3:39 AM, Michael Keuter <li...@mk...<mailto:li...@mk...>> wrote: Am 18.09.2019 um 12:02 schrieb Michael Keuter <li...@mk...<mailto:li...@mk...>>: Am 18.09.2019 um 00:10 schrieb Lonnie Abelbeck <li...@lo...<mailto:li...@lo...>>: Michael, OK, I'll add the new AIF wireguard-vpn plugin config variables outlined below. Others might find them useful as well. Yes, me :-). Your idea looks very promising. Thanks Lonnie for adding this, very useful. Michael Documented in the WiKi: https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#wireguard_configuration_options [cid:image001.png@01D56F8B.81B863E0] Lonnie |
|
From: Lonnie A. <li...@lo...> - 2019-09-19 19:36:58
|
> On Sep 19, 2019, at 3:39 AM, Michael Keuter <li...@mk...> wrote: > > >> Am 18.09.2019 um 12:02 schrieb Michael Keuter <li...@mk...>: >> >>> >>> Am 18.09.2019 um 00:10 schrieb Lonnie Abelbeck <li...@lo...>: >>> >>> Michael, >>> >>> OK, I'll add the new AIF wireguard-vpn plugin config variables outlined below. >>> >>> Others might find them useful as well. >> >> Yes, me :-). Your idea looks very promising. > > Thanks Lonnie for adding this, very useful. > > Michael Documented in the WiKi: https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#wireguard_configuration_options Lonnie |
|
From: Michael K. <li...@mk...> - 2019-09-19 08:39:19
|
> Am 18.09.2019 um 12:02 schrieb Michael Keuter <li...@mk...>: > >> >> Am 18.09.2019 um 00:10 schrieb Lonnie Abelbeck <li...@lo...>: >> >> Michael, >> >> OK, I'll add the new AIF wireguard-vpn plugin config variables outlined below. >> >> Others might find them useful as well. > > Yes, me :-). Your idea looks very promising. Thanks Lonnie for adding this, very useful. Michael http://www.mksolutions.info |
|
From: Michael K. <li...@mk...> - 2019-09-18 10:02:56
|
> Am 18.09.2019 um 00:10 schrieb Lonnie Abelbeck <li...@lo...>: > > Michael, > > OK, I'll add the new AIF wireguard-vpn plugin config variables outlined below. > > Others might find them useful as well. Yes, me :-). Your idea looks very promising. > Give me a day or two. > > Lonnie > > > >> On Sep 17, 2019, at 4:56 PM, Michael Knill <mic...@ip...> wrote: >> >> Thanks Lonnie >> >> Yes maybe I am overestimating the complexity and it should be a set and forget in most instances e.g. SSH port, 5060 and RTP ports. >> That being said however, I am certainly interested in your plugin option below as an alternative to custom rules as I begin to use Wireguard more and more often. >> >> Thanks again. >> >> Regards >> Michael Knill >> >> On 18/9/19, 12:04 am, "Lonnie Abelbeck" <li...@lo...> wrote: >> >> Hi Michael, >> >> Thanks for the detailed description. >> >> I think your over estimating the complexity of maintaining iptables custom rules for local WireGuard traffic (per custom_wg_lan_input() in another email). It really is not that difficult considering only a very small subset of iptables syntax is required. >> >> From how I understand your setup, you have a structured WireGuard mesh of clients, which not all should be allowed to access the server's internals within the WireGuard mesh. This is a somewhat unique setup, but possibly will become more common. As such we need to first understand what firewalling is required ... specifically rules limiting local WireGuard traffic. That is why I suggest you start with custom rules to solve your problem, at least at first. >> >> If you find that your custom rules limiting local WireGuard traffic need constant maintenance, note we already have an AIF wireguard-vpn plugin which is automatically enabled and the plugin configuration is passed via the "WireGuard VPN Configuration" sub-tab. The "Firewall Options:" are passed to the wireguard-vpn plugin. >> ... or >> If the uniqueness of this problem does not justify cluttering-up the "WireGuard VPN Configuration", new AIF wireguard-vpn plugin config variable options could be added and edited as how other "Firewall Plugins:" are configured. >> >> Possibly something like: >> -- >> >> # Limit WireGuard WG->Local access >> # >> # Note: The default policy is to allow all WG->Local traffic >> # unless WIREGUARD_VPN_HOST_OPEN_xxx is defined, then >> # the default policy is to deny all WG->Local traffic. >> # >> # Syntax: >> # "host1,host2~port1,port2 host3,host4~port3,port4 ..." >> # >> # Example: (allow SSH traffic, deny all other) >> # WIREGUARD_VPN_HOST_OPEN_TCP="0/0~22" >> # >> # Example: (deny HTTP/HTTPS traffic, allow all other) >> # WIREGUARD_VPN_HOST_DENY_TCP="0/0~80,443" >> # ------------------------------------------------------------------------------ >> WIREGUARD_VPN_HOST_OPEN_TCP="" >> WIREGUARD_VPN_HOST_OPEN_UDP="" >> >> WIREGUARD_VPN_HOST_DENY_TCP="" >> WIREGUARD_VPN_HOST_DENY_UDP="" >> -- >> >> Personally I find using a custom rule just as simple, but that is me. >> >> Lonnie >> >> >>> On Sep 16, 2019, at 6:27 PM, Michael Knill <mic...@ip...> wrote: >>> >>> Hi Devs >>> >>> Just wondering if I could have a bit of a discussion about the Astlinux firewall and the firewall configuration. >>> >>> With the recent increase in hacking attempts that I am seeing on my systems, I'm having to get more serious about security and I'm finding that the firewall tab and resulting iptables rules are not quite as granular as I would like. As I am planning on changing my architecture to being VPN based, this was highlighted recently with the need to add custom rules for VPN’s. >>> >>> Now yes I agree that it would be good to learn iptables and adding custom rules but this will be a considerable learning curve for me and certainly my support staff. >>> >>> So I'm just wondering if there has been or could be a consideration to extend the granularity of the current firewall tab? >>> Here are some of my thoughts: >>> • Could we add an additional Zone called VPN >>> • Could we separate the Rules Action into three parts: Action (NAT, Pass, Deny etc), Source Zone (EXT, LAN, DMZ, VPN) & Destination Zone (EXT, LAN, DMZ, VPN, Local) >>> • Could we pull out some of the Firewall options and create some default Zone to Zone rules >>> • Maybe look at building out the use of netset rules for Geoblocking etc. >>> >>> I'm beginning to have a few partners concerned about the security of Astlinux and its going to be more and more difficult to defend as time goes on. I know that Astlinux has the functionality and tools available to meet most security requirements however they just need to be more accessible to the average network person such as myself. I really don't want to get to the stage where I am putting a firewall in front of the system purely to appease my partners or customers or because its easier. >>> >>> Yes there is probably quite a bit of work here and some big changes but as I have invested heavily into Astlinux being the core of my business, I'm prepared to contribute financially if necessary. >>> >>> I apologise if I have stirred up a hornets nest as it was certainly not my intention. It is the fact that I believe heavily in this product (and so have many of my partners that are now recommending us) that I am looking to the future of where it is heading. >>> >>> I look forward to your comments. >>> >>> Regards >>> Michael Knill Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2019-09-18 00:13:11
|
Cool thanks so much Lonnie. That's going to make things much easier for my brain which is already hurting from all the other things I am doing __
Regards
Michael Knill
On 18/9/19, 8:11 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Michael,
OK, I'll add the new AIF wireguard-vpn plugin config variables outlined below.
Others might find them useful as well.
Give me a day or two.
Lonnie
> On Sep 17, 2019, at 4:56 PM, Michael Knill <mic...@ip...> wrote:
>
> Thanks Lonnie
>
> Yes maybe I am overestimating the complexity and it should be a set and forget in most instances e.g. SSH port, 5060 and RTP ports.
> That being said however, I am certainly interested in your plugin option below as an alternative to custom rules as I begin to use Wireguard more and more often.
>
> Thanks again.
>
> Regards
> Michael Knill
>
> On 18/9/19, 12:04 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Michael,
>
> Thanks for the detailed description.
>
> I think your over estimating the complexity of maintaining iptables custom rules for local WireGuard traffic (per custom_wg_lan_input() in another email). It really is not that difficult considering only a very small subset of iptables syntax is required.
>
> From how I understand your setup, you have a structured WireGuard mesh of clients, which not all should be allowed to access the server's internals within the WireGuard mesh. This is a somewhat unique setup, but possibly will become more common. As such we need to first understand what firewalling is required ... specifically rules limiting local WireGuard traffic. That is why I suggest you start with custom rules to solve your problem, at least at first.
>
> If you find that your custom rules limiting local WireGuard traffic need constant maintenance, note we already have an AIF wireguard-vpn plugin which is automatically enabled and the plugin configuration is passed via the "WireGuard VPN Configuration" sub-tab. The "Firewall Options:" are passed to the wireguard-vpn plugin.
> ... or
> If the uniqueness of this problem does not justify cluttering-up the "WireGuard VPN Configuration", new AIF wireguard-vpn plugin config variable options could be added and edited as how other "Firewall Plugins:" are configured.
>
> Possibly something like:
> --
>
> # Limit WireGuard WG->Local access
> #
> # Note: The default policy is to allow all WG->Local traffic
> # unless WIREGUARD_VPN_HOST_OPEN_xxx is defined, then
> # the default policy is to deny all WG->Local traffic.
> #
> # Syntax:
> # "host1,host2~port1,port2 host3,host4~port3,port4 ..."
> #
> # Example: (allow SSH traffic, deny all other)
> # WIREGUARD_VPN_HOST_OPEN_TCP="0/0~22"
> #
> # Example: (deny HTTP/HTTPS traffic, allow all other)
> # WIREGUARD_VPN_HOST_DENY_TCP="0/0~80,443"
> # ------------------------------------------------------------------------------
> WIREGUARD_VPN_HOST_OPEN_TCP=""
> WIREGUARD_VPN_HOST_OPEN_UDP=""
>
> WIREGUARD_VPN_HOST_DENY_TCP=""
> WIREGUARD_VPN_HOST_DENY_UDP=""
> --
>
> Personally I find using a custom rule just as simple, but that is me.
>
> Lonnie
>
>
>> On Sep 16, 2019, at 6:27 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Hi Devs
>>
>> Just wondering if I could have a bit of a discussion about the Astlinux firewall and the firewall configuration.
>>
>> With the recent increase in hacking attempts that I am seeing on my systems, I'm having to get more serious about security and I'm finding that the firewall tab and resulting iptables rules are not quite as granular as I would like. As I am planning on changing my architecture to being VPN based, this was highlighted recently with the need to add custom rules for VPN’s.
>>
>> Now yes I agree that it would be good to learn iptables and adding custom rules but this will be a considerable learning curve for me and certainly my support staff.
>>
>> So I'm just wondering if there has been or could be a consideration to extend the granularity of the current firewall tab?
>> Here are some of my thoughts:
>> • Could we add an additional Zone called VPN
>> • Could we separate the Rules Action into three parts: Action (NAT, Pass, Deny etc), Source Zone (EXT, LAN, DMZ, VPN) & Destination Zone (EXT, LAN, DMZ, VPN, Local)
>> • Could we pull out some of the Firewall options and create some default Zone to Zone rules
>> • Maybe look at building out the use of netset rules for Geoblocking etc.
>>
>> I'm beginning to have a few partners concerned about the security of Astlinux and its going to be more and more difficult to defend as time goes on. I know that Astlinux has the functionality and tools available to meet most security requirements however they just need to be more accessible to the average network person such as myself. I really don't want to get to the stage where I am putting a firewall in front of the system purely to appease my partners or customers or because its easier.
>>
>> Yes there is probably quite a bit of work here and some big changes but as I have invested heavily into Astlinux being the core of my business, I'm prepared to contribute financially if necessary.
>>
>> I apologise if I have stirred up a hornets nest as it was certainly not my intention. It is the fact that I believe heavily in this product (and so have many of my partners that are now recommending us) that I am looking to the future of where it is heading.
>>
>> I look forward to your comments.
>>
>> Regards
>> Michael Knill
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2019-09-17 22:10:54
|
Michael, OK, I'll add the new AIF wireguard-vpn plugin config variables outlined below. Others might find them useful as well. Give me a day or two. Lonnie > On Sep 17, 2019, at 4:56 PM, Michael Knill <mic...@ip...> wrote: > > Thanks Lonnie > > Yes maybe I am overestimating the complexity and it should be a set and forget in most instances e.g. SSH port, 5060 and RTP ports. > That being said however, I am certainly interested in your plugin option below as an alternative to custom rules as I begin to use Wireguard more and more often. > > Thanks again. > > Regards > Michael Knill > > On 18/9/19, 12:04 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, > > Thanks for the detailed description. > > I think your over estimating the complexity of maintaining iptables custom rules for local WireGuard traffic (per custom_wg_lan_input() in another email). It really is not that difficult considering only a very small subset of iptables syntax is required. > > From how I understand your setup, you have a structured WireGuard mesh of clients, which not all should be allowed to access the server's internals within the WireGuard mesh. This is a somewhat unique setup, but possibly will become more common. As such we need to first understand what firewalling is required ... specifically rules limiting local WireGuard traffic. That is why I suggest you start with custom rules to solve your problem, at least at first. > > If you find that your custom rules limiting local WireGuard traffic need constant maintenance, note we already have an AIF wireguard-vpn plugin which is automatically enabled and the plugin configuration is passed via the "WireGuard VPN Configuration" sub-tab. The "Firewall Options:" are passed to the wireguard-vpn plugin. > ... or > If the uniqueness of this problem does not justify cluttering-up the "WireGuard VPN Configuration", new AIF wireguard-vpn plugin config variable options could be added and edited as how other "Firewall Plugins:" are configured. > > Possibly something like: > -- > > # Limit WireGuard WG->Local access > # > # Note: The default policy is to allow all WG->Local traffic > # unless WIREGUARD_VPN_HOST_OPEN_xxx is defined, then > # the default policy is to deny all WG->Local traffic. > # > # Syntax: > # "host1,host2~port1,port2 host3,host4~port3,port4 ..." > # > # Example: (allow SSH traffic, deny all other) > # WIREGUARD_VPN_HOST_OPEN_TCP="0/0~22" > # > # Example: (deny HTTP/HTTPS traffic, allow all other) > # WIREGUARD_VPN_HOST_DENY_TCP="0/0~80,443" > # ------------------------------------------------------------------------------ > WIREGUARD_VPN_HOST_OPEN_TCP="" > WIREGUARD_VPN_HOST_OPEN_UDP="" > > WIREGUARD_VPN_HOST_DENY_TCP="" > WIREGUARD_VPN_HOST_DENY_UDP="" > -- > > Personally I find using a custom rule just as simple, but that is me. > > Lonnie > > >> On Sep 16, 2019, at 6:27 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi Devs >> >> Just wondering if I could have a bit of a discussion about the Astlinux firewall and the firewall configuration. >> >> With the recent increase in hacking attempts that I am seeing on my systems, I'm having to get more serious about security and I'm finding that the firewall tab and resulting iptables rules are not quite as granular as I would like. As I am planning on changing my architecture to being VPN based, this was highlighted recently with the need to add custom rules for VPN’s. >> >> Now yes I agree that it would be good to learn iptables and adding custom rules but this will be a considerable learning curve for me and certainly my support staff. >> >> So I'm just wondering if there has been or could be a consideration to extend the granularity of the current firewall tab? >> Here are some of my thoughts: >> • Could we add an additional Zone called VPN >> • Could we separate the Rules Action into three parts: Action (NAT, Pass, Deny etc), Source Zone (EXT, LAN, DMZ, VPN) & Destination Zone (EXT, LAN, DMZ, VPN, Local) >> • Could we pull out some of the Firewall options and create some default Zone to Zone rules >> • Maybe look at building out the use of netset rules for Geoblocking etc. >> >> I'm beginning to have a few partners concerned about the security of Astlinux and its going to be more and more difficult to defend as time goes on. I know that Astlinux has the functionality and tools available to meet most security requirements however they just need to be more accessible to the average network person such as myself. I really don't want to get to the stage where I am putting a firewall in front of the system purely to appease my partners or customers or because its easier. >> >> Yes there is probably quite a bit of work here and some big changes but as I have invested heavily into Astlinux being the core of my business, I'm prepared to contribute financially if necessary. >> >> I apologise if I have stirred up a hornets nest as it was certainly not my intention. It is the fact that I believe heavily in this product (and so have many of my partners that are now recommending us) that I am looking to the future of where it is heading. >> >> I look forward to your comments. >> >> Regards >> Michael Knill >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2019-09-17 21:56:32
|
Thanks Lonnie
Yes maybe I am overestimating the complexity and it should be a set and forget in most instances e.g. SSH port, 5060 and RTP ports.
That being said however, I am certainly interested in your plugin option below as an alternative to custom rules as I begin to use Wireguard more and more often.
Thanks again.
Regards
Michael Knill
On 18/9/19, 12:04 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
Thanks for the detailed description.
I think your over estimating the complexity of maintaining iptables custom rules for local WireGuard traffic (per custom_wg_lan_input() in another email). It really is not that difficult considering only a very small subset of iptables syntax is required.
From how I understand your setup, you have a structured WireGuard mesh of clients, which not all should be allowed to access the server's internals within the WireGuard mesh. This is a somewhat unique setup, but possibly will become more common. As such we need to first understand what firewalling is required ... specifically rules limiting local WireGuard traffic. That is why I suggest you start with custom rules to solve your problem, at least at first.
If you find that your custom rules limiting local WireGuard traffic need constant maintenance, note we already have an AIF wireguard-vpn plugin which is automatically enabled and the plugin configuration is passed via the "WireGuard VPN Configuration" sub-tab. The "Firewall Options:" are passed to the wireguard-vpn plugin.
... or
If the uniqueness of this problem does not justify cluttering-up the "WireGuard VPN Configuration", new AIF wireguard-vpn plugin config variable options could be added and edited as how other "Firewall Plugins:" are configured.
Possibly something like:
--
# Limit WireGuard WG->Local access
#
# Note: The default policy is to allow all WG->Local traffic
# unless WIREGUARD_VPN_HOST_OPEN_xxx is defined, then
# the default policy is to deny all WG->Local traffic.
#
# Syntax:
# "host1,host2~port1,port2 host3,host4~port3,port4 ..."
#
# Example: (allow SSH traffic, deny all other)
# WIREGUARD_VPN_HOST_OPEN_TCP="0/0~22"
#
# Example: (deny HTTP/HTTPS traffic, allow all other)
# WIREGUARD_VPN_HOST_DENY_TCP="0/0~80,443"
# ------------------------------------------------------------------------------
WIREGUARD_VPN_HOST_OPEN_TCP=""
WIREGUARD_VPN_HOST_OPEN_UDP=""
WIREGUARD_VPN_HOST_DENY_TCP=""
WIREGUARD_VPN_HOST_DENY_UDP=""
--
Personally I find using a custom rule just as simple, but that is me.
Lonnie
> On Sep 16, 2019, at 6:27 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Devs
>
> Just wondering if I could have a bit of a discussion about the Astlinux firewall and the firewall configuration.
>
> With the recent increase in hacking attempts that I am seeing on my systems, I'm having to get more serious about security and I'm finding that the firewall tab and resulting iptables rules are not quite as granular as I would like. As I am planning on changing my architecture to being VPN based, this was highlighted recently with the need to add custom rules for VPN’s.
>
> Now yes I agree that it would be good to learn iptables and adding custom rules but this will be a considerable learning curve for me and certainly my support staff.
>
> So I'm just wondering if there has been or could be a consideration to extend the granularity of the current firewall tab?
> Here are some of my thoughts:
> • Could we add an additional Zone called VPN
> • Could we separate the Rules Action into three parts: Action (NAT, Pass, Deny etc), Source Zone (EXT, LAN, DMZ, VPN) & Destination Zone (EXT, LAN, DMZ, VPN, Local)
> • Could we pull out some of the Firewall options and create some default Zone to Zone rules
> • Maybe look at building out the use of netset rules for Geoblocking etc.
>
> I'm beginning to have a few partners concerned about the security of Astlinux and its going to be more and more difficult to defend as time goes on. I know that Astlinux has the functionality and tools available to meet most security requirements however they just need to be more accessible to the average network person such as myself. I really don't want to get to the stage where I am putting a firewall in front of the system purely to appease my partners or customers or because its easier.
>
> Yes there is probably quite a bit of work here and some big changes but as I have invested heavily into Astlinux being the core of my business, I'm prepared to contribute financially if necessary.
>
> I apologise if I have stirred up a hornets nest as it was certainly not my intention. It is the fact that I believe heavily in this product (and so have many of my partners that are now recommending us) that I am looking to the future of where it is heading.
>
> I look forward to your comments.
>
> Regards
> Michael Knill
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
28 messages has been excluded from this view by a project administrator.
