Menu
▾
▴
astlinux-users — AstLinux Users Mailing List
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(91) |
Feb
(111) |
Mar
(226) |
Apr
(65) |
May
(197) |
Jun
(202) |
Jul
(92) |
Aug
(87) |
Sep
(120) |
Oct
(133) |
Nov
(89) |
Dec
(155) |
| 2008 |
Jan
(251) |
Feb
(136) |
Mar
(174) |
Apr
(149) |
May
(56) |
Jun
(32) |
Jul
(36) |
Aug
(171) |
Sep
(245) |
Oct
(244) |
Nov
(218) |
Dec
(272) |
| 2009 |
Jan
(113) |
Feb
(119) |
Mar
(192) |
Apr
(117) |
May
(93) |
Jun
(46) |
Jul
(80) |
Aug
(54) |
Sep
(109) |
Oct
(70) |
Nov
(145) |
Dec
(110) |
| 2010 |
Jan
(137) |
Feb
(87) |
Mar
(45) |
Apr
(157) |
May
(58) |
Jun
(99) |
Jul
(188) |
Aug
(136) |
Sep
(101) |
Oct
(100) |
Nov
(61) |
Dec
(60) |
| 2011 |
Jan
(84) |
Feb
(43) |
Mar
(70) |
Apr
(17) |
May
(69) |
Jun
(28) |
Jul
(43) |
Aug
(21) |
Sep
(151) |
Oct
(120) |
Nov
(84) |
Dec
(101) |
| 2012 |
Jan
(119) |
Feb
(82) |
Mar
(70) |
Apr
(115) |
May
(66) |
Jun
(131) |
Jul
(70) |
Aug
(65) |
Sep
(66) |
Oct
(86) |
Nov
(197) |
Dec
(81) |
| 2013 |
Jan
(65) |
Feb
(48) |
Mar
(32) |
Apr
(68) |
May
(98) |
Jun
(59) |
Jul
(41) |
Aug
(52) |
Sep
(42) |
Oct
(37) |
Nov
(10) |
Dec
(27) |
| 2014 |
Jan
(61) |
Feb
(34) |
Mar
(30) |
Apr
(52) |
May
(45) |
Jun
(40) |
Jul
(28) |
Aug
(9) |
Sep
(39) |
Oct
(69) |
Nov
(55) |
Dec
(19) |
| 2015 |
Jan
(13) |
Feb
(21) |
Mar
(5) |
Apr
(14) |
May
(30) |
Jun
(51) |
Jul
(31) |
Aug
(12) |
Sep
(29) |
Oct
(15) |
Nov
(24) |
Dec
(16) |
| 2016 |
Jan
(62) |
Feb
(76) |
Mar
(30) |
Apr
(43) |
May
(46) |
Jun
(62) |
Jul
(21) |
Aug
(49) |
Sep
(67) |
Oct
(27) |
Nov
(26) |
Dec
(38) |
| 2017 |
Jan
(7) |
Feb
(12) |
Mar
(69) |
Apr
(59) |
May
(54) |
Jun
(40) |
Jul
(76) |
Aug
(82) |
Sep
(92) |
Oct
(51) |
Nov
(32) |
Dec
(30) |
| 2018 |
Jan
(22) |
Feb
(25) |
Mar
(34) |
Apr
(35) |
May
(37) |
Jun
(21) |
Jul
(69) |
Aug
(55) |
Sep
(17) |
Oct
(67) |
Nov
(9) |
Dec
(5) |
| 2019 |
Jan
(19) |
Feb
(12) |
Mar
(15) |
Apr
(19) |
May
|
Jun
(27) |
Jul
(27) |
Aug
(25) |
Sep
(25) |
Oct
(27) |
Nov
(10) |
Dec
(14) |
| 2020 |
Jan
(22) |
Feb
(20) |
Mar
(36) |
Apr
(40) |
May
(52) |
Jun
(35) |
Jul
(21) |
Aug
(32) |
Sep
(71) |
Oct
(27) |
Nov
(11) |
Dec
(16) |
| 2021 |
Jan
(16) |
Feb
(21) |
Mar
(21) |
Apr
(27) |
May
(17) |
Jun
|
Jul
(2) |
Aug
(22) |
Sep
(23) |
Oct
(7) |
Nov
(11) |
Dec
(28) |
| 2022 |
Jan
(23) |
Feb
(18) |
Mar
(9) |
Apr
(15) |
May
(15) |
Jun
(7) |
Jul
(8) |
Aug
(15) |
Sep
(1) |
Oct
|
Nov
(11) |
Dec
(10) |
| 2023 |
Jan
(14) |
Feb
(10) |
Mar
(11) |
Apr
(13) |
May
(2) |
Jun
(30) |
Jul
(1) |
Aug
(15) |
Sep
(13) |
Oct
(3) |
Nov
(25) |
Dec
(5) |
| 2024 |
Jan
(3) |
Feb
(10) |
Mar
(9) |
Apr
|
May
(1) |
Jun
(15) |
Jul
(7) |
Aug
(10) |
Sep
(3) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(3) |
Feb
(1) |
Mar
(7) |
Apr
(5) |
May
(13) |
Jun
(16) |
Jul
(1) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael K. <mic...@ip...> - 2019-06-23 20:54:47
|
Thanks Lonnie
No it would be another address in the /24 range on the interface.
Regards
Michael Knill
On 23/6/19, 11:49 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
> On Jun 23, 2019, at 12:35 AM, Michael Knill <mic...@ip...> wrote:
>
> Hi Group
>
> I know there is EXTIP_ALIAS for WAN interfaces but how would I put on a secondary IP Address for a LAN interface?
> Do I need to use ‘ip addr add’ in rc.elocal?
Hi Michael,
Yes, rc.elocal would be the way to do that.
I assume you are talking about adding a /32 .
Lonnie
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2019-06-23 13:48:41
|
> On Jun 23, 2019, at 12:35 AM, Michael Knill <mic...@ip...> wrote: > > Hi Group > > I know there is EXTIP_ALIAS for WAN interfaces but how would I put on a secondary IP Address for a LAN interface? > Do I need to use ‘ip addr add’ in rc.elocal? Hi Michael, Yes, rc.elocal would be the way to do that. I assume you are talking about adding a /32 . Lonnie |
|
From: Michael K. <mic...@ip...> - 2019-06-23 05:35:24
|
Hi Group I know there is EXTIP_ALIAS for WAN interfaces but how would I put on a secondary IP Address for a LAN interface? Do I need to use ‘ip addr add’ in rc.elocal? Thnaks Regards Michael Knill |
|
From: Lonnie A. <li...@lo...> - 2019-06-22 13:46:07
|
Announcing Pre-Release Version: astlinux-1.3-4246-f527cd The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own. -- Asterisk 11.x, no longer included, officially EOL 2017-10-25 -- Asterisk 13.23.1 (new '13se' version) Older than latest Asterisk 13.x version but more tested, built --without-pjproject -- Asterisk 13.27.0 (version bump) and 16.4.0 (new version) Adds: res_mwi_devstate.so, MWI Device State Subscriptions -- Linux Kernel 3.16.69, security and bug fixes, including MDS (ZombieLoad) and SACK Panic mitigation support. -- busybox, *major* version bump to 1.30.1, security and bug fixes. -- WireGuard VPN, version bump to 0.0.20190601 Add "service wireguard reload" support. This allows WireGuard peers to be edited, added, and/or removed with minimal impact to active tunnels. Web Interface Network / Edit tabs, add "Reload WireGuard VPN" support. -- ne, new package, version 3.1.2, the nice editor, alternative to nano ne is easy to use for the beginner, but powerful and fully configurable for the wizard. Includes syntax checking for: asterisk, conf, ini, perl, sh More Info: http://ne.di.unimi.it/ -- Complete Pre-Release ChangeLog: https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt Updated Documentation Topics: Asterisk LTS Series Version - - https://doc.astlinux-project.org/userdoc:tt_asterisk_upgrade_version 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 New "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-06-13 22:52:48
|
Typo below: - 2) "Restart WireGuard VPN" takes << 1 second (using "syncconf"), no noticeable impact at all, even when editing the AllowedIPs of the peer tunnel used for + 2) "Reload WireGuard VPN" takes << 1 second (using "syncconf"), no noticeable impact at all, even when editing the AllowedIPs of the peer tunnel used for > On Jun 13, 2019, at 5:47 PM, Lonnie Abelbeck <li...@lo...> wrote: > >> Will this be in 1.3.6? > > It looks like it will, I'm testing ... Exactly what will be the final solution upstream is to be determined, Jason considered moving the "syncconf" code into the standard "setconf". Jason's thoughts are here: > https://lists.zx2c4.com/pipermail/wireguard/2019-June/004225.html > > Regardless if it is "syncconf", "setconf" or something else we can easily adapt, currently we are using the "syncconf" commit per above. > > > A real world example, connecting over WG to a Linode instance of AstLinux: > > 1) "Restart WireGuard VPN" takes 35 seconds (using "setconf"), 17 seconds for the WG peer to reestablish and the rest of the time are most likely the TCP backoff timers for the HTTPS web interface session, totaling 35 seconds. > > 2) "Restart WireGuard VPN" takes << 1 second (using "syncconf"), no noticeable impact at all, even when editing the AllowedIPs of the peer tunnel used for access. > > Lonnie > > > >> On Jun 13, 2019, at 4:36 PM, Michael Knill <mic...@ip...> wrote: >> >> Thanks Lonnie. >> Awesome news as I am looking to build my entire Astlinux network around Wireguard and this was a big issue especially since I didn't realise that wg setconf interrupted active tunnels (whoops). >> Will this be in 1.3.6? >> >> Regards >> Michael Knill >> >> On 13/6/19, 1:35 pm, "Lonnie Abelbeck" <li...@lo...> wrote: >> >> Hi Michael, >> >>> On Jun 8, 2019, at 10:28 PM, Michael Knill <mic...@ip...> wrote: >>> >>> Hi Lonnie >>> >>> I have overcome having to reset Wireguard by adding it to the configuration and then adding the peer from the command line as follows: >>> wg set wg0 peer <Public key of Endpoint VPN Peer collected above> allowed-ips <Allocated Endpoint IP Address>/32 >>> >>> Seems to work fine. May be worthwhile adding it to the GUI. >> >> The WireGuard author has come up with a new "wg syncconf ..." subcommand (not in master just yet) >> >> I added support for it, currently implemented as "service wireguard reload" ... a web interface item "Reload WireGuard VPN" soon. >> >> Previously using "wg setconf ..." under the best conditions active tunnels would be interrupted for 17 seconds, now there is no interruption with "wg syncconf ...". The wg0 interface is not taken down and back up, so any static routes will remain. >> >> So, if all your are doing is editing, adding, and/or deleting peers, follow it with a "service wireguard reload" or "Reload WireGuard VPN" menu and it is applied immediately without any interruption. >> >> In addition, the auto-routes are properly added and deleted due to changes in the peer configs. >> >> So far this is working well in testing. >> >> Michael, long story short, you will be able to add/edit/delete a peer and simply select "Reload WireGuard VPN", poof you're done. >> >> Lonnie >> >> >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Lonnie A. <li...@lo...> - 2019-06-13 22:47:18
|
> Will this be in 1.3.6? It looks like it will, I'm testing ... Exactly what will be the final solution upstream is to be determined, Jason considered moving the "syncconf" code into the standard "setconf". Jason's thoughts are here: https://lists.zx2c4.com/pipermail/wireguard/2019-June/004225.html Regardless if it is "syncconf", "setconf" or something else we can easily adapt, currently we are using the "syncconf" commit per above. A real world example, connecting over WG to a Linode instance of AstLinux: 1) "Restart WireGuard VPN" takes 35 seconds (using "setconf"), 17 seconds for the WG peer to reestablish and the rest of the time are most likely the TCP backoff timers for the HTTPS web interface session, totaling 35 seconds. 2) "Restart WireGuard VPN" takes << 1 second (using "syncconf"), no noticeable impact at all, even when editing the AllowedIPs of the peer tunnel used for access. Lonnie > On Jun 13, 2019, at 4:36 PM, Michael Knill <mic...@ip...> wrote: > > Thanks Lonnie. > Awesome news as I am looking to build my entire Astlinux network around Wireguard and this was a big issue especially since I didn't realise that wg setconf interrupted active tunnels (whoops). > Will this be in 1.3.6? > > Regards > Michael Knill > > On 13/6/19, 1:35 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, > >> On Jun 8, 2019, at 10:28 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi Lonnie >> >> I have overcome having to reset Wireguard by adding it to the configuration and then adding the peer from the command line as follows: >> wg set wg0 peer <Public key of Endpoint VPN Peer collected above> allowed-ips <Allocated Endpoint IP Address>/32 >> >> Seems to work fine. May be worthwhile adding it to the GUI. > > The WireGuard author has come up with a new "wg syncconf ..." subcommand (not in master just yet) > > I added support for it, currently implemented as "service wireguard reload" ... a web interface item "Reload WireGuard VPN" soon. > > Previously using "wg setconf ..." under the best conditions active tunnels would be interrupted for 17 seconds, now there is no interruption with "wg syncconf ...". The wg0 interface is not taken down and back up, so any static routes will remain. > > So, if all your are doing is editing, adding, and/or deleting peers, follow it with a "service wireguard reload" or "Reload WireGuard VPN" menu and it is applied immediately without any interruption. > > In addition, the auto-routes are properly added and deleted due to changes in the peer configs. > > So far this is working well in testing. > > Michael, long story short, you will be able to add/edit/delete a peer and simply select "Reload WireGuard VPN", poof you're done. > > Lonnie > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2019-06-13 21:36:23
|
Thanks Lonnie.
Awesome news as I am looking to build my entire Astlinux network around Wireguard and this was a big issue especially since I didn't realise that wg setconf interrupted active tunnels (whoops).
Will this be in 1.3.6?
Regards
Michael Knill
On 13/6/19, 1:35 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
> On Jun 8, 2019, at 10:28 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Lonnie
>
> I have overcome having to reset Wireguard by adding it to the configuration and then adding the peer from the command line as follows:
> wg set wg0 peer <Public key of Endpoint VPN Peer collected above> allowed-ips <Allocated Endpoint IP Address>/32
>
> Seems to work fine. May be worthwhile adding it to the GUI.
The WireGuard author has come up with a new "wg syncconf ..." subcommand (not in master just yet)
I added support for it, currently implemented as "service wireguard reload" ... a web interface item "Reload WireGuard VPN" soon.
Previously using "wg setconf ..." under the best conditions active tunnels would be interrupted for 17 seconds, now there is no interruption with "wg syncconf ...". The wg0 interface is not taken down and back up, so any static routes will remain.
So, if all your are doing is editing, adding, and/or deleting peers, follow it with a "service wireguard reload" or "Reload WireGuard VPN" menu and it is applied immediately without any interruption.
In addition, the auto-routes are properly added and deleted due to changes in the peer configs.
So far this is working well in testing.
Michael, long story short, you will be able to add/edit/delete a peer and simply select "Reload WireGuard VPN", poof you're done.
Lonnie
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2019-06-13 03:35:25
|
Hi Michael, > On Jun 8, 2019, at 10:28 PM, Michael Knill <mic...@ip...> wrote: > > Hi Lonnie > > I have overcome having to reset Wireguard by adding it to the configuration and then adding the peer from the command line as follows: > wg set wg0 peer <Public key of Endpoint VPN Peer collected above> allowed-ips <Allocated Endpoint IP Address>/32 > > Seems to work fine. May be worthwhile adding it to the GUI. The WireGuard author has come up with a new "wg syncconf ..." subcommand (not in master just yet) I added support for it, currently implemented as "service wireguard reload" ... a web interface item "Reload WireGuard VPN" soon. Previously using "wg setconf ..." under the best conditions active tunnels would be interrupted for 17 seconds, now there is no interruption with "wg syncconf ...". The wg0 interface is not taken down and back up, so any static routes will remain. So, if all your are doing is editing, adding, and/or deleting peers, follow it with a "service wireguard reload" or "Reload WireGuard VPN" menu and it is applied immediately without any interruption. In addition, the auto-routes are properly added and deleted due to changes in the peer configs. So far this is working well in testing. Michael, long story short, you will be able to add/edit/delete a peer and simply select "Reload WireGuard VPN", poof you're done. Lonnie |
|
From: Michael K. <mic...@ip...> - 2019-06-09 21:04:57
|
Thanks Lonnie.
I'm looking forward to having a play.
Regards
Michael Knill
On 9/6/19, 9:43 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
Thanks for clarifying.
> Wireguard can fail back to the Primary route so quickly that it is unnoticeable when you are in a voice call. Very cool!
Yes, very cool, I use that as well.
> So if I did have a secondary IP Address on the wg0 interface, would I need custom firewall rules?
Keep in mind that the default setting in the WireGuard Config:
_x_ Create routes for Allowed IP's for all peers
As it says, it will auto-create routes for any AllowedIPs using foreign addresses.
I don't think any custom firewall rules will be needed.
I also don't think you need the rc.elocal "Add Secondary IP Addresses to wg0" given above.
Lonnie
> On Jun 8, 2019, at 10:28 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Lonnie
>
> Sorry for the confusion. No I will have three separate servers, one purely for management and the other two are transit switches, one primary and one backup in case the primary fails.
> The path the VPN takes will be completely up to the Astlinux configuration which may or may not have a failover route configured. Its actually a really neat solution whereby I don't care about any NAT or the path it takes and the testing I have done, Wireguard can fail back to the Primary route so quickly that it is unnoticeable when you are in a voice call. Very cool!
>
> I have overcome having to reset Wireguard by adding it to the configuration and then adding the peer from the command line as follows:
> wg set wg0 peer <Public key of Endpoint VPN Peer collected above> allowed-ips <Allocated Endpoint IP Address>/32
>
> Seems to work fine. May be worthwhile adding it to the GUI.
>
> As far as overlapping routes, the overlap is between individual customer Astlinux peers e.g. you could have a satellite office on 172.29.253.2/24 which overlaps with another customer Astlinux peer with the same address. This is not a problem of course unless they know about each other but this is a possibility for a multisite customer.
> It also means that I cant standardise the VPN gateway address at each site for mobile peers e.g. 172.29.253.1 for site 1, 172.29.253.2 for site 2 etc.
> None of this is insurmountable, just maybe not quite a neat as a Local /24 subnet for local peers and a separate subnet for the three upstream servers (not three separate subnets as I first mentioned).
>
> So if I did have a secondary IP Address on the wg0 interface, would I need custom firewall rules?
>
> Regards
> Michael Knill
>
> On 8/6/19, 11:20 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Michael,
>
> A single /24 looks simpler to my eye ... very similar to how I do it myself.
>
>> Hmm it certainly is unusual as there are overlapping routes everywhere but they just don't know about each other.
>
> Overlapping routes ? I don't see any, all basically point-to-point in your internal WG 172.29.253.0/24 net, so far.
>
>> It will certainly also get messy if Astlinux boxes peering to us are also peering to the 3 upstream servers.
>
> Can you explain what you mean by "messy" ?
>
> ===
> As an aside, I'm trying to think how the "clients" could be configured as "Mobile Clients" on one of the "servers". As it is now, adding or removing a "client" requires restarting WireGuard on each of the three servers to apply changes.
>
> Michael, correct me if I am wrong, but your current parallel design:
>
> client --|-- Primary
> --|-- Secondary
> --|-- Management
>
> is to allow each 3 paths to go over different transports (PPPoE, Cable, 4G/LTE).
>
> But, if you can cleverly use WAN Failover to swap network paths (PPPoE, Cable, 4G/LTE) using this layout:
>
> client --|-- Primary --|-- Secondary
> --|-- Management
>
> In this case only the Primary server needs to know about the clients credentials, and *if* the clients only need a single WG IP address (no client LAN routing over WG) then clients could be auto-assigned "Mobile Client" credentials with IP's in the .101 to .199 range.
>
> "Mobile Clients" can be added and removed in realtime without restarting WireGuard.
>
> Lonnie
>
>
>
>
>> On Jun 7, 2019, at 11:40 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Thanks Lonnie
>>
>> Yes I'm replying to the original post and yes I do recall now talking about that.
>> Hmm maybe I can just use a /24:
>>
>> -- All 3 upstream servers --
>> gui.wireguard.conf:
>> WIREGUARD_IP="172.29.253.[252|253|254]"
>> WIREGUARD_NM="255.255.255.0"
>>
>> wg0.peer:
>> [Peer]
>> # Peer 1
>> PublicKey = ###
>> AllowedIPs = 172.29.253.1/32
>>
>> [Peer]
>> # Peer 2
>> PublicKey = ###
>> AllowedIPs = 172.29.253.2/32 ........>
>>
>> [Peer]
>> # Peer 100 (Note 101-199 used for Client peer's Remote Peers)
>> PublicKey = ###
>> AllowedIPs = 172.29.253.100/32
>>
>> -- Client --
>> gui.wireguard.conf:
>> WIREGUARD_IP="172.29.253.[1-100]"
>> WIREGUARD_NM="255.255.255.0"
>>
>> wg0.peer:
>> [Peer]
>> # Management Server
>> PublicKey = ###
>> Endpoint = management01.ipcaccess.net
>> AllowedIPs = 172.29.253.254/32
>> PersistentKeepalive = 25
>>
>> [Peer]
>> # Primary Server
>> PublicKey = ###
>> Endpoint = primary01.ipcaccess.net
>> AllowedIPs = 172.29.253.253/32
>> # No keepalive required as SIP Options ping will keep it up
>>
>> [Peer]
>> # Secondary Server
>> PublicKey = ###
>> Endpoint = secondary01.ipcaccess.net
>> AllowedIPs = 172.29.253.252/32
>> # No keepalive required as SIP Options ping will keep it up
>>
>> [Peer]
>> # Another Astlinux box peering to us
>> PublicKey = ###
>> AllowedIPs = 172.29.253.2/32,<other accessible routes at the satellite site>
>> # No keepalive required as SIP Options ping will keep it up
>> --
>>
>> Hmm it certainly is unusual as there are overlapping routes everywhere but they just don't know about each other. It will certainly also get messy if Astlinux boxes peering to us are also peering to the 3 upstream servers.
>> So would Secondary addresses actually work if I did it purely for my sanity?
>>
>> Regards
>> Michael Knill
>>
>> On 8/6/19, 12:33 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>>
>> Hi Michael,
>>
>> I seem to recall discussing this before, but why the 3 separate /24 networks requiring a rc.elocal rather than one /22 network set by the WG configs ?
>>
>> # netcalc 172.29.200.1/22
>> Address : 172.29.200.1 10101100.00011101.110010 00.00000001
>> Netmask : 255.255.252.0 = 22 11111111.11111111.111111 00.00000000
>> Wildcard : 0.0.3.255 00000000.00000000.000000 11.11111111
>> =>
>> Network : 172.29.200.0/22 10101100.00011101.110010 00.00000000
>> HostMin : 172.29.200.1 10101100.00011101.110010 00.00000001
>> HostMax : 172.29.203.254 10101100.00011101.110010 11.11111110
>> Broadcast: 172.29.203.255 10101100.00011101.110010 11.11111111
>> Hosts/Net: 1022 Class B, Private network (RFC1918)
>>
>>
>> Other than that, with only a quick glance, it looks like you understand the elegance of WireGuard.
>>
>> Also I see you noted:
>> --
>> # No keepalive required as SIP Options ping will keep it up
>> --
>> which is probably just fine, though there is not much added overhead if "PersistentKeepalive = 25" is also set possibly on the remote non-"SIP Options ping" peer, just something to file away in your mind.
>>
>> Lonnie
>>
>>
>>
>>> On Jun 7, 2019, at 8:57 PM, Michael Knill <mic...@ip...> wrote:
>>>
>>> Hi Group
>>>
>>> I would like to bring this up again as I have begun development of a transit switch for my customers (using Astlinux).
>>> The architecture will be both a primary and secondary server for the transit switch with regular synchronisation from Primary to Secondary. Both will have trunks to my upstream SIP provider with active/active redundancy.
>>> All customer Astlinux boxes will connect via Wireguard VPN as a client to 3 servers being Primary Transit, Secondary Transit and a Management server (I would rather not manage through the Transit servers). The customer Astlinux box could also be a VPN server for other satellite sites and user Remote Peers.
>>> Should this config work?
>>>
>>> -- Management Server --
>>> gui.wireguard.conf:
>>> WIREGUARD_IP="172.29.200.254"
>>> WIREGUARD_NM="255.255.255.0"
>>>
>>> wg0.peer:
>>> [Peer]
>>> # Peer 1
>>> PublicKey = ###
>>> AllowedIPs = 172.29.200.1/32
>>>
>>> [Peer]
>>> # Peer 2
>>> PublicKey = ###
>>> AllowedIPs = 172.29.200.2/32 ........>
>>>
>>> [Peer]
>>> # Peer 200
>>> PublicKey = ###
>>> AllowedIPs = 172.29.200.200/32
>>>
>>>
>>> -- Primary Server --
>>> gui.wireguard.conf:
>>> WIREGUARD_IP="172.29.201.254"
>>> WIREGUARD_NM="255.255.255.0"
>>>
>>> wg0.peer:
>>> [Peer]
>>> # Peer 1
>>> PublicKey = ###
>>> AllowedIPs = 172.29.201.1/32
>>>
>>> [Peer]
>>> # Peer 2
>>> PublicKey = ###
>>> AllowedIPs = 172.29.201.2/32 ........>
>>>
>>> [Peer]
>>> # Peer 200
>>> PublicKey = ###
>>> AllowedIPs = 172.29.201.200/32
>>>
>>>
>>> -- Secondary Server --
>>> gui.wireguard.conf:
>>> WIREGUARD_IP="172.29.202.254"
>>> WIREGUARD_NM="255.255.255.0"
>>>
>>> wg0.peer:
>>> [Peer]
>>> # Peer 1
>>> PublicKey = ###
>>> AllowedIPs = 172.29.202.1/32
>>>
>>> [Peer]
>>> # Peer 2
>>> PublicKey = ###
>>> AllowedIPs = 172.29.202.2/32. ........>
>>>
>>> [Peer]
>>> # Peer 200
>>> PublicKey = ###
>>> AllowedIPs = 172.29.202.200/32
>>>
>>>
>>> -- Client --
>>> gui.wireguard.conf:
>>> # This range is used for peers to us that we are a server e.g. satellite sites and users
>>> WIREGUARD_IP="172.29.253.1"
>>> WIREGUARD_NM="255.255.255.0"
>>>
>>> rc.elocal:
>>> # Add Secondary IP Addresses to wg0
>>> ip addr add 172.29.200.1/24 dev wg0
>>> ip addr add 172.29.201.1/24 dev wg0
>>> ip addr add 172.29.202.1/24 dev wg0
>>>
>>> wg0.peer:
>>> [Peer]
>>> # Management Server
>>> PublicKey = ###
>>> Endpoint = management01.ipcaccess.net
>>> AllowedIPs = 172.29.200.254/32
>>> PersistentKeepalive = 25
>>>
>>> [Peer]
>>> # Primary Server
>>> PublicKey = ###
>>> Endpoint = primary01.ipcaccess.net
>>> AllowedIPs = 172.29.201.254/32
>>> # No keepalive required as SIP Options ping will keep it up
>>>
>>> [Peer]
>>> # Secondary Server
>>> PublicKey = ###
>>> Endpoint = secondary01.ipcaccess.net
>>> AllowedIPs = 172.29.202.254/32
>>> # No keepalive required as SIP Options ping will keep it up
>>>
>>> [Peer]
>>> # Another Astlinux box peering to us
>>> PublicKey = ###
>>> AllowedIPs = 172.29.253.2/32,<other accessible routes at the satellite site>
>>> # No keepalive required as SIP Options ping will keep it up
>>> --
>>>
>>> Can anyone see problems with this configuration?
>>>
>>> Regards
>>> Michael Knill
>>>
>>> From: David Kerr <da...@ke...>
>>> Reply-To: AstLinux List <ast...@li...>
>>> Date: Tuesday, 1 January 2019 at 6:21 pm
>>> To: AstLinux List <ast...@li...>
>>> Subject: Re: [Astlinux-users] Multiple wg interfaces
>>>
>>> Michael,
>>> A single wg interface can have multiple IP addresses. They can be different subnets too. You will have to manually edit the config files.
>>>
>>> David.
>>>
>>> On Tue, Jan 1, 2019 at 6:37 AM Michael Knill <mic...@ip...> wrote:
>>>> Hi group
>>>>
>>>> Here is my scenario. I have primary and backup Wireguard VPN Peers that multiple Astlinux boxes will be connecting to.
>>>> I assume that I will need different wgx interfaces for this as I cant have the same IP Address.
>>>> If so, just wondering how to set this up in Astlinux?
>>>>
>>>> Regards
>>>> Michael Knill
>>>> _______________________________________________
>>>> Astlinux-users mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>>
>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>> --
>>> David Kerr Sent from Gmail Mobile
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>
>>
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>
>>
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2019-06-09 11:43:15
|
Hi Michael, Thanks for clarifying. > Wireguard can fail back to the Primary route so quickly that it is unnoticeable when you are in a voice call. Very cool! Yes, very cool, I use that as well. > So if I did have a secondary IP Address on the wg0 interface, would I need custom firewall rules? Keep in mind that the default setting in the WireGuard Config: _x_ Create routes for Allowed IP's for all peers As it says, it will auto-create routes for any AllowedIPs using foreign addresses. I don't think any custom firewall rules will be needed. I also don't think you need the rc.elocal "Add Secondary IP Addresses to wg0" given above. Lonnie > On Jun 8, 2019, at 10:28 PM, Michael Knill <mic...@ip...> wrote: > > Hi Lonnie > > Sorry for the confusion. No I will have three separate servers, one purely for management and the other two are transit switches, one primary and one backup in case the primary fails. > The path the VPN takes will be completely up to the Astlinux configuration which may or may not have a failover route configured. Its actually a really neat solution whereby I don't care about any NAT or the path it takes and the testing I have done, Wireguard can fail back to the Primary route so quickly that it is unnoticeable when you are in a voice call. Very cool! > > I have overcome having to reset Wireguard by adding it to the configuration and then adding the peer from the command line as follows: > wg set wg0 peer <Public key of Endpoint VPN Peer collected above> allowed-ips <Allocated Endpoint IP Address>/32 > > Seems to work fine. May be worthwhile adding it to the GUI. > > As far as overlapping routes, the overlap is between individual customer Astlinux peers e.g. you could have a satellite office on 172.29.253.2/24 which overlaps with another customer Astlinux peer with the same address. This is not a problem of course unless they know about each other but this is a possibility for a multisite customer. > It also means that I cant standardise the VPN gateway address at each site for mobile peers e.g. 172.29.253.1 for site 1, 172.29.253.2 for site 2 etc. > None of this is insurmountable, just maybe not quite a neat as a Local /24 subnet for local peers and a separate subnet for the three upstream servers (not three separate subnets as I first mentioned). > > So if I did have a secondary IP Address on the wg0 interface, would I need custom firewall rules? > > Regards > Michael Knill > > On 8/6/19, 11:20 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, > > A single /24 looks simpler to my eye ... very similar to how I do it myself. > >> Hmm it certainly is unusual as there are overlapping routes everywhere but they just don't know about each other. > > Overlapping routes ? I don't see any, all basically point-to-point in your internal WG 172.29.253.0/24 net, so far. > >> It will certainly also get messy if Astlinux boxes peering to us are also peering to the 3 upstream servers. > > Can you explain what you mean by "messy" ? > > === > As an aside, I'm trying to think how the "clients" could be configured as "Mobile Clients" on one of the "servers". As it is now, adding or removing a "client" requires restarting WireGuard on each of the three servers to apply changes. > > Michael, correct me if I am wrong, but your current parallel design: > > client --|-- Primary > --|-- Secondary > --|-- Management > > is to allow each 3 paths to go over different transports (PPPoE, Cable, 4G/LTE). > > But, if you can cleverly use WAN Failover to swap network paths (PPPoE, Cable, 4G/LTE) using this layout: > > client --|-- Primary --|-- Secondary > --|-- Management > > In this case only the Primary server needs to know about the clients credentials, and *if* the clients only need a single WG IP address (no client LAN routing over WG) then clients could be auto-assigned "Mobile Client" credentials with IP's in the .101 to .199 range. > > "Mobile Clients" can be added and removed in realtime without restarting WireGuard. > > Lonnie > > > > >> On Jun 7, 2019, at 11:40 PM, Michael Knill <mic...@ip...> wrote: >> >> Thanks Lonnie >> >> Yes I'm replying to the original post and yes I do recall now talking about that. >> Hmm maybe I can just use a /24: >> >> -- All 3 upstream servers -- >> gui.wireguard.conf: >> WIREGUARD_IP="172.29.253.[252|253|254]" >> WIREGUARD_NM="255.255.255.0" >> >> wg0.peer: >> [Peer] >> # Peer 1 >> PublicKey = ### >> AllowedIPs = 172.29.253.1/32 >> >> [Peer] >> # Peer 2 >> PublicKey = ### >> AllowedIPs = 172.29.253.2/32 ........> >> >> [Peer] >> # Peer 100 (Note 101-199 used for Client peer's Remote Peers) >> PublicKey = ### >> AllowedIPs = 172.29.253.100/32 >> >> -- Client -- >> gui.wireguard.conf: >> WIREGUARD_IP="172.29.253.[1-100]" >> WIREGUARD_NM="255.255.255.0" >> >> wg0.peer: >> [Peer] >> # Management Server >> PublicKey = ### >> Endpoint = management01.ipcaccess.net >> AllowedIPs = 172.29.253.254/32 >> PersistentKeepalive = 25 >> >> [Peer] >> # Primary Server >> PublicKey = ### >> Endpoint = primary01.ipcaccess.net >> AllowedIPs = 172.29.253.253/32 >> # No keepalive required as SIP Options ping will keep it up >> >> [Peer] >> # Secondary Server >> PublicKey = ### >> Endpoint = secondary01.ipcaccess.net >> AllowedIPs = 172.29.253.252/32 >> # No keepalive required as SIP Options ping will keep it up >> >> [Peer] >> # Another Astlinux box peering to us >> PublicKey = ### >> AllowedIPs = 172.29.253.2/32,<other accessible routes at the satellite site> >> # No keepalive required as SIP Options ping will keep it up >> -- >> >> Hmm it certainly is unusual as there are overlapping routes everywhere but they just don't know about each other. It will certainly also get messy if Astlinux boxes peering to us are also peering to the 3 upstream servers. >> So would Secondary addresses actually work if I did it purely for my sanity? >> >> Regards >> Michael Knill >> >> On 8/6/19, 12:33 pm, "Lonnie Abelbeck" <li...@lo...> wrote: >> >> Hi Michael, >> >> I seem to recall discussing this before, but why the 3 separate /24 networks requiring a rc.elocal rather than one /22 network set by the WG configs ? >> >> # netcalc 172.29.200.1/22 >> Address : 172.29.200.1 10101100.00011101.110010 00.00000001 >> Netmask : 255.255.252.0 = 22 11111111.11111111.111111 00.00000000 >> Wildcard : 0.0.3.255 00000000.00000000.000000 11.11111111 >> => >> Network : 172.29.200.0/22 10101100.00011101.110010 00.00000000 >> HostMin : 172.29.200.1 10101100.00011101.110010 00.00000001 >> HostMax : 172.29.203.254 10101100.00011101.110010 11.11111110 >> Broadcast: 172.29.203.255 10101100.00011101.110010 11.11111111 >> Hosts/Net: 1022 Class B, Private network (RFC1918) >> >> >> Other than that, with only a quick glance, it looks like you understand the elegance of WireGuard. >> >> Also I see you noted: >> -- >> # No keepalive required as SIP Options ping will keep it up >> -- >> which is probably just fine, though there is not much added overhead if "PersistentKeepalive = 25" is also set possibly on the remote non-"SIP Options ping" peer, just something to file away in your mind. >> >> Lonnie >> >> >> >>> On Jun 7, 2019, at 8:57 PM, Michael Knill <mic...@ip...> wrote: >>> >>> Hi Group >>> >>> I would like to bring this up again as I have begun development of a transit switch for my customers (using Astlinux). >>> The architecture will be both a primary and secondary server for the transit switch with regular synchronisation from Primary to Secondary. Both will have trunks to my upstream SIP provider with active/active redundancy. >>> All customer Astlinux boxes will connect via Wireguard VPN as a client to 3 servers being Primary Transit, Secondary Transit and a Management server (I would rather not manage through the Transit servers). The customer Astlinux box could also be a VPN server for other satellite sites and user Remote Peers. >>> Should this config work? >>> >>> -- Management Server -- >>> gui.wireguard.conf: >>> WIREGUARD_IP="172.29.200.254" >>> WIREGUARD_NM="255.255.255.0" >>> >>> wg0.peer: >>> [Peer] >>> # Peer 1 >>> PublicKey = ### >>> AllowedIPs = 172.29.200.1/32 >>> >>> [Peer] >>> # Peer 2 >>> PublicKey = ### >>> AllowedIPs = 172.29.200.2/32 ........> >>> >>> [Peer] >>> # Peer 200 >>> PublicKey = ### >>> AllowedIPs = 172.29.200.200/32 >>> >>> >>> -- Primary Server -- >>> gui.wireguard.conf: >>> WIREGUARD_IP="172.29.201.254" >>> WIREGUARD_NM="255.255.255.0" >>> >>> wg0.peer: >>> [Peer] >>> # Peer 1 >>> PublicKey = ### >>> AllowedIPs = 172.29.201.1/32 >>> >>> [Peer] >>> # Peer 2 >>> PublicKey = ### >>> AllowedIPs = 172.29.201.2/32 ........> >>> >>> [Peer] >>> # Peer 200 >>> PublicKey = ### >>> AllowedIPs = 172.29.201.200/32 >>> >>> >>> -- Secondary Server -- >>> gui.wireguard.conf: >>> WIREGUARD_IP="172.29.202.254" >>> WIREGUARD_NM="255.255.255.0" >>> >>> wg0.peer: >>> [Peer] >>> # Peer 1 >>> PublicKey = ### >>> AllowedIPs = 172.29.202.1/32 >>> >>> [Peer] >>> # Peer 2 >>> PublicKey = ### >>> AllowedIPs = 172.29.202.2/32. ........> >>> >>> [Peer] >>> # Peer 200 >>> PublicKey = ### >>> AllowedIPs = 172.29.202.200/32 >>> >>> >>> -- Client -- >>> gui.wireguard.conf: >>> # This range is used for peers to us that we are a server e.g. satellite sites and users >>> WIREGUARD_IP="172.29.253.1" >>> WIREGUARD_NM="255.255.255.0" >>> >>> rc.elocal: >>> # Add Secondary IP Addresses to wg0 >>> ip addr add 172.29.200.1/24 dev wg0 >>> ip addr add 172.29.201.1/24 dev wg0 >>> ip addr add 172.29.202.1/24 dev wg0 >>> >>> wg0.peer: >>> [Peer] >>> # Management Server >>> PublicKey = ### >>> Endpoint = management01.ipcaccess.net >>> AllowedIPs = 172.29.200.254/32 >>> PersistentKeepalive = 25 >>> >>> [Peer] >>> # Primary Server >>> PublicKey = ### >>> Endpoint = primary01.ipcaccess.net >>> AllowedIPs = 172.29.201.254/32 >>> # No keepalive required as SIP Options ping will keep it up >>> >>> [Peer] >>> # Secondary Server >>> PublicKey = ### >>> Endpoint = secondary01.ipcaccess.net >>> AllowedIPs = 172.29.202.254/32 >>> # No keepalive required as SIP Options ping will keep it up >>> >>> [Peer] >>> # Another Astlinux box peering to us >>> PublicKey = ### >>> AllowedIPs = 172.29.253.2/32,<other accessible routes at the satellite site> >>> # No keepalive required as SIP Options ping will keep it up >>> -- >>> >>> Can anyone see problems with this configuration? >>> >>> Regards >>> Michael Knill >>> >>> From: David Kerr <da...@ke...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Tuesday, 1 January 2019 at 6:21 pm >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Multiple wg interfaces >>> >>> Michael, >>> A single wg interface can have multiple IP addresses. They can be different subnets too. You will have to manually edit the config files. >>> >>> David. >>> >>> On Tue, Jan 1, 2019 at 6:37 AM Michael Knill <mic...@ip...> wrote: >>>> Hi group >>>> >>>> Here is my scenario. I have primary and backup Wireguard VPN Peers that multiple Astlinux boxes will be connecting to. >>>> I assume that I will need different wgx interfaces for this as I cant have the same IP Address. >>>> If so, just wondering how to set this up in Astlinux? >>>> >>>> Regards >>>> Michael Knill >>>> _______________________________________________ >>>> Astlinux-users mailing list >>>> Ast...@li... >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>>> >>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >>> -- >>> David Kerr Sent from Gmail Mobile >>> _______________________________________________ >>> Astlinux-users mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... >> >> >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2019-06-09 03:29:28
|
Hi Lonnie
Sorry for the confusion. No I will have three separate servers, one purely for management and the other two are transit switches, one primary and one backup in case the primary fails.
The path the VPN takes will be completely up to the Astlinux configuration which may or may not have a failover route configured. Its actually a really neat solution whereby I don't care about any NAT or the path it takes and the testing I have done, Wireguard can fail back to the Primary route so quickly that it is unnoticeable when you are in a voice call. Very cool!
I have overcome having to reset Wireguard by adding it to the configuration and then adding the peer from the command line as follows:
wg set wg0 peer <Public key of Endpoint VPN Peer collected above> allowed-ips <Allocated Endpoint IP Address>/32
Seems to work fine. May be worthwhile adding it to the GUI.
As far as overlapping routes, the overlap is between individual customer Astlinux peers e.g. you could have a satellite office on 172.29.253.2/24 which overlaps with another customer Astlinux peer with the same address. This is not a problem of course unless they know about each other but this is a possibility for a multisite customer.
It also means that I cant standardise the VPN gateway address at each site for mobile peers e.g. 172.29.253.1 for site 1, 172.29.253.2 for site 2 etc.
None of this is insurmountable, just maybe not quite a neat as a Local /24 subnet for local peers and a separate subnet for the three upstream servers (not three separate subnets as I first mentioned).
So if I did have a secondary IP Address on the wg0 interface, would I need custom firewall rules?
Regards
Michael Knill
On 8/6/19, 11:20 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
A single /24 looks simpler to my eye ... very similar to how I do it myself.
> Hmm it certainly is unusual as there are overlapping routes everywhere but they just don't know about each other.
Overlapping routes ? I don't see any, all basically point-to-point in your internal WG 172.29.253.0/24 net, so far.
> It will certainly also get messy if Astlinux boxes peering to us are also peering to the 3 upstream servers.
Can you explain what you mean by "messy" ?
===
As an aside, I'm trying to think how the "clients" could be configured as "Mobile Clients" on one of the "servers". As it is now, adding or removing a "client" requires restarting WireGuard on each of the three servers to apply changes.
Michael, correct me if I am wrong, but your current parallel design:
client --|-- Primary
--|-- Secondary
--|-- Management
is to allow each 3 paths to go over different transports (PPPoE, Cable, 4G/LTE).
But, if you can cleverly use WAN Failover to swap network paths (PPPoE, Cable, 4G/LTE) using this layout:
client --|-- Primary --|-- Secondary
--|-- Management
In this case only the Primary server needs to know about the clients credentials, and *if* the clients only need a single WG IP address (no client LAN routing over WG) then clients could be auto-assigned "Mobile Client" credentials with IP's in the .101 to .199 range.
"Mobile Clients" can be added and removed in realtime without restarting WireGuard.
Lonnie
> On Jun 7, 2019, at 11:40 PM, Michael Knill <mic...@ip...> wrote:
>
> Thanks Lonnie
>
> Yes I'm replying to the original post and yes I do recall now talking about that.
> Hmm maybe I can just use a /24:
>
> -- All 3 upstream servers --
> gui.wireguard.conf:
> WIREGUARD_IP="172.29.253.[252|253|254]"
> WIREGUARD_NM="255.255.255.0"
>
> wg0.peer:
> [Peer]
> # Peer 1
> PublicKey = ###
> AllowedIPs = 172.29.253.1/32
>
> [Peer]
> # Peer 2
> PublicKey = ###
> AllowedIPs = 172.29.253.2/32 ........>
>
> [Peer]
> # Peer 100 (Note 101-199 used for Client peer's Remote Peers)
> PublicKey = ###
> AllowedIPs = 172.29.253.100/32
>
> -- Client --
> gui.wireguard.conf:
> WIREGUARD_IP="172.29.253.[1-100]"
> WIREGUARD_NM="255.255.255.0"
>
> wg0.peer:
> [Peer]
> # Management Server
> PublicKey = ###
> Endpoint = management01.ipcaccess.net
> AllowedIPs = 172.29.253.254/32
> PersistentKeepalive = 25
>
> [Peer]
> # Primary Server
> PublicKey = ###
> Endpoint = primary01.ipcaccess.net
> AllowedIPs = 172.29.253.253/32
> # No keepalive required as SIP Options ping will keep it up
>
> [Peer]
> # Secondary Server
> PublicKey = ###
> Endpoint = secondary01.ipcaccess.net
> AllowedIPs = 172.29.253.252/32
> # No keepalive required as SIP Options ping will keep it up
>
> [Peer]
> # Another Astlinux box peering to us
> PublicKey = ###
> AllowedIPs = 172.29.253.2/32,<other accessible routes at the satellite site>
> # No keepalive required as SIP Options ping will keep it up
> --
>
> Hmm it certainly is unusual as there are overlapping routes everywhere but they just don't know about each other. It will certainly also get messy if Astlinux boxes peering to us are also peering to the 3 upstream servers.
> So would Secondary addresses actually work if I did it purely for my sanity?
>
> Regards
> Michael Knill
>
> On 8/6/19, 12:33 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Michael,
>
> I seem to recall discussing this before, but why the 3 separate /24 networks requiring a rc.elocal rather than one /22 network set by the WG configs ?
>
> # netcalc 172.29.200.1/22
> Address : 172.29.200.1 10101100.00011101.110010 00.00000001
> Netmask : 255.255.252.0 = 22 11111111.11111111.111111 00.00000000
> Wildcard : 0.0.3.255 00000000.00000000.000000 11.11111111
> =>
> Network : 172.29.200.0/22 10101100.00011101.110010 00.00000000
> HostMin : 172.29.200.1 10101100.00011101.110010 00.00000001
> HostMax : 172.29.203.254 10101100.00011101.110010 11.11111110
> Broadcast: 172.29.203.255 10101100.00011101.110010 11.11111111
> Hosts/Net: 1022 Class B, Private network (RFC1918)
>
>
> Other than that, with only a quick glance, it looks like you understand the elegance of WireGuard.
>
> Also I see you noted:
> --
> # No keepalive required as SIP Options ping will keep it up
> --
> which is probably just fine, though there is not much added overhead if "PersistentKeepalive = 25" is also set possibly on the remote non-"SIP Options ping" peer, just something to file away in your mind.
>
> Lonnie
>
>
>
>> On Jun 7, 2019, at 8:57 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Hi Group
>>
>> I would like to bring this up again as I have begun development of a transit switch for my customers (using Astlinux).
>> The architecture will be both a primary and secondary server for the transit switch with regular synchronisation from Primary to Secondary. Both will have trunks to my upstream SIP provider with active/active redundancy.
>> All customer Astlinux boxes will connect via Wireguard VPN as a client to 3 servers being Primary Transit, Secondary Transit and a Management server (I would rather not manage through the Transit servers). The customer Astlinux box could also be a VPN server for other satellite sites and user Remote Peers.
>> Should this config work?
>>
>> -- Management Server --
>> gui.wireguard.conf:
>> WIREGUARD_IP="172.29.200.254"
>> WIREGUARD_NM="255.255.255.0"
>>
>> wg0.peer:
>> [Peer]
>> # Peer 1
>> PublicKey = ###
>> AllowedIPs = 172.29.200.1/32
>>
>> [Peer]
>> # Peer 2
>> PublicKey = ###
>> AllowedIPs = 172.29.200.2/32 ........>
>>
>> [Peer]
>> # Peer 200
>> PublicKey = ###
>> AllowedIPs = 172.29.200.200/32
>>
>>
>> -- Primary Server --
>> gui.wireguard.conf:
>> WIREGUARD_IP="172.29.201.254"
>> WIREGUARD_NM="255.255.255.0"
>>
>> wg0.peer:
>> [Peer]
>> # Peer 1
>> PublicKey = ###
>> AllowedIPs = 172.29.201.1/32
>>
>> [Peer]
>> # Peer 2
>> PublicKey = ###
>> AllowedIPs = 172.29.201.2/32 ........>
>>
>> [Peer]
>> # Peer 200
>> PublicKey = ###
>> AllowedIPs = 172.29.201.200/32
>>
>>
>> -- Secondary Server --
>> gui.wireguard.conf:
>> WIREGUARD_IP="172.29.202.254"
>> WIREGUARD_NM="255.255.255.0"
>>
>> wg0.peer:
>> [Peer]
>> # Peer 1
>> PublicKey = ###
>> AllowedIPs = 172.29.202.1/32
>>
>> [Peer]
>> # Peer 2
>> PublicKey = ###
>> AllowedIPs = 172.29.202.2/32. ........>
>>
>> [Peer]
>> # Peer 200
>> PublicKey = ###
>> AllowedIPs = 172.29.202.200/32
>>
>>
>> -- Client --
>> gui.wireguard.conf:
>> # This range is used for peers to us that we are a server e.g. satellite sites and users
>> WIREGUARD_IP="172.29.253.1"
>> WIREGUARD_NM="255.255.255.0"
>>
>> rc.elocal:
>> # Add Secondary IP Addresses to wg0
>> ip addr add 172.29.200.1/24 dev wg0
>> ip addr add 172.29.201.1/24 dev wg0
>> ip addr add 172.29.202.1/24 dev wg0
>>
>> wg0.peer:
>> [Peer]
>> # Management Server
>> PublicKey = ###
>> Endpoint = management01.ipcaccess.net
>> AllowedIPs = 172.29.200.254/32
>> PersistentKeepalive = 25
>>
>> [Peer]
>> # Primary Server
>> PublicKey = ###
>> Endpoint = primary01.ipcaccess.net
>> AllowedIPs = 172.29.201.254/32
>> # No keepalive required as SIP Options ping will keep it up
>>
>> [Peer]
>> # Secondary Server
>> PublicKey = ###
>> Endpoint = secondary01.ipcaccess.net
>> AllowedIPs = 172.29.202.254/32
>> # No keepalive required as SIP Options ping will keep it up
>>
>> [Peer]
>> # Another Astlinux box peering to us
>> PublicKey = ###
>> AllowedIPs = 172.29.253.2/32,<other accessible routes at the satellite site>
>> # No keepalive required as SIP Options ping will keep it up
>> --
>>
>> Can anyone see problems with this configuration?
>>
>> Regards
>> Michael Knill
>>
>> From: David Kerr <da...@ke...>
>> Reply-To: AstLinux List <ast...@li...>
>> Date: Tuesday, 1 January 2019 at 6:21 pm
>> To: AstLinux List <ast...@li...>
>> Subject: Re: [Astlinux-users] Multiple wg interfaces
>>
>> Michael,
>> A single wg interface can have multiple IP addresses. They can be different subnets too. You will have to manually edit the config files.
>>
>> David.
>>
>> On Tue, Jan 1, 2019 at 6:37 AM Michael Knill <mic...@ip...> wrote:
>>> Hi group
>>>
>>> Here is my scenario. I have primary and backup Wireguard VPN Peers that multiple Astlinux boxes will be connecting to.
>>> I assume that I will need different wgx interfaces for this as I cant have the same IP Address.
>>> If so, just wondering how to set this up in Astlinux?
>>>
>>> Regards
>>> Michael Knill
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>> --
>> David Kerr Sent from Gmail Mobile
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2019-06-08 13:20:16
|
Hi Michael,
A single /24 looks simpler to my eye ... very similar to how I do it myself.
> Hmm it certainly is unusual as there are overlapping routes everywhere but they just don't know about each other.
Overlapping routes ? I don't see any, all basically point-to-point in your internal WG 172.29.253.0/24 net, so far.
> It will certainly also get messy if Astlinux boxes peering to us are also peering to the 3 upstream servers.
Can you explain what you mean by "messy" ?
===
As an aside, I'm trying to think how the "clients" could be configured as "Mobile Clients" on one of the "servers". As it is now, adding or removing a "client" requires restarting WireGuard on each of the three servers to apply changes.
Michael, correct me if I am wrong, but your current parallel design:
client --|-- Primary
--|-- Secondary
--|-- Management
is to allow each 3 paths to go over different transports (PPPoE, Cable, 4G/LTE).
But, if you can cleverly use WAN Failover to swap network paths (PPPoE, Cable, 4G/LTE) using this layout:
client --|-- Primary --|-- Secondary
--|-- Management
In this case only the Primary server needs to know about the clients credentials, and *if* the clients only need a single WG IP address (no client LAN routing over WG) then clients could be auto-assigned "Mobile Client" credentials with IP's in the .101 to .199 range.
"Mobile Clients" can be added and removed in realtime without restarting WireGuard.
Lonnie
> On Jun 7, 2019, at 11:40 PM, Michael Knill <mic...@ip...> wrote:
>
> Thanks Lonnie
>
> Yes I'm replying to the original post and yes I do recall now talking about that.
> Hmm maybe I can just use a /24:
>
> -- All 3 upstream servers --
> gui.wireguard.conf:
> WIREGUARD_IP="172.29.253.[252|253|254]"
> WIREGUARD_NM="255.255.255.0"
>
> wg0.peer:
> [Peer]
> # Peer 1
> PublicKey = ###
> AllowedIPs = 172.29.253.1/32
>
> [Peer]
> # Peer 2
> PublicKey = ###
> AllowedIPs = 172.29.253.2/32 ........>
>
> [Peer]
> # Peer 100 (Note 101-199 used for Client peer's Remote Peers)
> PublicKey = ###
> AllowedIPs = 172.29.253.100/32
>
> -- Client --
> gui.wireguard.conf:
> WIREGUARD_IP="172.29.253.[1-100]"
> WIREGUARD_NM="255.255.255.0"
>
> wg0.peer:
> [Peer]
> # Management Server
> PublicKey = ###
> Endpoint = management01.ipcaccess.net
> AllowedIPs = 172.29.253.254/32
> PersistentKeepalive = 25
>
> [Peer]
> # Primary Server
> PublicKey = ###
> Endpoint = primary01.ipcaccess.net
> AllowedIPs = 172.29.253.253/32
> # No keepalive required as SIP Options ping will keep it up
>
> [Peer]
> # Secondary Server
> PublicKey = ###
> Endpoint = secondary01.ipcaccess.net
> AllowedIPs = 172.29.253.252/32
> # No keepalive required as SIP Options ping will keep it up
>
> [Peer]
> # Another Astlinux box peering to us
> PublicKey = ###
> AllowedIPs = 172.29.253.2/32,<other accessible routes at the satellite site>
> # No keepalive required as SIP Options ping will keep it up
> --
>
> Hmm it certainly is unusual as there are overlapping routes everywhere but they just don't know about each other. It will certainly also get messy if Astlinux boxes peering to us are also peering to the 3 upstream servers.
> So would Secondary addresses actually work if I did it purely for my sanity?
>
> Regards
> Michael Knill
>
> On 8/6/19, 12:33 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Michael,
>
> I seem to recall discussing this before, but why the 3 separate /24 networks requiring a rc.elocal rather than one /22 network set by the WG configs ?
>
> # netcalc 172.29.200.1/22
> Address : 172.29.200.1 10101100.00011101.110010 00.00000001
> Netmask : 255.255.252.0 = 22 11111111.11111111.111111 00.00000000
> Wildcard : 0.0.3.255 00000000.00000000.000000 11.11111111
> =>
> Network : 172.29.200.0/22 10101100.00011101.110010 00.00000000
> HostMin : 172.29.200.1 10101100.00011101.110010 00.00000001
> HostMax : 172.29.203.254 10101100.00011101.110010 11.11111110
> Broadcast: 172.29.203.255 10101100.00011101.110010 11.11111111
> Hosts/Net: 1022 Class B, Private network (RFC1918)
>
>
> Other than that, with only a quick glance, it looks like you understand the elegance of WireGuard.
>
> Also I see you noted:
> --
> # No keepalive required as SIP Options ping will keep it up
> --
> which is probably just fine, though there is not much added overhead if "PersistentKeepalive = 25" is also set possibly on the remote non-"SIP Options ping" peer, just something to file away in your mind.
>
> Lonnie
>
>
>
>> On Jun 7, 2019, at 8:57 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Hi Group
>>
>> I would like to bring this up again as I have begun development of a transit switch for my customers (using Astlinux).
>> The architecture will be both a primary and secondary server for the transit switch with regular synchronisation from Primary to Secondary. Both will have trunks to my upstream SIP provider with active/active redundancy.
>> All customer Astlinux boxes will connect via Wireguard VPN as a client to 3 servers being Primary Transit, Secondary Transit and a Management server (I would rather not manage through the Transit servers). The customer Astlinux box could also be a VPN server for other satellite sites and user Remote Peers.
>> Should this config work?
>>
>> -- Management Server --
>> gui.wireguard.conf:
>> WIREGUARD_IP="172.29.200.254"
>> WIREGUARD_NM="255.255.255.0"
>>
>> wg0.peer:
>> [Peer]
>> # Peer 1
>> PublicKey = ###
>> AllowedIPs = 172.29.200.1/32
>>
>> [Peer]
>> # Peer 2
>> PublicKey = ###
>> AllowedIPs = 172.29.200.2/32 ........>
>>
>> [Peer]
>> # Peer 200
>> PublicKey = ###
>> AllowedIPs = 172.29.200.200/32
>>
>>
>> -- Primary Server --
>> gui.wireguard.conf:
>> WIREGUARD_IP="172.29.201.254"
>> WIREGUARD_NM="255.255.255.0"
>>
>> wg0.peer:
>> [Peer]
>> # Peer 1
>> PublicKey = ###
>> AllowedIPs = 172.29.201.1/32
>>
>> [Peer]
>> # Peer 2
>> PublicKey = ###
>> AllowedIPs = 172.29.201.2/32 ........>
>>
>> [Peer]
>> # Peer 200
>> PublicKey = ###
>> AllowedIPs = 172.29.201.200/32
>>
>>
>> -- Secondary Server --
>> gui.wireguard.conf:
>> WIREGUARD_IP="172.29.202.254"
>> WIREGUARD_NM="255.255.255.0"
>>
>> wg0.peer:
>> [Peer]
>> # Peer 1
>> PublicKey = ###
>> AllowedIPs = 172.29.202.1/32
>>
>> [Peer]
>> # Peer 2
>> PublicKey = ###
>> AllowedIPs = 172.29.202.2/32. ........>
>>
>> [Peer]
>> # Peer 200
>> PublicKey = ###
>> AllowedIPs = 172.29.202.200/32
>>
>>
>> -- Client --
>> gui.wireguard.conf:
>> # This range is used for peers to us that we are a server e.g. satellite sites and users
>> WIREGUARD_IP="172.29.253.1"
>> WIREGUARD_NM="255.255.255.0"
>>
>> rc.elocal:
>> # Add Secondary IP Addresses to wg0
>> ip addr add 172.29.200.1/24 dev wg0
>> ip addr add 172.29.201.1/24 dev wg0
>> ip addr add 172.29.202.1/24 dev wg0
>>
>> wg0.peer:
>> [Peer]
>> # Management Server
>> PublicKey = ###
>> Endpoint = management01.ipcaccess.net
>> AllowedIPs = 172.29.200.254/32
>> PersistentKeepalive = 25
>>
>> [Peer]
>> # Primary Server
>> PublicKey = ###
>> Endpoint = primary01.ipcaccess.net
>> AllowedIPs = 172.29.201.254/32
>> # No keepalive required as SIP Options ping will keep it up
>>
>> [Peer]
>> # Secondary Server
>> PublicKey = ###
>> Endpoint = secondary01.ipcaccess.net
>> AllowedIPs = 172.29.202.254/32
>> # No keepalive required as SIP Options ping will keep it up
>>
>> [Peer]
>> # Another Astlinux box peering to us
>> PublicKey = ###
>> AllowedIPs = 172.29.253.2/32,<other accessible routes at the satellite site>
>> # No keepalive required as SIP Options ping will keep it up
>> --
>>
>> Can anyone see problems with this configuration?
>>
>> Regards
>> Michael Knill
>>
>> From: David Kerr <da...@ke...>
>> Reply-To: AstLinux List <ast...@li...>
>> Date: Tuesday, 1 January 2019 at 6:21 pm
>> To: AstLinux List <ast...@li...>
>> Subject: Re: [Astlinux-users] Multiple wg interfaces
>>
>> Michael,
>> A single wg interface can have multiple IP addresses. They can be different subnets too. You will have to manually edit the config files.
>>
>> David.
>>
>> On Tue, Jan 1, 2019 at 6:37 AM Michael Knill <mic...@ip...> wrote:
>>> Hi group
>>>
>>> Here is my scenario. I have primary and backup Wireguard VPN Peers that multiple Astlinux boxes will be connecting to.
>>> I assume that I will need different wgx interfaces for this as I cant have the same IP Address.
>>> If so, just wondering how to set this up in Astlinux?
>>>
>>> Regards
>>> Michael Knill
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>> --
>> David Kerr Sent from Gmail Mobile
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Michael K. <mic...@ip...> - 2019-06-08 04:55:14
|
Thanks Lonnie Yes I'm replying to the original post and yes I do recall now talking about that. Hmm maybe I can just use a /24: -- All 3 upstream servers -- gui.wireguard.conf: WIREGUARD_IP="172.29.253.[252|253|254]" WIREGUARD_NM="255.255.255.0" wg0.peer: [Peer] # Peer 1 PublicKey = ### AllowedIPs = 172.29.253.1/32 [Peer] # Peer 2 PublicKey = ### AllowedIPs = 172.29.253.2/32 ........> [Peer] # Peer 100 (Note 101-199 used for Client peer's Remote Peers) PublicKey = ### AllowedIPs = 172.29.253.100/32 -- Client -- gui.wireguard.conf: WIREGUARD_IP="172.29.253.[1-100]" WIREGUARD_NM="255.255.255.0" wg0.peer: [Peer] # Management Server PublicKey = ### Endpoint = management01.ipcaccess.net AllowedIPs = 172.29.253.254/32 PersistentKeepalive = 25 [Peer] # Primary Server PublicKey = ### Endpoint = primary01.ipcaccess.net AllowedIPs = 172.29.253.253/32 # No keepalive required as SIP Options ping will keep it up [Peer] # Secondary Server PublicKey = ### Endpoint = secondary01.ipcaccess.net AllowedIPs = 172.29.253.252/32 # No keepalive required as SIP Options ping will keep it up [Peer] # Another Astlinux box peering to us PublicKey = ### AllowedIPs = 172.29.253.2/32,<other accessible routes at the satellite site> # No keepalive required as SIP Options ping will keep it up -- Hmm it certainly is unusual as there are overlapping routes everywhere but they just don't know about each other. It will certainly also get messy if Astlinux boxes peering to us are also peering to the 3 upstream servers. So would Secondary addresses actually work if I did it purely for my sanity? Regards Michael Knill On 8/6/19, 12:33 pm, "Lonnie Abelbeck" <li...@lo...> wrote: Hi Michael, I seem to recall discussing this before, but why the 3 separate /24 networks requiring a rc.elocal rather than one /22 network set by the WG configs ? # netcalc 172.29.200.1/22 Address : 172.29.200.1 10101100.00011101.110010 00.00000001 Netmask : 255.255.252.0 = 22 11111111.11111111.111111 00.00000000 Wildcard : 0.0.3.255 00000000.00000000.000000 11.11111111 => Network : 172.29.200.0/22 10101100.00011101.110010 00.00000000 HostMin : 172.29.200.1 10101100.00011101.110010 00.00000001 HostMax : 172.29.203.254 10101100.00011101.110010 11.11111110 Broadcast: 172.29.203.255 10101100.00011101.110010 11.11111111 Hosts/Net: 1022 Class B, Private network (RFC1918) Other than that, with only a quick glance, it looks like you understand the elegance of WireGuard. Also I see you noted: -- # No keepalive required as SIP Options ping will keep it up -- which is probably just fine, though there is not much added overhead if "PersistentKeepalive = 25" is also set possibly on the remote non-"SIP Options ping" peer, just something to file away in your mind. Lonnie > On Jun 7, 2019, at 8:57 PM, Michael Knill <mic...@ip...> wrote: > > Hi Group > > I would like to bring this up again as I have begun development of a transit switch for my customers (using Astlinux). > The architecture will be both a primary and secondary server for the transit switch with regular synchronisation from Primary to Secondary. Both will have trunks to my upstream SIP provider with active/active redundancy. > All customer Astlinux boxes will connect via Wireguard VPN as a client to 3 servers being Primary Transit, Secondary Transit and a Management server (I would rather not manage through the Transit servers). The customer Astlinux box could also be a VPN server for other satellite sites and user Remote Peers. > Should this config work? > > -- Management Server -- > gui.wireguard.conf: > WIREGUARD_IP="172.29.200.254" > WIREGUARD_NM="255.255.255.0" > > wg0.peer: > [Peer] > # Peer 1 > PublicKey = ### > AllowedIPs = 172.29.200.1/32 > > [Peer] > # Peer 2 > PublicKey = ### > AllowedIPs = 172.29.200.2/32 ........> > > [Peer] > # Peer 200 > PublicKey = ### > AllowedIPs = 172.29.200.200/32 > > > -- Primary Server -- > gui.wireguard.conf: > WIREGUARD_IP="172.29.201.254" > WIREGUARD_NM="255.255.255.0" > > wg0.peer: > [Peer] > # Peer 1 > PublicKey = ### > AllowedIPs = 172.29.201.1/32 > > [Peer] > # Peer 2 > PublicKey = ### > AllowedIPs = 172.29.201.2/32 ........> > > [Peer] > # Peer 200 > PublicKey = ### > AllowedIPs = 172.29.201.200/32 > > > -- Secondary Server -- > gui.wireguard.conf: > WIREGUARD_IP="172.29.202.254" > WIREGUARD_NM="255.255.255.0" > > wg0.peer: > [Peer] > # Peer 1 > PublicKey = ### > AllowedIPs = 172.29.202.1/32 > > [Peer] > # Peer 2 > PublicKey = ### > AllowedIPs = 172.29.202.2/32. ........> > > [Peer] > # Peer 200 > PublicKey = ### > AllowedIPs = 172.29.202.200/32 > > > -- Client -- > gui.wireguard.conf: > # This range is used for peers to us that we are a server e.g. satellite sites and users > WIREGUARD_IP="172.29.253.1" > WIREGUARD_NM="255.255.255.0" > > rc.elocal: > # Add Secondary IP Addresses to wg0 > ip addr add 172.29.200.1/24 dev wg0 > ip addr add 172.29.201.1/24 dev wg0 > ip addr add 172.29.202.1/24 dev wg0 > > wg0.peer: > [Peer] > # Management Server > PublicKey = ### > Endpoint = management01.ipcaccess.net > AllowedIPs = 172.29.200.254/32 > PersistentKeepalive = 25 > > [Peer] > # Primary Server > PublicKey = ### > Endpoint = primary01.ipcaccess.net > AllowedIPs = 172.29.201.254/32 > # No keepalive required as SIP Options ping will keep it up > > [Peer] > # Secondary Server > PublicKey = ### > Endpoint = secondary01.ipcaccess.net > AllowedIPs = 172.29.202.254/32 > # No keepalive required as SIP Options ping will keep it up > > [Peer] > # Another Astlinux box peering to us > PublicKey = ### > AllowedIPs = 172.29.253.2/32,<other accessible routes at the satellite site> > # No keepalive required as SIP Options ping will keep it up > -- > > Can anyone see problems with this configuration? > > Regards > Michael Knill > > From: David Kerr <da...@ke...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 1 January 2019 at 6:21 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Multiple wg interfaces > > Michael, > A single wg interface can have multiple IP addresses. They can be different subnets too. You will have to manually edit the config files. > > David. > > On Tue, Jan 1, 2019 at 6:37 AM Michael Knill <mic...@ip...> wrote: >> Hi group >> >> Here is my scenario. I have primary and backup Wireguard VPN Peers that multiple Astlinux boxes will be connecting to. >> I assume that I will need different wgx interfaces for this as I cant have the same IP Address. >> If so, just wondering how to set this up in Astlinux? >> >> Regards >> Michael Knill >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > -- > David Kerr Sent from Gmail Mobile > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... _______________________________________________ Astlinux-users mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Lonnie A. <li...@lo...> - 2019-06-08 02:33:14
|
Hi Michael, I seem to recall discussing this before, but why the 3 separate /24 networks requiring a rc.elocal rather than one /22 network set by the WG configs ? # netcalc 172.29.200.1/22 Address : 172.29.200.1 10101100.00011101.110010 00.00000001 Netmask : 255.255.252.0 = 22 11111111.11111111.111111 00.00000000 Wildcard : 0.0.3.255 00000000.00000000.000000 11.11111111 => Network : 172.29.200.0/22 10101100.00011101.110010 00.00000000 HostMin : 172.29.200.1 10101100.00011101.110010 00.00000001 HostMax : 172.29.203.254 10101100.00011101.110010 11.11111110 Broadcast: 172.29.203.255 10101100.00011101.110010 11.11111111 Hosts/Net: 1022 Class B, Private network (RFC1918) Other than that, with only a quick glance, it looks like you understand the elegance of WireGuard. Also I see you noted: -- # No keepalive required as SIP Options ping will keep it up -- which is probably just fine, though there is not much added overhead if "PersistentKeepalive = 25" is also set possibly on the remote non-"SIP Options ping" peer, just something to file away in your mind. Lonnie > On Jun 7, 2019, at 8:57 PM, Michael Knill <mic...@ip...> wrote: > > Hi Group > > I would like to bring this up again as I have begun development of a transit switch for my customers (using Astlinux). > The architecture will be both a primary and secondary server for the transit switch with regular synchronisation from Primary to Secondary. Both will have trunks to my upstream SIP provider with active/active redundancy. > All customer Astlinux boxes will connect via Wireguard VPN as a client to 3 servers being Primary Transit, Secondary Transit and a Management server (I would rather not manage through the Transit servers). The customer Astlinux box could also be a VPN server for other satellite sites and user Remote Peers. > Should this config work? > > -- Management Server -- > gui.wireguard.conf: > WIREGUARD_IP="172.29.200.254" > WIREGUARD_NM="255.255.255.0" > > wg0.peer: > [Peer] > # Peer 1 > PublicKey = ### > AllowedIPs = 172.29.200.1/32 > > [Peer] > # Peer 2 > PublicKey = ### > AllowedIPs = 172.29.200.2/32 ........> > > [Peer] > # Peer 200 > PublicKey = ### > AllowedIPs = 172.29.200.200/32 > > > -- Primary Server -- > gui.wireguard.conf: > WIREGUARD_IP="172.29.201.254" > WIREGUARD_NM="255.255.255.0" > > wg0.peer: > [Peer] > # Peer 1 > PublicKey = ### > AllowedIPs = 172.29.201.1/32 > > [Peer] > # Peer 2 > PublicKey = ### > AllowedIPs = 172.29.201.2/32 ........> > > [Peer] > # Peer 200 > PublicKey = ### > AllowedIPs = 172.29.201.200/32 > > > -- Secondary Server -- > gui.wireguard.conf: > WIREGUARD_IP="172.29.202.254" > WIREGUARD_NM="255.255.255.0" > > wg0.peer: > [Peer] > # Peer 1 > PublicKey = ### > AllowedIPs = 172.29.202.1/32 > > [Peer] > # Peer 2 > PublicKey = ### > AllowedIPs = 172.29.202.2/32. ........> > > [Peer] > # Peer 200 > PublicKey = ### > AllowedIPs = 172.29.202.200/32 > > > -- Client -- > gui.wireguard.conf: > # This range is used for peers to us that we are a server e.g. satellite sites and users > WIREGUARD_IP="172.29.253.1" > WIREGUARD_NM="255.255.255.0" > > rc.elocal: > # Add Secondary IP Addresses to wg0 > ip addr add 172.29.200.1/24 dev wg0 > ip addr add 172.29.201.1/24 dev wg0 > ip addr add 172.29.202.1/24 dev wg0 > > wg0.peer: > [Peer] > # Management Server > PublicKey = ### > Endpoint = management01.ipcaccess.net > AllowedIPs = 172.29.200.254/32 > PersistentKeepalive = 25 > > [Peer] > # Primary Server > PublicKey = ### > Endpoint = primary01.ipcaccess.net > AllowedIPs = 172.29.201.254/32 > # No keepalive required as SIP Options ping will keep it up > > [Peer] > # Secondary Server > PublicKey = ### > Endpoint = secondary01.ipcaccess.net > AllowedIPs = 172.29.202.254/32 > # No keepalive required as SIP Options ping will keep it up > > [Peer] > # Another Astlinux box peering to us > PublicKey = ### > AllowedIPs = 172.29.253.2/32,<other accessible routes at the satellite site> > # No keepalive required as SIP Options ping will keep it up > -- > > Can anyone see problems with this configuration? > > Regards > Michael Knill > > From: David Kerr <da...@ke...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 1 January 2019 at 6:21 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Multiple wg interfaces > > Michael, > A single wg interface can have multiple IP addresses. They can be different subnets too. You will have to manually edit the config files. > > David. > > On Tue, Jan 1, 2019 at 6:37 AM Michael Knill <mic...@ip...> wrote: >> Hi group >> >> Here is my scenario. I have primary and backup Wireguard VPN Peers that multiple Astlinux boxes will be connecting to. >> I assume that I will need different wgx interfaces for this as I cant have the same IP Address. >> If so, just wondering how to set this up in Astlinux? >> >> Regards >> Michael Knill >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > -- > David Kerr Sent from Gmail Mobile > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2019-06-08 01:57:30
|
Hi Group I would like to bring this up again as I have begun development of a transit switch for my customers (using Astlinux). The architecture will be both a primary and secondary server for the transit switch with regular synchronisation from Primary to Secondary. Both will have trunks to my upstream SIP provider with active/active redundancy. All customer Astlinux boxes will connect via Wireguard VPN as a client to 3 servers being Primary Transit, Secondary Transit and a Management server (I would rather not manage through the Transit servers). The customer Astlinux box could also be a VPN server for other satellite sites and user Remote Peers. Should this config work? -- Management Server -- gui.wireguard.conf: WIREGUARD_IP="172.29.200.254" WIREGUARD_NM="255.255.255.0" wg0.peer: [Peer] # Peer 1 PublicKey = ### AllowedIPs = 172.29.200.1/32 [Peer] # Peer 2 PublicKey = ### AllowedIPs = 172.29.200.2/32 ........> [Peer] # Peer 200 PublicKey = ### AllowedIPs = 172.29.200.200/32 -- Primary Server -- gui.wireguard.conf: WIREGUARD_IP="172.29.201.254" WIREGUARD_NM="255.255.255.0" wg0.peer: [Peer] # Peer 1 PublicKey = ### AllowedIPs = 172.29.201.1/32 [Peer] # Peer 2 PublicKey = ### AllowedIPs = 172.29.201.2/32 ........> [Peer] # Peer 200 PublicKey = ### AllowedIPs = 172.29.201.200/32 -- Secondary Server -- gui.wireguard.conf: WIREGUARD_IP="172.29.202.254" WIREGUARD_NM="255.255.255.0" wg0.peer: [Peer] # Peer 1 PublicKey = ### AllowedIPs = 172.29.202.1/32 [Peer] # Peer 2 PublicKey = ### AllowedIPs = 172.29.202.2/32. ........> [Peer] # Peer 200 PublicKey = ### AllowedIPs = 172.29.202.200/32 -- Client -- gui.wireguard.conf: # This range is used for peers to us that we are a server e.g. satellite sites and users WIREGUARD_IP="172.29.253.1" WIREGUARD_NM="255.255.255.0" rc.elocal: # Add Secondary IP Addresses to wg0 ip addr add 172.29.200.1/24 dev wg0 ip addr add 172.29.201.1/24 dev wg0 ip addr add 172.29.202.1/24 dev wg0 wg0.peer: [Peer] # Management Server PublicKey = ### Endpoint = management01.ipcaccess.net AllowedIPs = 172.29.200.254/32 PersistentKeepalive = 25 [Peer] # Primary Server PublicKey = ### Endpoint = primary01.ipcaccess.net AllowedIPs = 172.29.201.254/32 # No keepalive required as SIP Options ping will keep it up [Peer] # Secondary Server PublicKey = ### Endpoint = secondary01.ipcaccess.net AllowedIPs = 172.29.202.254/32 # No keepalive required as SIP Options ping will keep it up [Peer] # Another Astlinux box peering to us PublicKey = ### AllowedIPs = 172.29.253.2/32,<other accessible routes at the satellite site> # No keepalive required as SIP Options ping will keep it up -- Can anyone see problems with this configuration? Regards Michael Knill From: David Kerr <da...@ke...> Reply-To: AstLinux List <ast...@li...> Date: Tuesday, 1 January 2019 at 6:21 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Multiple wg interfaces Michael, A single wg interface can have multiple IP addresses. They can be different subnets too. You will have to manually edit the config files. David. On Tue, Jan 1, 2019 at 6:37 AM Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote: Hi group Here is my scenario. I have primary and backup Wireguard VPN Peers that multiple Astlinux boxes will be connecting to. I assume that I will need different wgx interfaces for this as I cant have the same IP Address. If so, just wondering how to set this up in Astlinux? Regards Michael Knill _______________________________________________ Astlinux-users mailing list Ast...@li...<mailto:Ast...@li...> https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto:pa...@kr...>. -- David Kerr Sent from Gmail Mobile |
|
From: Lonnie A. <li...@lo...> - 2019-06-04 19:59:25
|
Hi David, > But this thread has got me interested in a related topic, and that is getting a gateway device on which I could run VMware ESXi and then run Astlinux in that. The same box could then also run some other VM's (for e.g. Ubiquiti UniFi Controller, PiHole, whatever). Right now I am running Unifi inside a VM on QEMU on Astlinux (a custom build) but it might make sense to move to ESXi. Excellent idea. Learning how to manage a VM host is a good skill to have. From my research people have successfully run VMware ESXi and Proxmox on the HPE MicroServer which has 4 actual cores (no hyper-threading) and AMD has fewer side-channel exploit issues than Intel. Though for CPU performance, even my Qotom i3-6100U tests slightly over 2x of the AMD X3421 ... the i7-7500U would be faster but possibly pushing the heat dissipation rate of the case. The Qotom's extra NIC's could be useful if they can be passed native to a VM guest, an Intel i211 NIC pcie card could be added to the MicroServer if extra NIC's are needed. The MicroServer clearly wins on disk options with good cooling, the single Qotom 2.5" SSD could get cooked inside the i7 case ... a mSATA disk would even get hotter. The MicroServer supports up to 32 GB of RAM, the Qotom is 16 GB max. Though 8 GB should get you started. I really don't know which box would provide the better VM Host server ... I'm sure others here have more experience than I. Lonnie > On Jun 4, 2019, at 1:22 PM, David Kerr <da...@ke...> wrote: > > So on the surface this looks attractive, but on further investigation I think its better to separate my NAS requirements from my Firewall/Phone. This box has pretty basic RAID capabilities and the HDDs are not hot swappable. I'm also not sure I want my NAS on the same box as my network gateway... if power goes out I want to run my gateway for as long as possible on the UPS, whereas I am happy to let my NAS shutdown and power off for duration of the power outage (which sadly are quite frequent for me). > > But this thread has got me interested in a related topic, and that is getting a gateway device on which I could run VMware ESXi and then run Astlinux in that. The same box could then also run some other VM's (for e.g. Ubiquiti UniFi Controller, PiHole, whatever). Right now I am running Unifi inside a VM on QEMU on Astlinux (a custom build) but it might make sense to move to ESXi. > > I'm wondering if the Qotom boxes are good enough for ESXi. I just came across a 6th gen i7 version with 6 NIC's... Q575G6. Looks new, so not locally stocked yet -- would have to come from china. > > David > > On Mon, Jun 3, 2019 at 6:37 PM Michael Knill <mic...@ip...> wrote: > Hmm interesting. Firewall, Phone and NAS all in one box! > > Regards > Michael Knill > > On 4/6/19, 8:19 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > The MicroServer includes basic hardware RAID (0,1,10 IIRC) support using a Marvell chip > -- > 01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9230 PCIe SATA 6Gb/s Controller (rev 11) > -- > At BIOS boot you can type Control-M to configure the builtin hardware RAID. I did not play with this. > > For serious NAS applications a SAS PCIe card and SAS drives would probably be the way to go. This overview video did that https://www.youtube.com/watch?v=v3QQBHIjtGI > > Lonnie > > > > > On Jun 3, 2019, at 5:06 PM, David Kerr <da...@ke...> wrote: > > > > This box is begging for RAID support across the 4 drive bays. How would you suggest going about that? > > > > David > > > > On Mon, Jun 3, 2019 at 5:20 PM Lonnie Abelbeck <li...@lo...> wrote: > > A newly released hardware description and configuration has been added to the AstLinux documentation: > > > > HPE ProLiant MicroServer Gen10 AMD X3421 > > https://doc.astlinux-project.org/userdoc:board_hpe_microserver_x3421 > > > > I personally purchased a HPE ProLiant MicroServer Gen10 (Model: P04923-S01) (8G RAM, No SSD) via Amazon: > > > > HPE ProLiant Microserver Gen10 ... > > https://www.amazon.com/gp/product/B07DFPDRV8/ > > > > $329.00 USD -- Solution Model: P04923-S01, AMD X3421 CPU, 4-core @2.1 GHz, 8G RAM > > > > $ 8.00 USD -- ORICO 2.5 to 3.5 Hard Drive Adapter HDD SSD Mounting Bracket Tray (32GB SSD laying around) > > > > $ 0.00 USD -- Shipping (Included) > > > > First you might ask, a 9" cube with 4 drive bays, this is not a typical AstLinux hardware description ... yes you are correct. The reason this box caught my eye was several fold: > > > > 1) Good value with 8G DDR4 RAM included, puts the barebone board/case/power-supply price at around $200 USD. > > 2) Can run AstLinux either bare-metal or as a guest VM with a hypervisor on the MicroServer. Start a project bare-metal and transition to a VM later if needed. > > 3) Widely obtainable, backed by HP Enterprise and should have a long run on ebay as the years go by. > > 4) Good reviews [1] (and FYI Overview Video [2]). > > > > The MicroServer's AMD X3421 performance falls between the faster Qotom Q530G6 (Core i3-6100U) and slower Qotom Q190G4N-S07 (Celeron J1900). About 3x the performance of a PC Engines APU2. > > > > The power consumption is relatively low for this kind of box, idles at 16 W. And runs cool at idle, k10temp reports 23 degC CPU (measured on the board, not CPU core) (ambient temp is 22 degC / 72 degF). The large but quiet fan is overkill for a bare-metal AstLinux install. > > > > The HPE MicroServer offers: > > -- Lots of configuration options. > > -- Supports Video (VGA) Console > > -- Supports 2.5" SSD (with 2.5" to 3.5" tray) > > -- 2x Broadcom NetXtreme BCM5720 NIC's > > -- 2x PCIe low-profile slots > > -- Power button > > > > The MicroServer requires DDR4 RAM, dual 288-pin UDIMM's, 8GB to 32GB supported. > > > > No surprise, line-speed 1Gbps network routing and line-speed WireGuard VPN with 50% headroom. > > > > The HPE MicroServer Gen10 X3421 has run solidly for a few days, further updates as needed. > > > > Lonnie > > > > [1] Review https://www.servethehome.com/hpe-proliant-microserver-gen10-review/ > > > > [2] Overview Video https://www.youtube.com/watch?v=v3QQBHIjtGI > > > > > > > > > > _______________________________________________ > > Astlinux-users mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > _______________________________________________ > > Astlinux-users mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: David K. <da...@ke...> - 2019-06-04 18:48:03
|
So on the surface this looks attractive, but on further investigation I think its better to separate my NAS requirements from my Firewall/Phone. This box has pretty basic RAID capabilities and the HDDs are not hot swappable. I'm also not sure I want my NAS on the same box as my network gateway... if power goes out I want to run my gateway for as long as possible on the UPS, whereas I am happy to let my NAS shutdown and power off for duration of the power outage (which sadly are quite frequent for me). But this thread has got me interested in a related topic, and that is getting a gateway device on which I could run VMware ESXi and then run Astlinux in that. The same box could then also run some other VM's (for e.g. Ubiquiti UniFi Controller, PiHole, whatever). Right now I am running Unifi inside a VM on QEMU on Astlinux (a custom build) but it might make sense to move to ESXi. I'm wondering if the Qotom boxes are good enough for ESXi. I just came across a 6th gen i7 version with 6 NIC's... Q575G6. Looks new, so not locally stocked yet -- would have to come from china. David On Mon, Jun 3, 2019 at 6:37 PM Michael Knill < mic...@ip...> wrote: > Hmm interesting. Firewall, Phone and NAS all in one box! > > Regards > Michael Knill > > On 4/6/19, 8:19 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > The MicroServer includes basic hardware RAID (0,1,10 IIRC) support > using a Marvell chip > -- > 01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9230 PCIe > SATA 6Gb/s Controller (rev 11) > -- > At BIOS boot you can type Control-M to configure the builtin hardware > RAID. I did not play with this. > > For serious NAS applications a SAS PCIe card and SAS drives would > probably be the way to go. This overview video did that > https://www.youtube.com/watch?v=v3QQBHIjtGI > > Lonnie > > > > > On Jun 3, 2019, at 5:06 PM, David Kerr <da...@ke...> wrote: > > > > This box is begging for RAID support across the 4 drive bays. How > would you suggest going about that? > > > > David > > > > On Mon, Jun 3, 2019 at 5:20 PM Lonnie Abelbeck < > li...@lo...> wrote: > > A newly released hardware description and configuration has been > added to the AstLinux documentation: > > > > HPE ProLiant MicroServer Gen10 AMD X3421 > > https://doc.astlinux-project.org/userdoc:board_hpe_microserver_x3421 > > > > I personally purchased a HPE ProLiant MicroServer Gen10 (Model: > P04923-S01) (8G RAM, No SSD) via Amazon: > > > > HPE ProLiant Microserver Gen10 ... > > https://www.amazon.com/gp/product/B07DFPDRV8/ > > > > $329.00 USD -- Solution Model: P04923-S01, AMD X3421 CPU, 4-core > @2.1 GHz, 8G RAM > > > > $ 8.00 USD -- ORICO 2.5 to 3.5 Hard Drive Adapter HDD SSD Mounting > Bracket Tray (32GB SSD laying around) > > > > $ 0.00 USD -- Shipping (Included) > > > > First you might ask, a 9" cube with 4 drive bays, this is not a > typical AstLinux hardware description ... yes you are correct. The reason > this box caught my eye was several fold: > > > > 1) Good value with 8G DDR4 RAM included, puts the barebone > board/case/power-supply price at around $200 USD. > > 2) Can run AstLinux either bare-metal or as a guest VM with a > hypervisor on the MicroServer. Start a project bare-metal and transition > to a VM later if needed. > > 3) Widely obtainable, backed by HP Enterprise and should have a long > run on ebay as the years go by. > > 4) Good reviews [1] (and FYI Overview Video [2]). > > > > The MicroServer's AMD X3421 performance falls between the faster > Qotom Q530G6 (Core i3-6100U) and slower Qotom Q190G4N-S07 (Celeron J1900). > About 3x the performance of a PC Engines APU2. > > > > The power consumption is relatively low for this kind of box, idles > at 16 W. And runs cool at idle, k10temp reports 23 degC CPU (measured on > the board, not CPU core) (ambient temp is 22 degC / 72 degF). The large > but quiet fan is overkill for a bare-metal AstLinux install. > > > > The HPE MicroServer offers: > > -- Lots of configuration options. > > -- Supports Video (VGA) Console > > -- Supports 2.5" SSD (with 2.5" to 3.5" tray) > > -- 2x Broadcom NetXtreme BCM5720 NIC's > > -- 2x PCIe low-profile slots > > -- Power button > > > > The MicroServer requires DDR4 RAM, dual 288-pin UDIMM's, 8GB to 32GB > supported. > > > > No surprise, line-speed 1Gbps network routing and line-speed > WireGuard VPN with 50% headroom. > > > > The HPE MicroServer Gen10 X3421 has run solidly for a few days, > further updates as needed. > > > > Lonnie > > > > [1] Review > https://www.servethehome.com/hpe-proliant-microserver-gen10-review/ > > > > [2] Overview Video https://www.youtube.com/watch?v=v3QQBHIjtGI > > > > > > > > > > _______________________________________________ > > Astlinux-users mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > _______________________________________________ > > Astlinux-users mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2019-06-03 22:37:16
|
Hmm interesting. Firewall, Phone and NAS all in one box!
Regards
Michael Knill
On 4/6/19, 8:19 am, "Lonnie Abelbeck" <li...@lo...> wrote:
The MicroServer includes basic hardware RAID (0,1,10 IIRC) support using a Marvell chip
--
01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9230 PCIe SATA 6Gb/s Controller (rev 11)
--
At BIOS boot you can type Control-M to configure the builtin hardware RAID. I did not play with this.
For serious NAS applications a SAS PCIe card and SAS drives would probably be the way to go. This overview video did that https://www.youtube.com/watch?v=v3QQBHIjtGI
Lonnie
> On Jun 3, 2019, at 5:06 PM, David Kerr <da...@ke...> wrote:
>
> This box is begging for RAID support across the 4 drive bays. How would you suggest going about that?
>
> David
>
> On Mon, Jun 3, 2019 at 5:20 PM Lonnie Abelbeck <li...@lo...> wrote:
> A newly released hardware description and configuration has been added to the AstLinux documentation:
>
> HPE ProLiant MicroServer Gen10 AMD X3421
> https://doc.astlinux-project.org/userdoc:board_hpe_microserver_x3421
>
> I personally purchased a HPE ProLiant MicroServer Gen10 (Model: P04923-S01) (8G RAM, No SSD) via Amazon:
>
> HPE ProLiant Microserver Gen10 ...
> https://www.amazon.com/gp/product/B07DFPDRV8/
>
> $329.00 USD -- Solution Model: P04923-S01, AMD X3421 CPU, 4-core @2.1 GHz, 8G RAM
>
> $ 8.00 USD -- ORICO 2.5 to 3.5 Hard Drive Adapter HDD SSD Mounting Bracket Tray (32GB SSD laying around)
>
> $ 0.00 USD -- Shipping (Included)
>
> First you might ask, a 9" cube with 4 drive bays, this is not a typical AstLinux hardware description ... yes you are correct. The reason this box caught my eye was several fold:
>
> 1) Good value with 8G DDR4 RAM included, puts the barebone board/case/power-supply price at around $200 USD.
> 2) Can run AstLinux either bare-metal or as a guest VM with a hypervisor on the MicroServer. Start a project bare-metal and transition to a VM later if needed.
> 3) Widely obtainable, backed by HP Enterprise and should have a long run on ebay as the years go by.
> 4) Good reviews [1] (and FYI Overview Video [2]).
>
> The MicroServer's AMD X3421 performance falls between the faster Qotom Q530G6 (Core i3-6100U) and slower Qotom Q190G4N-S07 (Celeron J1900). About 3x the performance of a PC Engines APU2.
>
> The power consumption is relatively low for this kind of box, idles at 16 W. And runs cool at idle, k10temp reports 23 degC CPU (measured on the board, not CPU core) (ambient temp is 22 degC / 72 degF). The large but quiet fan is overkill for a bare-metal AstLinux install.
>
> The HPE MicroServer offers:
> -- Lots of configuration options.
> -- Supports Video (VGA) Console
> -- Supports 2.5" SSD (with 2.5" to 3.5" tray)
> -- 2x Broadcom NetXtreme BCM5720 NIC's
> -- 2x PCIe low-profile slots
> -- Power button
>
> The MicroServer requires DDR4 RAM, dual 288-pin UDIMM's, 8GB to 32GB supported.
>
> No surprise, line-speed 1Gbps network routing and line-speed WireGuard VPN with 50% headroom.
>
> The HPE MicroServer Gen10 X3421 has run solidly for a few days, further updates as needed.
>
> Lonnie
>
> [1] Review https://www.servethehome.com/hpe-proliant-microserver-gen10-review/
>
> [2] Overview Video https://www.youtube.com/watch?v=v3QQBHIjtGI
>
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2019-06-03 22:19:38
|
The MicroServer includes basic hardware RAID (0,1,10 IIRC) support using a Marvell chip -- 01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9230 PCIe SATA 6Gb/s Controller (rev 11) -- At BIOS boot you can type Control-M to configure the builtin hardware RAID. I did not play with this. For serious NAS applications a SAS PCIe card and SAS drives would probably be the way to go. This overview video did that https://www.youtube.com/watch?v=v3QQBHIjtGI Lonnie > On Jun 3, 2019, at 5:06 PM, David Kerr <da...@ke...> wrote: > > This box is begging for RAID support across the 4 drive bays. How would you suggest going about that? > > David > > On Mon, Jun 3, 2019 at 5:20 PM Lonnie Abelbeck <li...@lo...> wrote: > A newly released hardware description and configuration has been added to the AstLinux documentation: > > HPE ProLiant MicroServer Gen10 AMD X3421 > https://doc.astlinux-project.org/userdoc:board_hpe_microserver_x3421 > > I personally purchased a HPE ProLiant MicroServer Gen10 (Model: P04923-S01) (8G RAM, No SSD) via Amazon: > > HPE ProLiant Microserver Gen10 ... > https://www.amazon.com/gp/product/B07DFPDRV8/ > > $329.00 USD -- Solution Model: P04923-S01, AMD X3421 CPU, 4-core @2.1 GHz, 8G RAM > > $ 8.00 USD -- ORICO 2.5 to 3.5 Hard Drive Adapter HDD SSD Mounting Bracket Tray (32GB SSD laying around) > > $ 0.00 USD -- Shipping (Included) > > First you might ask, a 9" cube with 4 drive bays, this is not a typical AstLinux hardware description ... yes you are correct. The reason this box caught my eye was several fold: > > 1) Good value with 8G DDR4 RAM included, puts the barebone board/case/power-supply price at around $200 USD. > 2) Can run AstLinux either bare-metal or as a guest VM with a hypervisor on the MicroServer. Start a project bare-metal and transition to a VM later if needed. > 3) Widely obtainable, backed by HP Enterprise and should have a long run on ebay as the years go by. > 4) Good reviews [1] (and FYI Overview Video [2]). > > The MicroServer's AMD X3421 performance falls between the faster Qotom Q530G6 (Core i3-6100U) and slower Qotom Q190G4N-S07 (Celeron J1900). About 3x the performance of a PC Engines APU2. > > The power consumption is relatively low for this kind of box, idles at 16 W. And runs cool at idle, k10temp reports 23 degC CPU (measured on the board, not CPU core) (ambient temp is 22 degC / 72 degF). The large but quiet fan is overkill for a bare-metal AstLinux install. > > The HPE MicroServer offers: > -- Lots of configuration options. > -- Supports Video (VGA) Console > -- Supports 2.5" SSD (with 2.5" to 3.5" tray) > -- 2x Broadcom NetXtreme BCM5720 NIC's > -- 2x PCIe low-profile slots > -- Power button > > The MicroServer requires DDR4 RAM, dual 288-pin UDIMM's, 8GB to 32GB supported. > > No surprise, line-speed 1Gbps network routing and line-speed WireGuard VPN with 50% headroom. > > The HPE MicroServer Gen10 X3421 has run solidly for a few days, further updates as needed. > > Lonnie > > [1] Review https://www.servethehome.com/hpe-proliant-microserver-gen10-review/ > > [2] Overview Video https://www.youtube.com/watch?v=v3QQBHIjtGI > > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: David K. <da...@ke...> - 2019-06-03 22:06:59
|
This box is begging for RAID support across the 4 drive bays. How would you suggest going about that? David On Mon, Jun 3, 2019 at 5:20 PM Lonnie Abelbeck <li...@lo...> wrote: > A newly released hardware description and configuration has been added to > the AstLinux documentation: > > HPE ProLiant MicroServer Gen10 AMD X3421 > https://doc.astlinux-project.org/userdoc:board_hpe_microserver_x3421 > > I personally purchased a HPE ProLiant MicroServer Gen10 (Model: > P04923-S01) (8G RAM, No SSD) via Amazon: > > HPE ProLiant Microserver Gen10 ... > https://www.amazon.com/gp/product/B07DFPDRV8/ > > $329.00 USD -- Solution Model: P04923-S01, AMD X3421 CPU, 4-core @2.1 GHz, > 8G RAM > > $ 8.00 USD -- ORICO 2.5 to 3.5 Hard Drive Adapter HDD SSD Mounting > Bracket Tray (32GB SSD laying around) > > $ 0.00 USD -- Shipping (Included) > > First you might ask, a 9" cube with 4 drive bays, this is not a typical > AstLinux hardware description ... yes you are correct. The reason this box > caught my eye was several fold: > > 1) Good value with 8G DDR4 RAM included, puts the barebone > board/case/power-supply price at around $200 USD. > 2) Can run AstLinux either bare-metal or as a guest VM with a hypervisor > on the MicroServer. Start a project bare-metal and transition to a VM > later if needed. > 3) Widely obtainable, backed by HP Enterprise and should have a long run > on ebay as the years go by. > 4) Good reviews [1] (and FYI Overview Video [2]). > > The MicroServer's AMD X3421 performance falls between the faster Qotom > Q530G6 (Core i3-6100U) and slower Qotom Q190G4N-S07 (Celeron J1900). About > 3x the performance of a PC Engines APU2. > > The power consumption is relatively low for this kind of box, idles at 16 > W. And runs cool at idle, k10temp reports 23 degC CPU (measured on the > board, not CPU core) (ambient temp is 22 degC / 72 degF). The large but > quiet fan is overkill for a bare-metal AstLinux install. > > The HPE MicroServer offers: > -- Lots of configuration options. > -- Supports Video (VGA) Console > -- Supports 2.5" SSD (with 2.5" to 3.5" tray) > -- 2x Broadcom NetXtreme BCM5720 NIC's > -- 2x PCIe low-profile slots > -- Power button > > The MicroServer requires DDR4 RAM, dual 288-pin UDIMM's, 8GB to 32GB > supported. > > No surprise, line-speed 1Gbps network routing and line-speed WireGuard VPN > with 50% headroom. > > The HPE MicroServer Gen10 X3421 has run solidly for a few days, further > updates as needed. > > Lonnie > > [1] Review > https://www.servethehome.com/hpe-proliant-microserver-gen10-review/ > > [2] Overview Video https://www.youtube.com/watch?v=v3QQBHIjtGI > > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > |
|
From: Lonnie A. <li...@lo...> - 2019-06-03 21:19:58
|
A newly released hardware description and configuration has been added to the AstLinux documentation: HPE ProLiant MicroServer Gen10 AMD X3421 https://doc.astlinux-project.org/userdoc:board_hpe_microserver_x3421 I personally purchased a HPE ProLiant MicroServer Gen10 (Model: P04923-S01) (8G RAM, No SSD) via Amazon: HPE ProLiant Microserver Gen10 ... https://www.amazon.com/gp/product/B07DFPDRV8/ $329.00 USD -- Solution Model: P04923-S01, AMD X3421 CPU, 4-core @2.1 GHz, 8G RAM $ 8.00 USD -- ORICO 2.5 to 3.5 Hard Drive Adapter HDD SSD Mounting Bracket Tray (32GB SSD laying around) $ 0.00 USD -- Shipping (Included) First you might ask, a 9" cube with 4 drive bays, this is not a typical AstLinux hardware description ... yes you are correct. The reason this box caught my eye was several fold: 1) Good value with 8G DDR4 RAM included, puts the barebone board/case/power-supply price at around $200 USD. 2) Can run AstLinux either bare-metal or as a guest VM with a hypervisor on the MicroServer. Start a project bare-metal and transition to a VM later if needed. 3) Widely obtainable, backed by HP Enterprise and should have a long run on ebay as the years go by. 4) Good reviews [1] (and FYI Overview Video [2]). The MicroServer's AMD X3421 performance falls between the faster Qotom Q530G6 (Core i3-6100U) and slower Qotom Q190G4N-S07 (Celeron J1900). About 3x the performance of a PC Engines APU2. The power consumption is relatively low for this kind of box, idles at 16 W. And runs cool at idle, k10temp reports 23 degC CPU (measured on the board, not CPU core) (ambient temp is 22 degC / 72 degF). The large but quiet fan is overkill for a bare-metal AstLinux install. The HPE MicroServer offers: -- Lots of configuration options. -- Supports Video (VGA) Console -- Supports 2.5" SSD (with 2.5" to 3.5" tray) -- 2x Broadcom NetXtreme BCM5720 NIC's -- 2x PCIe low-profile slots -- Power button The MicroServer requires DDR4 RAM, dual 288-pin UDIMM's, 8GB to 32GB supported. No surprise, line-speed 1Gbps network routing and line-speed WireGuard VPN with 50% headroom. The HPE MicroServer Gen10 X3421 has run solidly for a few days, further updates as needed. Lonnie [1] Review https://www.servethehome.com/hpe-proliant-microserver-gen10-review/ [2] Overview Video https://www.youtube.com/watch?v=v3QQBHIjtGI |
|
From: Michael K. <li...@mk...> - 2019-04-27 11:28:09
|
> Am 27.04.2019 um 08:27 schrieb Michael Knill <mic...@ip...>: > > Sorry! Far out. I'm obviously too tired to be doing this now. > This is the correct site: > 3055-CWP-CM1 kd # /usr/sbin/pppoe-status > pppoe-status: Link is down (can't read pppd PID file /var/run/pppoe.conf-adsl.pid.pppd) > > 3055-CWP-CM1 kd # /usr/sbin/pppoe-restart > pppoe-stop: No PPPoE connection appears to be running > ................TIMED OUT > /usr/sbin/pppoe-start: line 193: 31414 Terminated $CONNECT "$@" > /dev/null 2>&1 > > Any other things I should try? Yes, the restart delay: ## The PPPoE restart delay (in seconds) between pppoe-stop and pppoe-start for a pppoe-restart. ## Defaults to 2 seconds when not defined, some ISP's may require a much longer delay. #PPPOE_RESTART_DELAY=2 I have some providers where I need to use 120 or even 180 seconds delay. I used that so that I restarted the PPPoE conection at let's say 03:00 in the night, so that the ISP didn't reconnect during business time. > Regards > Michael Knill > > On 27/4/19, 4:21 pm, "Michael Knill" <mic...@ip...> wrote: > > Ok I have a site with 'No pppoe-status available'. > 3999-IPCBuild-CM1 etc # /usr/sbin/pppoe-status > /usr/sbin/pppoe-status: Cannot read configuration file '/etc/ppp/pppoe.conf' > > /tmp/etc/ppp is not there. > > 3999-IPCBuild-CM1 sbin # pppoe-restart > pppoe-stop: Cannot read configuration file '/etc/ppp/pppoe.conf' > pppoe-restart: PPPoE not enabled. > > reboot appears to be the only thing that fixes it. > > Any other things I should try? > > Regards > Michael Knill > > On 26/3/19, 11:38 pm, "Michael Keuter" <li...@mk...> wrote: > > >> Am 26.03.2019 um 01:59 schrieb Michael Knill <mic...@ip...>: >> >> Hi Group >> >> I have an annoying problem where the PPPoE Connection Status: on the Status Tab shows as no connection status available but PPPoE is working fine. >> It needs a system reboot to fix the problem. >> >> Any ideas? >> >> Regards >> Michael Knill > > Hi Michael, > > I had the same issue years ago as well (in those scenarios). This might be a timing issue in the PPPoE software (usr/sbin/pppoe-staus) after a manual/scripted PPPoE restart or when the ISP forced a reconnect and the line is not up again within a specific timeframe. > > Michael > > http://www.mksolutions.info > > > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2019-04-27 06:27:15
|
Sorry! Far out. I'm obviously too tired to be doing this now.
This is the correct site:
3055-CWP-CM1 kd # /usr/sbin/pppoe-status
pppoe-status: Link is down (can't read pppd PID file /var/run/pppoe.conf-adsl.pid.pppd)
3055-CWP-CM1 kd # /usr/sbin/pppoe-restart
pppoe-stop: No PPPoE connection appears to be running
................TIMED OUT
/usr/sbin/pppoe-start: line 193: 31414 Terminated $CONNECT "$@" > /dev/null 2>&1
Any other things I should try?
Regards
Michael Knill
On 27/4/19, 4:21 pm, "Michael Knill" <mic...@ip...> wrote:
Ok I have a site with 'No pppoe-status available'.
3999-IPCBuild-CM1 etc # /usr/sbin/pppoe-status
/usr/sbin/pppoe-status: Cannot read configuration file '/etc/ppp/pppoe.conf'
/tmp/etc/ppp is not there.
3999-IPCBuild-CM1 sbin # pppoe-restart
pppoe-stop: Cannot read configuration file '/etc/ppp/pppoe.conf'
pppoe-restart: PPPoE not enabled.
reboot appears to be the only thing that fixes it.
Any other things I should try?
Regards
Michael Knill
On 26/3/19, 11:38 pm, "Michael Keuter" <li...@mk...> wrote:
> Am 26.03.2019 um 01:59 schrieb Michael Knill <mic...@ip...>:
>
> Hi Group
>
> I have an annoying problem where the PPPoE Connection Status: on the Status Tab shows as no connection status available but PPPoE is working fine.
> It needs a system reboot to fix the problem.
>
> Any ideas?
>
> Regards
> Michael Knill
Hi Michael,
I had the same issue years ago as well (in those scenarios). This might be a timing issue in the PPPoE software (usr/sbin/pppoe-staus) after a manual/scripted PPPoE restart or when the ISP forced a reconnect and the line is not up again within a specific timeframe.
Michael
http://www.mksolutions.info
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Michael K. <mic...@ip...> - 2019-04-27 06:21:31
|
Ok I have a site with 'No pppoe-status available'.
3999-IPCBuild-CM1 etc # /usr/sbin/pppoe-status
/usr/sbin/pppoe-status: Cannot read configuration file '/etc/ppp/pppoe.conf'
/tmp/etc/ppp is not there.
3999-IPCBuild-CM1 sbin # pppoe-restart
pppoe-stop: Cannot read configuration file '/etc/ppp/pppoe.conf'
pppoe-restart: PPPoE not enabled.
reboot appears to be the only thing that fixes it.
Any other things I should try?
Regards
Michael Knill
On 26/3/19, 11:38 pm, "Michael Keuter" <li...@mk...> wrote:
> Am 26.03.2019 um 01:59 schrieb Michael Knill <mic...@ip...>:
>
> Hi Group
>
> I have an annoying problem where the PPPoE Connection Status: on the Status Tab shows as no connection status available but PPPoE is working fine.
> It needs a system reboot to fix the problem.
>
> Any ideas?
>
> Regards
> Michael Knill
Hi Michael,
I had the same issue years ago as well (in those scenarios). This might be a timing issue in the PPPoE software (usr/sbin/pppoe-staus) after a manual/scripted PPPoE restart or when the ISP forced a reconnect and the line is not up again within a specific timeframe.
Michael
http://www.mksolutions.info
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2019-04-19 18:50:55
|
Announcing Pre-Release Version: astlinux-1.3-4181-610913 The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own. -- Asterisk 11.x, no longer included, officially EOL 2017-10-25 -- Asterisk 13.23.1 (new '13se' version) Older than latest Asterisk 13.x version but more tested, built --without-pjproject -- Asterisk 13.26.0 (version bump) and 16.3.0 (new version) Adds: res_mwi_devstate.so, MWI Device State Subscriptions -- Linux Kernel 3.16.64, security and bug fixes. -- busybox, *major* version bump to 1.30.1, security and bug fixes. -- WireGuard VPN, version bump to 0.0.20190406 -- ne, new package, version 3.1.2, the nice editor, alternative to nano ne is easy to use for the beginner, but powerful and fully configurable for the wizard. Includes syntax checking for: asterisk, conf, ini, perl, sh More Info: http://ne.di.unimi.it/ -- Complete Pre-Release ChangeLog: https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt Updated Documentation Topics: Asterisk LTS Series Version - - https://doc.astlinux-project.org/userdoc:tt_asterisk_upgrade_version 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 New "Development" tab feature for desktop browsers: Guest VM x86-64bit ISO: Download Pre-Release Guest VM Install ISO (Video Console) AstLinux Team |
63 messages has been excluded from this view by a project administrator.
