astlinux-users — AstLinux Users Mailing List

Re: [Astlinux-users] SIP Options ping not working

[Michael K. <mic...@ip...>]

And yes good test. Of course a firewall restart does not clear translations.
Am I able to clear firewall translations without waiting for them to time out which is what I assume you are doing here?
It would have to be dome from a remote session as well e.g. through the firewall.

Regards
Michael Knill

On 4/7/18, 10:41 pm, "Lonnie Abelbeck" <li...@lo...> wrote:

    > So my questions are:
    > • Is tcpdump BEFORE the firewall?
    
    For incoming packets tcpdump is before the firewall, for outgoing packets tcpdump is after the firewall, ie.
    --
    wire -> NIC -> tcpdump -> netfilter/firewall
    
    netfilter/firewall -> tcpdump -> NIC -> wire
    --
    so tcpdump does not see outbound packets blocked by the firewall.
    
    
    > • What tests should I do next?
    
    Have you ever tried ...
    --
    service asterisk stop
    sleep 90
    service asterisk init
    --
    
    
    Lonnie
    
    
    
    
    
    > On Jul 3, 2018, at 10:19 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > Back to the ongoing saga of SIP Options ping not working. This one is a bit different though. Here is the scenario:
    >  
    > 	• Can SSH into box fine and network connectivity is fine
    > 	• Find IP Address based SIP Trunk is UNREACHABLE. Can ping provider from the box
    > 	• Asterisk SIP Debug shows SIP Options sent but none received. This is also the case using tcpdump on the ppp0 interface
    > 	• Asterisk reload and Firewall restart did not fix the problem. The system needed a full reboot for the trunk to be REACHABLE
    >  
    > So my questions are:
    > 	• Is tcpdump BEFORE the firewall?
    > 	• Can you think of what the issue could be?
    > 	• What tests should I do next?
    >  
    > Unfortunately (or fortunately) this happens very infrequently so the fix will be a long confirmation period.
    >  
    > Thanks all!
    >  
    > Regards
    > Michael Knill
    > ------------------------------------------------------------------------------
    > Check out the vibrant tech community on one of the world's most
    > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
    > 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....
    
    
    ------------------------------------------------------------------------------
    Check out the vibrant tech community on one of the world's most
    engaging tech sites, Slashdot.org! http://sdm.link/slashdot
    _______________________________________________
    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....

Re: [Astlinux-users] SIP Options ping not working

[Michael K. <mic...@ip...>]

Thanks Lonnie. Great info to know.
Its still a bit of a mystery though as I was seeing the outbound packet with tcpdump so it had passed the firewall, but did not see the return packet!

Regards
Michael Knill

On 4/7/18, 10:41 pm, "Lonnie Abelbeck" <li...@lo...> wrote:

    > So my questions are:
    > • Is tcpdump BEFORE the firewall?
    
    For incoming packets tcpdump is before the firewall, for outgoing packets tcpdump is after the firewall, ie.
    --
    wire -> NIC -> tcpdump -> netfilter/firewall
    
    netfilter/firewall -> tcpdump -> NIC -> wire
    --
    so tcpdump does not see outbound packets blocked by the firewall.
    
    
    > • What tests should I do next?
    
    Have you ever tried ...
    --
    service asterisk stop
    sleep 90
    service asterisk init
    --
    
    
    Lonnie
    
    
    
    
    
    > On Jul 3, 2018, at 10:19 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > Back to the ongoing saga of SIP Options ping not working. This one is a bit different though. Here is the scenario:
    >  
    > 	• Can SSH into box fine and network connectivity is fine
    > 	• Find IP Address based SIP Trunk is UNREACHABLE. Can ping provider from the box
    > 	• Asterisk SIP Debug shows SIP Options sent but none received. This is also the case using tcpdump on the ppp0 interface
    > 	• Asterisk reload and Firewall restart did not fix the problem. The system needed a full reboot for the trunk to be REACHABLE
    >  
    > So my questions are:
    > 	• Is tcpdump BEFORE the firewall?
    > 	• Can you think of what the issue could be?
    > 	• What tests should I do next?
    >  
    > Unfortunately (or fortunately) this happens very infrequently so the fix will be a long confirmation period.
    >  
    > Thanks all!
    >  
    > Regards
    > Michael Knill
    > ------------------------------------------------------------------------------
    > Check out the vibrant tech community on one of the world's most
    > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
    > 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....
    
    
    ------------------------------------------------------------------------------
    Check out the vibrant tech community on one of the world's most
    engaging tech sites, Slashdot.org! http://sdm.link/slashdot
    _______________________________________________
    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....

Re: [Astlinux-users] SIP Options ping not working

[Lonnie A. <li...@lo...>]

> So my questions are:
> • Is tcpdump BEFORE the firewall?

For incoming packets tcpdump is before the firewall, for outgoing packets tcpdump is after the firewall, ie.
--
wire -> NIC -> tcpdump -> netfilter/firewall

netfilter/firewall -> tcpdump -> NIC -> wire
--
so tcpdump does not see outbound packets blocked by the firewall.


> • What tests should I do next?

Have you ever tried ...
--
service asterisk stop
sleep 90
service asterisk init
--


Lonnie





> On Jul 3, 2018, at 10:19 PM, Michael Knill <mic...@ip...> wrote:
> 
> Back to the ongoing saga of SIP Options ping not working. This one is a bit different though. Here is the scenario:
>  
> 	• Can SSH into box fine and network connectivity is fine
> 	• Find IP Address based SIP Trunk is UNREACHABLE. Can ping provider from the box
> 	• Asterisk SIP Debug shows SIP Options sent but none received. This is also the case using tcpdump on the ppp0 interface
> 	• Asterisk reload and Firewall restart did not fix the problem. The system needed a full reboot for the trunk to be REACHABLE
>  
> So my questions are:
> 	• Is tcpdump BEFORE the firewall?
> 	• Can you think of what the issue could be?
> 	• What tests should I do next?
>  
> Unfortunately (or fortunately) this happens very infrequently so the fix will be a long confirmation period.
>  
> Thanks all!
>  
> Regards
> Michael Knill
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> 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] SIP Options ping not working

[Michael K. <mic...@ip...>]

Back to the ongoing saga of SIP Options ping not working. This one is a bit different though. Here is the scenario:


  *   Can SSH into box fine and network connectivity is fine
  *   Find IP Address based SIP Trunk is UNREACHABLE. Can ping provider from the box
  *   Asterisk SIP Debug shows SIP Options sent but none received. This is also the case using tcpdump on the ppp0 interface
  *   Asterisk reload and Firewall restart did not fix the problem. The system needed a full reboot for the trunk to be REACHABLE

So my questions are:

  1.  Is tcpdump BEFORE the firewall?
  2.  Can you think of what the issue could be?
  3.  What tests should I do next?

Unfortunately (or fortunately) this happens very infrequently so the fix will be a long confirmation period.

Thanks all!

Regards
Michael Knill

Re: [Astlinux-users] Using WAN Failover for Astlinux High Availability

[Michael K. <mic...@ip...>]

Yes that could be used too although it would require lots more testing.

Regards
Michael Knill

From: Michael Keuter <li...@mk...>
Reply-To: AstLinux List <ast...@li...>
Date: Monday, 2 July 2018 at 8:51 am
To: AstLinux List <ast...@li...>
Subject: Re: [Astlinux-users] Using WAN Failover for Astlinux High Availability



Am 02.07.2018 um 00:12 schrieb Michael Knill <mic...@ip...<mailto:mic...@ip...>>:

Hi Michael

Sorry I probably shouldn't have called it HA as that is more as you described. Maybe it would be better calling it System Failover instead.
Keeping them in sync should be pretty easy and I can just exclude files that are different. I would make the failover time fairly long so it only did it when it was truly broken. The failover script would enable the interfaces which are addressed the same as the primary. Management would be via a separate interface.

So do you think it could work with WAN Failover?

Needs to be tested very thoroughly.
Maybe the clients will cache not only the IP-address of the server, but also the MAC-address.

Another approach would could be the "Server 1" + "Server 2" option, that many IP-phones offer (never tested it though), to get around the IP-address problematic:

[cid:AF8...@pr...]


Regards
Michael Knill

On 1/7/18, 9:07 pm, "Michael Keuter" <li...@mk...<mailto:li...@mk...>> wrote:



Am 01.07.2018 um 01:42 schrieb Michael Knill <mic...@ip...<mailto:mic...@ip...>>:

Hi Group

Tell me if I am totally off track but I have been wondering for a while how I can do Astlinux HA e.g. having a primary and standby box
So what do you need for this:
• Monitoring of the primary Astlinux server
• Run a script if connectivity lost
• Some sort of timers to prevent flapping
• Email notification to indicate that it has occurred
• Config sync between the two

When I considered the list, isn’t 1) to 4) actually already available with WAN Failover? Your monitor IP is the address of the other box?
Can you failover to the same interface?

Interesting thought!

Regards
Michael Knill

   Hi Michael,

   for "real" HA clusters usually a "Virtual IP" is used (where the SIP clients connect to), which is then "switched" to to real IP of the actice node.
   For Linux there are a few solutions:

   https://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol
   https://github.com/jedisct1/UCarp  (though the "ucarp.org<http://ucarp.org>" domain seem to now go to some Asian site)
   https://serverfault.com/questions/276170/alternatives-to-heartbeat-pacemaker-and-corosync

   I also got requests from a few customers a while ago, and we found it simpler just to use 2 identical boxes configure them the equally and put one offline in the shelf.
   In case of problem just switch the boxes.
   The only issue is to keep the boxes in sync (because both have the same IP).
   We used rsync to a server share, switched of the actice box for a few minutes afterhours and occacionally synced the offline box to that (we excluded a few hardware/MAC related files).
   You also can give them 2 different IPs, and change the IP in case of a problem.

   But to be honest: I do Asterisk/AstLinux stuff since 2007, but except an old water damage case (with only one net5501 under water that survived, but not the internal ISDN PCI card), I never had an issue that an AstLinux box broke and we really needed the Failover, except for testing, that it actually works as expected :-).
   In all other problem cases either the power was down, the ISP/internet connection was down/had issues or the SIP provider had problems :-).

   Michael

Michael

http://www.mksolutions.info

Re: [Astlinux-users] Using WAN Failover for Astlinux High Availability

[Michael K. <li...@mk...>]

> Am 02.07.2018 um 00:12 schrieb Michael Knill <mic...@ip...>:
> 
> Hi Michael
> 
> Sorry I probably shouldn't have called it HA as that is more as you described. Maybe it would be better calling it System Failover instead.
> Keeping them in sync should be pretty easy and I can just exclude files that are different. I would make the failover time fairly long so it only did it when it was truly broken. The failover script would enable the interfaces which are addressed the same as the primary. Management would be via a separate interface.
> 
> So do you think it could work with WAN Failover?

Needs to be tested very thoroughly.
Maybe the clients will cache not only the IP-address of the server, but also the MAC-address.

Another approach would could be the "Server 1" + "Server 2" option, that many IP-phones offer (never tested it though), to get around the IP-address problematic:



> Regards
> Michael Knill
> 
> On 1/7/18, 9:07 pm, "Michael Keuter" <li...@mk...> wrote:
> 
> 
>> Am 01.07.2018 um 01:42 schrieb Michael Knill <mic...@ip...>:
>> 
>> Hi Group
>> 
>> Tell me if I am totally off track but I have been wondering for a while how I can do Astlinux HA e.g. having a primary and standby box
>> So what do you need for this:
>> 	• Monitoring of the primary Astlinux server
>> 	• Run a script if connectivity lost
>> 	• Some sort of timers to prevent flapping
>> 	• Email notification to indicate that it has occurred
>> 	• Config sync between the two
>> 
>> When I considered the list, isn’t 1) to 4) actually already available with WAN Failover? Your monitor IP is the address of the other box?
>> Can you failover to the same interface?
>> 
>> Interesting thought!
>> 
>> Regards
>> Michael Knill
> 
>    Hi Michael,
> 
>    for "real" HA clusters usually a "Virtual IP" is used (where the SIP clients connect to), which is then "switched" to to real IP of the actice node.
>    For Linux there are a few solutions:
> 
>    https://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol
>    https://github.com/jedisct1/UCarp  (though the "ucarp.org" domain seem to now go to some Asian site)
>    https://serverfault.com/questions/276170/alternatives-to-heartbeat-pacemaker-and-corosync
> 
>    I also got requests from a few customers a while ago, and we found it simpler just to use 2 identical boxes configure them the equally and put one offline in the shelf.
>    In case of problem just switch the boxes. 
>    The only issue is to keep the boxes in sync (because both have the same IP). 
>    We used rsync to a server share, switched of the actice box for a few minutes afterhours and occacionally synced the offline box to that (we excluded a few hardware/MAC related files). 
>    You also can give them 2 different IPs, and change the IP in case of a problem.
> 
>    But to be honest: I do Asterisk/AstLinux stuff since 2007, but except an old water damage case (with only one net5501 under water that survived, but not the internal ISDN PCI card), I never had an issue that an AstLinux box broke and we really needed the Failover, except for testing, that it actually works as expected :-).
>    In all other problem cases either the power was down, the ISP/internet connection was down/had issues or the SIP provider had problems :-).
> 
>    Michael

Michael

http://www.mksolutions.info

Re: [Astlinux-users] Using WAN Failover for Astlinux High Availability

[Michael K. <mic...@ip...>]

Hi Michael

Sorry I probably shouldn't have called it HA as that is more as you described. Maybe it would be better calling it System Failover instead.
Keeping them in sync should be pretty easy and I can just exclude files that are different. I would make the failover time fairly long so it only did it when it was truly broken. The failover script would enable the interfaces which are addressed the same as the primary. Management would be via a separate interface.

So do you think it could work with WAN Failover?

Regards
Michael Knill

On 1/7/18, 9:07 pm, "Michael Keuter" <li...@mk...> wrote:

    
    > Am 01.07.2018 um 01:42 schrieb Michael Knill <mic...@ip...>:
    > 
    > Hi Group
    >  
    > Tell me if I am totally off track but I have been wondering for a while how I can do Astlinux HA e.g. having a primary and standby box
    > So what do you need for this:
    > 	• Monitoring of the primary Astlinux server
    > 	• Run a script if connectivity lost
    > 	• Some sort of timers to prevent flapping
    > 	• Email notification to indicate that it has occurred
    > 	• Config sync between the two
    >  
    > When I considered the list, isn’t 1) to 4) actually already available with WAN Failover? Your monitor IP is the address of the other box?
    > Can you failover to the same interface?
    >  
    > Interesting thought!
    >  
    > Regards
    > Michael Knill
    
    Hi Michael,
    
    for "real" HA clusters usually a "Virtual IP" is used (where the SIP clients connect to), which is then "switched" to to real IP of the actice node.
    For Linux there are a few solutions:
    
    https://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol
    https://github.com/jedisct1/UCarp  (though the "ucarp.org" domain seem to now go to some Asian site)
    https://serverfault.com/questions/276170/alternatives-to-heartbeat-pacemaker-and-corosync
    
    I also got requests from a few customers a while ago, and we found it simpler just to use 2 identical boxes configure them the equally and put one offline in the shelf.
    In case of problem just switch the boxes. 
    The only issue is to keep the boxes in sync (because both have the same IP). 
    We used rsync to a server share, switched of the actice box for a few minutes afterhours and occacionally synced the offline box to that (we excluded a few hardware/MAC related files). 
    You also can give them 2 different IPs, and change the IP in case of a problem.
    
    But to be honest: I do Asterisk/AstLinux stuff since 2007, but except an old water damage case (with only one net5501 under water that survived, but not the internal ISDN PCI card), I never had an issue that an AstLinux box broke and we really needed the Failover, except for testing, that it actually works as expected :-).
    In all other problem cases either the power was down, the ISP/internet connection was down/had issues or the SIP provider had problems :-).
    
    Michael
    
    http://www.mksolutions.info
    
    
    
    
    ------------------------------------------------------------------------------
    Check out the vibrant tech community on one of the world's most
    engaging tech sites, Slashdot.org! http://sdm.link/slashdot
    _______________________________________________
    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....

Re: [Astlinux-users] Using WAN Failover for Astlinux High Availability

[Michael K. <li...@mk...>]

> Am 01.07.2018 um 01:42 schrieb Michael Knill <mic...@ip...>:
> 
> Hi Group
>  
> Tell me if I am totally off track but I have been wondering for a while how I can do Astlinux HA e.g. having a primary and standby box
> So what do you need for this:
> 	• Monitoring of the primary Astlinux server
> 	• Run a script if connectivity lost
> 	• Some sort of timers to prevent flapping
> 	• Email notification to indicate that it has occurred
> 	• Config sync between the two
>  
> When I considered the list, isn’t 1) to 4) actually already available with WAN Failover? Your monitor IP is the address of the other box?
> Can you failover to the same interface?
>  
> Interesting thought!
>  
> Regards
> Michael Knill

Hi Michael,

for "real" HA clusters usually a "Virtual IP" is used (where the SIP clients connect to), which is then "switched" to to real IP of the actice node.
For Linux there are a few solutions:

https://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol
https://github.com/jedisct1/UCarp  (though the "ucarp.org" domain seem to now go to some Asian site)
https://serverfault.com/questions/276170/alternatives-to-heartbeat-pacemaker-and-corosync

I also got requests from a few customers a while ago, and we found it simpler just to use 2 identical boxes configure them the equally and put one offline in the shelf.
In case of problem just switch the boxes. 
The only issue is to keep the boxes in sync (because both have the same IP). 
We used rsync to a server share, switched of the actice box for a few minutes afterhours and occacionally synced the offline box to that (we excluded a few hardware/MAC related files). 
You also can give them 2 different IPs, and change the IP in case of a problem.

But to be honest: I do Asterisk/AstLinux stuff since 2007, but except an old water damage case (with only one net5501 under water that survived, but not the internal ISDN PCI card), I never had an issue that an AstLinux box broke and we really needed the Failover, except for testing, that it actually works as expected :-).
In all other problem cases either the power was down, the ISP/internet connection was down/had issues or the SIP provider had problems :-).

Michael

http://www.mksolutions.info

[Astlinux-users] Using WAN Failover for Astlinux High Availability

[Michael K. <mic...@ip...>]

Hi Group

Tell me if I am totally off track but I have been wondering for a while how I can do Astlinux HA e.g. having a primary and standby box
So what do you need for this:

  1.  Monitoring of the primary Astlinux server
  2.  Run a script if connectivity lost
  3.  Some sort of timers to prevent flapping
  4.  Email notification to indicate that it has occurred
  5.  Config sync between the two

When I considered the list, isn’t 1) to 4) actually already available with WAN Failover? Your monitor IP is the address of the other box?
Can you failover to the same interface?

Interesting thought!

Regards
Michael Knill

Re: [Astlinux-users] ACME (Let's Encrypt) Certificates

[David K. <da...@ke...>]

You could have different subdomains, e.g.

pbx1.ibcaccess.net
pbx2.ibcaccess.net
pbx2.ibcaccess.net

And each could have a unique certificate.  But then each Astlinux box would
need to have the login credentials for ibcaccess.net at whatever DNS
service you are using.  You might not want that.

Alternatively you could get a wildcard certificate for

*.ibcaccess.net

And deploy the same certificate to all Astlinux boxes even if they have
different subdomains.  However I think that our version of Acme client will
need to be updated to support that (probably not much of an issue, we've
been waiting for things to settle down a bit on the wildcard support).
Acme does not have wildcard support for all DNS services, so would need to
check on that.  But if you have a lot of Astlinux boxes with *.example.com
then this is probably much easier to manage.  You would request the
certificate at one Astlinux box and use the ssh deploy script to push
updated certificates out to every other one.

David




On Fri, Jun 15, 2018 at 8:57 AM, Lonnie Abelbeck <li...@lo...>
wrote:

> Hi Michael,
>
> Yes, ACME (Let's Encrypt) Certificates is the solution.
>
> You need a DNS provider supported by acme-cleint (acme.sh) that is able to
> prove DNS record ownership.
>
> There are two ways to go here:
>
> 1)  Create an account with a supported DNS service using the services's
> domain, such as https://www.duckdns.org/ , this is no cost for up to 5
> DNS records but they must be of the form <unique>.duckdns.org though a
> lot of the common ones have been taken.  Your username and assigned token
> is used to validate ownership of your DNS record.  Donate something and you
> will receive 10 DNS records.  DuckDNS is only one such example.
>
> 2) Register your own domain (yearly cost) then create an account with a
> supported DNS service using your domain, Cloudflare's free account supports
> this.  This is what I personally do.
> After you have a domain registered you need to set it's nameservers to
> point to Cloudflare's as instructed.
>
>
> > I currently have a domain that I use to access all my systems (
> ibcaccess.net). Can I use this?
>
> For security reasons, I would use a separate domain and account for my
> ACME (Let's Encrypt) Certificates, that way if your DNS API credentials got
> loose your core DNS infrastructure on a different account won't get
> compromised.
>
>
> > Would the customer need to access the Astlinux GUI using this domain?
>
> Yes, if you generated an ACME (Let's Encrypt) Certificate for host
> pbx4.example.org the user's DNS must resolve pbx4.example.org to the
> service in question.  Though if all the users are behind AstLinux you can
> define pbx4.example.org in { Configure DNS Hosts } -> "DNS Forwarder
> Hosts:" to the local server.  In general there does not need to be a public
> A record for pbx4.example.org if all the users are local.
>
> To be clear, the example.org DNS (domain for pbx4) must be publicly
> available for acme-cleint (acme.sh) to issue a valid certificate.
>
> Hope that helps.
>
> Lonnie
>
>
>
> > On Jun 15, 2018, at 1:23 AM, Michael Knill <michael.knill@ipcsolutions.
> com.au> wrote:
> >
> > Ok after reading the doco page and Lets Encrypt and ACME Protocol pages,
> I realise that I don't really know what I am doing 😊
> >
> > The Problem:
> > I am now providing more regular access to the Astlinux Admin interface
> to customers and the certificate error is not a good look. You can store
> the Self Signed Certificate with Firefox but Chrome does not let you now.
> >
> > The Solution:
> > ACME (Let's Encrypt) Certificates with DNS.
> > Problem is that I don't know what I need and how to do it.
> > I currently have a domain that I use to access all my systems (
> ibcaccess.net). Can I use this?
> > Would the customer need to access the Astlinux GUI using this domain?
> Would I need to use a subdomain for the internal address?
> >
> > Im just confused sorry. I am obviously too much of a noob regarding this
> stuff.
> >
> > Regards
> > Michael Knill
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
> _________________________________________
> > 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....
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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....

Re: [Astlinux-users] ACME (Let's Encrypt) Certificates

[Lonnie A. <li...@lo...>]

Hi Michael,

Yes, ACME (Let's Encrypt) Certificates is the solution.

You need a DNS provider supported by acme-cleint (acme.sh) that is able to prove DNS record ownership.

There are two ways to go here:

1)  Create an account with a supported DNS service using the services's domain, such as https://www.duckdns.org/ , this is no cost for up to 5 DNS records but they must be of the form <unique>.duckdns.org though a lot of the common ones have been taken.  Your username and assigned token is used to validate ownership of your DNS record.  Donate something and you will receive 10 DNS records.  DuckDNS is only one such example.

2) Register your own domain (yearly cost) then create an account with a supported DNS service using your domain, Cloudflare's free account supports this.  This is what I personally do.
After you have a domain registered you need to set it's nameservers to point to Cloudflare's as instructed.


> I currently have a domain that I use to access all my systems (ibcaccess.net). Can I use this?

For security reasons, I would use a separate domain and account for my ACME (Let's Encrypt) Certificates, that way if your DNS API credentials got loose your core DNS infrastructure on a different account won't get compromised.


> Would the customer need to access the Astlinux GUI using this domain?

Yes, if you generated an ACME (Let's Encrypt) Certificate for host pbx4.example.org the user's DNS must resolve pbx4.example.org to the service in question.  Though if all the users are behind AstLinux you can define pbx4.example.org in { Configure DNS Hosts } -> "DNS Forwarder Hosts:" to the local server.  In general there does not need to be a public A record for pbx4.example.org if all the users are local.

To be clear, the example.org DNS (domain for pbx4) must be publicly available for acme-cleint (acme.sh) to issue a valid certificate.

Hope that helps.

Lonnie



> On Jun 15, 2018, at 1:23 AM, Michael Knill <mic...@ip...> wrote:
> 
> Ok after reading the doco page and Lets Encrypt and ACME Protocol pages, I realise that I don't really know what I am doing 😊
>  
> The Problem:
> I am now providing more regular access to the Astlinux Admin interface to customers and the certificate error is not a good look. You can store the Self Signed Certificate with Firefox but Chrome does not let you now.
>  
> The Solution:
> ACME (Let's Encrypt) Certificates with DNS.
> Problem is that I don't know what I need and how to do it.
> I currently have a domain that I use to access all my systems (ibcaccess.net). Can I use this?
> Would the customer need to access the Astlinux GUI using this domain? Would I need to use a subdomain for the internal address?
>  
> Im just confused sorry. I am obviously too much of a noob regarding this stuff.
>  
> Regards
> Michael Knill
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> 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....

Re: [Astlinux-users] ACME (Let's Encrypt) Certificates

[David K. <da...@ke...>]

ACME certificates are supported directly in Astlinux...
https://doc.astlinux-project.org/userdoc:tt_acme_certificates

Each of your Astlinux boxes should have a unique URL (
https://michaelpbx.example.com) and you need access to the registrar where
you keep your DNS record for michaelpbx.example.com. Each Astlinux box will
then have its own certificate.  The full list of supported DNS registrars
can be found in stat/etc/acme/dnsapi/ and you would want to go to the acme
github page for documentation on each.

Initial setup must be done at CLI, but them you add a cron job as
documented and from then on it takes care of itself.

I have FreeDNS and Cloudflare registrars working for a couple of my domains.

David





On Fri, Jun 15, 2018 at 2:23 AM, Michael Knill <
mic...@ip...> wrote:

> Ok after reading the doco page and Lets Encrypt and ACME Protocol pages, I
> realise that I don't really know what I am doing 😊
>
>
>
> The Problem:
>
> I am now providing more regular access to the Astlinux Admin interface to
> customers and the certificate error is not a good look. You can store the
> Self Signed Certificate with Firefox but Chrome does not let you now.
>
>
>
> The Solution:
>
> ACME (Let's Encrypt) Certificates with DNS.
>
> Problem is that I don't know what I need and how to do it.
>
> I currently have a domain that I use to access all my systems (
> ibcaccess.net). Can I use this?
>
> Would the customer need to access the Astlinux GUI using this domain?
> Would I need to use a subdomain for the internal address?
>
>
>
> Im just confused sorry. I am obviously too much of a noob regarding this
> stuff.
>
>
>
> Regards
>
> Michael Knill
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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] ACME (Let's Encrypt) Certificates

[Michael K. <mic...@ip...>]

Ok after reading the doco page and Lets Encrypt and ACME Protocol pages, I realise that I don't really know what I am doing 😊

The Problem:
I am now providing more regular access to the Astlinux Admin interface to customers and the certificate error is not a good look. You can store the Self Signed Certificate with Firefox but Chrome does not let you now.

The Solution:
ACME (Let's Encrypt) Certificates with DNS.
Problem is that I don't know what I need and how to do it.
I currently have a domain that I use to access all my systems (ibcaccess.net). Can I use this?
Would the customer need to access the Astlinux GUI using this domain? Would I need to use a subdomain for the internal address?

Im just confused sorry. I am obviously too much of a noob regarding this stuff.

Regards
Michael Knill

Re: [Astlinux-users] Moving Astlinux from Asterisk 13 to 11

[Michael K. <mic...@ip...>]

Thanks Michael. Good find. I will document it now.

Regards
Michael Knill

From: Michael Keuter <li...@mk...>
Reply-To: AstLinux List <ast...@li...>
Date: Thursday, 7 June 2018 at 5:29 pm
To: AstLinux List <ast...@li...>
Subject: Re: [Astlinux-users] Moving Astlinux from Asterisk 13 to 11

Update: Here is your old thread :-)
https://sourceforge.net/p/astlinux/mailman/message/35439293/

Sent from a mobile device.

Michael Keuter

Am 07.06.2018 um 09:02 schrieb Michael Knill <mic...@ip...<mailto:mic...@ip...>>:
Hi Group

Im sure I have been told this before so sorry for asking again.
I need to move an Astlinux 1.3.1 box from Asterisk 13 to Asterisk 11 and Im not quite sure how to do it. Changing the repository URL will only help if its an upgrade.

I will document it this time.

Thanks

Regards
Michael Knill
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot
_______________________________________________
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...>.

Re: [Astlinux-users] Moving Astlinux from Asterisk 13 to 11

[Michael K. <li...@mk...>]

Update: Here is your old thread :-)
https://sourceforge.net/p/astlinux/mailman/message/35439293/

Sent from a mobile device.

Michael Keuter

> Am 07.06.2018 um 09:02 schrieb Michael Knill <mic...@ip...>:
> 
> Hi Group
>  
> Im sure I have been told this before so sorry for asking again.
> I need to move an Astlinux 1.3.1 box from Asterisk 13 to Asterisk 11 and Im not quite sure how to do it. Changing the repository URL will only help if its an upgrade.
>  
> I will document it this time.
>  
> Thanks
>  
> Regards
> Michael Knill
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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....

Re: [Astlinux-users] Moving Astlinux from Asterisk 13 to 11

[Michael K. <li...@mk...>]

Hi Michael,

since we're now at AstLinux 1.3.3 you can just change the URL to 13 and then upgrade to the newer version.

Sent from a mobile device.

Michael Keuter

> Am 07.06.2018 um 09:02 schrieb Michael Knill <mic...@ip...>:
> 
> Hi Group
>  
> Im sure I have been told this before so sorry for asking again.
> I need to move an Astlinux 1.3.1 box from Asterisk 13 to Asterisk 11 and Im not quite sure how to do it. Changing the repository URL will only help if its an upgrade.
>  
> I will document it this time.
>  
> Thanks
>  
> Regards
> Michael Knill
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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] Moving Astlinux from Asterisk 13 to 11

[Michael K. <mic...@ip...>]

Hi Group

Im sure I have been told this before so sorry for asking again.
I need to move an Astlinux 1.3.1 box from Asterisk 13 to Asterisk 11 and Im not quite sure how to do it. Changing the repository URL will only help if its an upgrade.

I will document it this time.

Thanks

Regards
Michael Knill

Re: [Astlinux-users] Controlling traffic over WAN failover interface

[Lonnie A. <li...@lo...>]

Great stuff, David !

Thanks for sharing.

Lonnie



> On Jun 5, 2018, at 7:09 PM, David Kerr <Da...@Ke...> wrote:
> 
> If using a WAN failover that uses cellular wireless connection you may need to carefully control how much traffic you send over that link to avoid very high data overage costs.  To this end I have implemented the following controls on my Astlinux box...
> 
> 1) Block any given local device by MAC address from using the link
> For example... block my Apple TV so no video streaming to that device.
> 
> 2) Block any given TCP/IP port for inbound/outbound traffic.
> For example... block ports used by an online backup service
> 
> 3) Rate limit any given device by MAC address to e.g. 256kbps
> For example... discourage video streaming to kids iPhones while still allowing messaging.
> 
> The above can all be implemented in firewall custom rules.  Below are the functions I implemented...
> 
> # =============================================================================
> ## Function to block devices so that they cannot access network through a given
> ## interface.  And/or block traffic to/from a specific tcp/udp port number.
> ## >>>Call this function only once per interface
> ## Parameters:
> ##  interface (e.g. eth2)
> ##  MacAddrs (list of mac addresses)
> ##  Ports (list of ports)
> ## The interface local IP addresses are whitelisted
> block_ports_macaddrs()
> {
>   local IFS=' '
>   local mac
>   local interface="$1"
>   local macs="${2//,/ }"  # if comma delimited convert to space delimited
>   local ports="$(echo $3 | tr -s ' ' ',')" # make sure comma delimited
>   local chain=$(echo "FORWARD_$interface" | tr [a-z] [A-Z])  # uppercase interface name
>   local ipv4=$(ip -4 addr show $interface | grep 'inet ' | awk -F' ' '{ print $2 }')
>   local ipv6ula=$(ip -6 addr show $interface | grep 'inet6 fd' | awk -F' ' '{ print $2 }')
> 
>   iptables -N $chain 2>/dev/null
>   iptables -F $chain
>   iptables -A FORWARD_CHAIN -o $interface -j $chain
>   if [ -n "$ipv4" ]; then
>     ip4tables -A $chain -d "$ipv4" -j ACCEPT
>   fi
>   if [ -n "$ipv6ula" ]; then
>     ip6tables -A $chain -d "$ipv6ula" -j ACCEPT
>   fi
>   for mac in $macs; do
>     echo "[CUSTOM RULE] Block MAC address $mac on interface $interface"
>     iptables -A $chain -m mac --mac-source $mac -j DROP
>   done
>   if [ -n "$ports" ]; then
>     echo "[CUSTOM RULE] Block ports $ports on interface $interface"
>     iptables -A $chain -p tcp -m multiport --dports $ports -j DROP
>     iptables -A $chain -p tcp -m multiport --sports $ports -j DROP
>     iptables -A $chain -p udp -m multiport --dports $ports -j DROP
>     iptables -A $chain -p udp -m multiport --sports $ports -j DROP
>   fi
> }
> 
> # =============================================================================
> ## Function to prepare for rate limiting for traffic between local net and
> ## the WAN failover wireguard net.  Actual packet selection for rate
> ## limiting will take place in iptables.  This function limits only 
> ## internal interfaces or WAN failover, not default EXTIF.
> prepare_rate_limits()
> {
>   local interface
>   local IFS=' '
>   for interface in $INT_IF $EXT2IF; do
>     echo "[CUSTOM RULE] Prepare $interface for rate limiting"
>     tc qdisc del dev $interface root 2>/dev/null
>     tc qdisc add dev $interface root handle 1: htb
>     tc class add dev $interface parent 1: classid 1:1 htb rate 256Kbit
>     tc class add dev $interface parent 1: classid 1:2 htb rate 512Kbit
>     tc class add dev $interface parent 1: classid 1:3 htb rate 1024Kbit
>     tc qdisc add dev $interface parent 1:1 handle 2: sfq perturb 10
>     tc qdisc add dev $interface parent 1:2 handle 3: sfq perturb 10
>     tc qdisc add dev $interface parent 1:3 handle 4: sfq perturb 10
>     tc filter add dev $interface protocol ip parent 1: prio 1 handle 1 fw flowid 1:1
>     tc filter add dev $interface protocol ip parent 1: prio 1 handle 2 fw flowid 1:2
>     tc filter add dev $interface protocol ip parent 1: prio 1 handle 3 fw flowid 1:3
>   done
> }
> 
> 
> ## Function to Rate limit some devices so that they cannot drive up huge data use.
> ## >>>Call this function only once per interface
> ## This uses kernel traffic control (tc) rules set on the net interface
> ## Parameters:
> ##  interface (e.g. eth2)
> ##  MacAddrs (list of mac addresses)
> ##  LimitMarks (list of limit-marks corresponding to each mac address)
> ##     Mark 1: 256 Kbps, 2: 512 Kbps, 3: 1 Mbps
> ## Inbound packets have the packet mark restored
> ## Outbound packets from selected devices are marked and the packet saved
> ## The interface local IP addresses are whitelisted
> rate_limit_macaddrs()
> {
>   local IFS=' '
>   local mac
>   local interface="$1"
>   local macs="${2//,/ }"  # if comma delimited convert to space delimited
>   local rate_marks="${3//,/ }" # if comma delimited convert to space delimited
>   local chain=$(echo "FORWARD_$interface" | tr [a-z] [A-Z])  # uppercase interface name
>   local ipv4=$(ip -4 addr show $interface | grep 'inet ' | awk -F' ' '{ print $2 }')
>   local ipv6ula=$(ip -6 addr show $interface | grep 'inet6 fd' | awk -F' ' '{ print $2 }')
> 
>   iptables -N $chain -t mangle 2>/dev/null
>   iptables -F $chain -t mangle
>   iptables -A FORWARD -t mangle -i $interface -j CONNMARK --restore-mark
>   iptables -A FORWARD -t mangle -o $interface -j $chain
>   if [ -n "$ipv4" ]; then
>     ip4tables -A $chain -t mangle -d "$ipv4" -j ACCEPT
>   fi
>   if [ -n "$ipv6ula" ]; then
>     ip6tables -A $chain -t mangle -d "$ipv6ula" -j ACCEPT
>   fi
>   iptables -A $chain -t mangle -j CONNMARK --restore-mark 
>   iptables -A $chain -t mangle -m mark ! --mark 0 -j ACCEPT
>   for mac in $macs; do
>     echo "[CUSTOM RULE] Rate limit MAC address $mac on interface $interface"
>     mark=${rate_marks%% *}
>     rate_marks=${rate_marks#* }
>     iptables -A $chain -t mangle -m mac --mac-source $mac -j MARK --set-mark ${mark:-1}
>   done
>   iptables -A $chain -t mangle -j CONNMARK --save-mark
>   iptables -A $chain -t mangle -j ACCEPT
> }
> 
> # =============================================================================
> ## Make the calls to block / rate limit 
> 
> prepare_rate_limits
> 
> rate_limit_macaddrs \
> "$EXT2IF" \
> "52:54:00:43:1c:6e 3c:2e:ff:xx:xx:xx 8c:85:90:xx:xx:xx b8:e8:56:xx:xx:xx" \
> "3 1 1 2"
> ##^ TestVM, iPhone, MacBook, iPad
> 
> block_ports_macaddrs \
> "$EXT2IF" \
> "00:08:9B:xx:xx:xx 00:08:9B:xx:xx:xx 00:08:9B:xx:xx:xx 52:54:00:xx:xx:xx 08:66:98:xx:xx:xx" \
> "4242"
> ##^ QNAP, QNAP, QNAP, UbuntuVM, AppleTV
> ##^ 4242 = crashplan ports
> 
> 
> Now if you are using wireguard to create a VPN link to a failover host you also want to repeat the above settings with "wg0" in place of "$EXT2IF" and because the wg0 interface is taken down during a wireguard VPN restart you also need to reset the rate limiting traffic controls "tc" commands in the up/down script for that.  For example...
> 
> #!/bin/bash
> ## Action: POST_UP PRE_DOWN
> action="$1"
> ## WireGuard Interface: (ex. wg0)
> interface="$2"
> 
> if [ "$action" = "POST_UP" ]; then
>   logger -t wireguard -p kern.info "WireGuard VPN is started on '$interface' interface."
>   echo "Prepare $interface for rate limiting"
>   tc qdisc del dev $interface root 2>/dev/null
>   tc qdisc add dev $interface root handle 1: htb
>   tc class add dev $interface parent 1: classid 1:1 htb rate 256Kbit
>   tc class add dev $interface parent 1: classid 1:2 htb rate 512Kbit
>   tc class add dev $interface parent 1: classid 1:3 htb rate 1024Kbit
>   tc qdisc add dev $interface parent 1:1 handle 2: sfq perturb 10
>   tc qdisc add dev $interface parent 1:2 handle 3: sfq perturb 10
>   tc qdisc add dev $interface parent 1:3 handle 4: sfq perturb 10
>   tc filter add dev $interface protocol ip parent 1: prio 1 handle 1 fw flowid 1:1
>   tc filter add dev $interface protocol ip parent 1: prio 1 handle 2 fw flowid 1:2
>   tc filter add dev $interface protocol ip parent 1: prio 1 handle 3 fw flowid 1:3
> elif [ "$action" = "PRE_DOWN" ]; then
>   logger -t wireguard -p kern.info "WireGuard VPN is stopping '$interface' interface."
> fi
> 

[Astlinux-users] Controlling traffic over WAN failover interface

[David K. <da...@ke...>]

If using a WAN failover that uses cellular wireless connection you may need
to carefully control how much traffic you send over that link to avoid very
high data overage costs.  To this end I have implemented the following
controls on my Astlinux box...

1) Block any given local device by MAC address from using the link
For example... block my Apple TV so no video streaming to that device.

2) Block any given TCP/IP port for inbound/outbound traffic.
For example... block ports used by an online backup service

3) Rate limit any given device by MAC address to e.g. 256kbps
For example... discourage video streaming to kids iPhones while still
allowing messaging.

The above can all be implemented in firewall custom rules.  Below are the
functions I implemented...

#
=============================================================================
## Function to block devices so that they cannot access network through a
given
## interface.  And/or block traffic to/from a specific tcp/udp port number.
## >>>Call this function only once per interface
## Parameters:
##  interface (e.g. eth2)
##  MacAddrs (list of mac addresses)
##  Ports (list of ports)
## The interface local IP addresses are whitelisted
block_ports_macaddrs()
{
  local IFS=' '
  local mac
  local interface="$1"
  local macs="${2//,/ }"  # if comma delimited convert to space delimited
  local ports="$(echo $3 | tr -s ' ' ',')" # make sure comma delimited
  local chain=$(echo "FORWARD_$interface" | tr [a-z] [A-Z])  # uppercase
interface name
  local ipv4=$(ip -4 addr show $interface | grep 'inet ' | awk -F' ' '{
print $2 }')
  local ipv6ula=$(ip -6 addr show $interface | grep 'inet6 fd' | awk -F' '
'{ print $2 }')

  iptables -N $chain 2>/dev/null
  iptables -F $chain
  iptables -A FORWARD_CHAIN -o $interface -j $chain
  if [ -n "$ipv4" ]; then
    ip4tables -A $chain -d "$ipv4" -j ACCEPT
  fi
  if [ -n "$ipv6ula" ]; then
    ip6tables -A $chain -d "$ipv6ula" -j ACCEPT
  fi
  for mac in $macs; do
    echo "[CUSTOM RULE] Block MAC address $mac on interface $interface"
    iptables -A $chain -m mac --mac-source $mac -j DROP
  done
  if [ -n "$ports" ]; then
    echo "[CUSTOM RULE] Block ports $ports on interface $interface"
    iptables -A $chain -p tcp -m multiport --dports $ports -j DROP
    iptables -A $chain -p tcp -m multiport --sports $ports -j DROP
    iptables -A $chain -p udp -m multiport --dports $ports -j DROP
    iptables -A $chain -p udp -m multiport --sports $ports -j DROP
  fi
}

#
=============================================================================
## Function to prepare for rate limiting for traffic between local net and
## the WAN failover wireguard net.  Actual packet selection for rate
## limiting will take place in iptables.  This function limits only
## internal interfaces or WAN failover, not default EXTIF.
prepare_rate_limits()
{
  local interface
  local IFS=' '
  for interface in $INT_IF $EXT2IF; do
    echo "[CUSTOM RULE] Prepare $interface for rate limiting"
    tc qdisc del dev $interface root 2>/dev/null
    tc qdisc add dev $interface root handle 1: htb
    tc class add dev $interface parent 1: classid 1:1 htb rate 256Kbit
    tc class add dev $interface parent 1: classid 1:2 htb rate 512Kbit
    tc class add dev $interface parent 1: classid 1:3 htb rate 1024Kbit
    tc qdisc add dev $interface parent 1:1 handle 2: sfq perturb 10
    tc qdisc add dev $interface parent 1:2 handle 3: sfq perturb 10
    tc qdisc add dev $interface parent 1:3 handle 4: sfq perturb 10
    tc filter add dev $interface protocol ip parent 1: prio 1 handle 1 fw
flowid 1:1
    tc filter add dev $interface protocol ip parent 1: prio 1 handle 2 fw
flowid 1:2
    tc filter add dev $interface protocol ip parent 1: prio 1 handle 3 fw
flowid 1:3
  done
}


## Function to Rate limit some devices so that they cannot drive up huge
data use.
## >>>Call this function only once per interface
## This uses kernel traffic control (tc) rules set on the net interface
## Parameters:
##  interface (e.g. eth2)
##  MacAddrs (list of mac addresses)
##  LimitMarks (list of limit-marks corresponding to each mac address)
##     Mark 1: 256 Kbps, 2: 512 Kbps, 3: 1 Mbps
## Inbound packets have the packet mark restored
## Outbound packets from selected devices are marked and the packet saved
## The interface local IP addresses are whitelisted
rate_limit_macaddrs()
{
  local IFS=' '
  local mac
  local interface="$1"
  local macs="${2//,/ }"  # if comma delimited convert to space delimited
  local rate_marks="${3//,/ }" # if comma delimited convert to space
delimited
  local chain=$(echo "FORWARD_$interface" | tr [a-z] [A-Z])  # uppercase
interface name
  local ipv4=$(ip -4 addr show $interface | grep 'inet ' | awk -F' ' '{
print $2 }')
  local ipv6ula=$(ip -6 addr show $interface | grep 'inet6 fd' | awk -F' '
'{ print $2 }')

  iptables -N $chain -t mangle 2>/dev/null
  iptables -F $chain -t mangle
  iptables -A FORWARD -t mangle -i $interface -j CONNMARK --restore-mark
  iptables -A FORWARD -t mangle -o $interface -j $chain
  if [ -n "$ipv4" ]; then
    ip4tables -A $chain -t mangle -d "$ipv4" -j ACCEPT
  fi
  if [ -n "$ipv6ula" ]; then
    ip6tables -A $chain -t mangle -d "$ipv6ula" -j ACCEPT
  fi
  iptables -A $chain -t mangle -j CONNMARK --restore-mark
  iptables -A $chain -t mangle -m mark ! --mark 0 -j ACCEPT
  for mac in $macs; do
    echo "[CUSTOM RULE] Rate limit MAC address $mac on interface $interface"
    mark=${rate_marks%% *}
    rate_marks=${rate_marks#* }
    iptables -A $chain -t mangle -m mac --mac-source $mac -j MARK
--set-mark ${mark:-1}
  done
  iptables -A $chain -t mangle -j CONNMARK --save-mark
  iptables -A $chain -t mangle -j ACCEPT
}

#
=============================================================================
## Make the calls to block / rate limit

prepare_rate_limits

rate_limit_macaddrs \
"$EXT2IF" \
"52:54:00:43:1c:6e 3c:2e:ff:xx:xx:xx 8c:85:90:xx:xx:xx b8:e8:56:xx:xx:xx" \
"3 1 1 2"
##^ TestVM, iPhone, MacBook, iPad

block_ports_macaddrs \
"$EXT2IF" \
"00:08:9B:xx:xx:xx 00:08:9B:xx:xx:xx 00:08:9B:xx:xx:xx 52:54:00:xx:xx:xx
08:66:98:xx:xx:xx" \
"4242"
##^ QNAP, QNAP, QNAP, UbuntuVM, AppleTV
##^ 4242 = crashplan ports


Now if you are using wireguard to create a VPN link to a failover host you
also want to repeat the above settings with "wg0" in place of "$EXT2IF" and
because the wg0 interface is taken down during a wireguard VPN restart you
also need to reset the rate limiting traffic controls "tc" commands in the
up/down script for that.  For example...

#!/bin/bash
## Action: POST_UP PRE_DOWN
action="$1"
## WireGuard Interface: (ex. wg0)
interface="$2"

if [ "$action" = "POST_UP" ]; then
  logger -t wireguard -p kern.info "WireGuard VPN is started on
'$interface' interface."
  echo "Prepare $interface for rate limiting"
  tc qdisc del dev $interface root 2>/dev/null
  tc qdisc add dev $interface root handle 1: htb
  tc class add dev $interface parent 1: classid 1:1 htb rate 256Kbit
  tc class add dev $interface parent 1: classid 1:2 htb rate 512Kbit
  tc class add dev $interface parent 1: classid 1:3 htb rate 1024Kbit
  tc qdisc add dev $interface parent 1:1 handle 2: sfq perturb 10
  tc qdisc add dev $interface parent 1:2 handle 3: sfq perturb 10
  tc qdisc add dev $interface parent 1:3 handle 4: sfq perturb 10
  tc filter add dev $interface protocol ip parent 1: prio 1 handle 1 fw
flowid 1:1
  tc filter add dev $interface protocol ip parent 1: prio 1 handle 2 fw
flowid 1:2
  tc filter add dev $interface protocol ip parent 1: prio 1 handle 3 fw
flowid 1:3
elif [ "$action" = "PRE_DOWN" ]; then
  logger -t wireguard -p kern.info "WireGuard VPN is stopping '$interface'
interface."
fi

Re: [Astlinux-users] WAN Failover using Netgear LB1121 4G/LTE Modem

[David K. <da...@ke...>]

Just wanted to add some observations of my own.  Like Lonnie I have been
testing WAN failover using the Netgear LB1121 and it is working well.

I did run into one quirk though which is when using bridge mode in the
LB1121 I was getting unreliable connections when switching to test
failover.  On investigation it appeared that the IP address issued by AT&T
was changing and the interface/route was getting into a weird state.  I
have switched my LB1121 back over to router mode with static IP address and
it is working fine.  This may be specific to AT&T, I think Lonnie is on
T-Mobile, but is something to look out for.  As I am tunneling through a
VPN to an external endpoint whether bridge or router makes no difference.

Lonnie and I both set up an Astlinux on Linode and wireguard VPN into it.
I tried to get Astlinux onto other cloud providers (AWS, Google) with no
success... their environment appears to require the GRUB loader.  However I
did try firing up a plain old Ubuntu on those cloud providers, installed
wireguard, setup a few iptables rules to implement simple NAT/Forwarding
and lo it all works.  So that is an alternate path.

You can also set an inbound NAT rule on your failover host to forward a
specific port to your AstLinux web interface so you can access that when in
failover situations (note, it will not work if your Astlinux box is using
the primary WAN as the default route will cause replies to go through the
primary interface and not the failover interface).  If you do this, add the
URL for your failover host to your SSL certificate so that you don't get
warnings.

Finally... the wireless plan I am using for my failover is not unlimited.
I therefore need to strictly limit traffic over the link and specifically
limit video streaming and online backups which could drive high usage.  I
implemented a number of rules to enforce this which I will post to this
list in a separate note.

David

On Tue, Jun 5, 2018 at 12:02 PM, Lonnie Abelbeck <li...@lo...>
wrote:

> I have now more completely tested my WAN Failover using 4G/LTE over
> WireGuard ...and now works perfectly with Asterisk with a configuration
> change.
>
> My 4G/LTE over WireGuard tunnel endpoint is with AstLinux on a Linode KVM
> (as documented previously).  The AstLinux on the Linode KVM instance is not
> running Asterisk.
>
> Previously my local Asterisk was configured with nat=no and since I have a
> static IPv4 address my SIP provider has an option to authenticate using the
> static address (no registration).  If I added the static IPv4 of my Linode
> KVM instance it mostly worked for outbound calls during failover but would
> require failover call configuration at the SIP provided end to handle
> inbound calls.
>
> Instead, I switched my SIP provider configuration to require registration
> and removed my static IPv4 authentication.  In order to force a quick
> registration update on the switch I use the wan-failover.script to reload
> sip:
>
> -- /mnt/kd/wan-failover.script snippet --
>   SECONDARY)
>     ## Switched to Failover using secondary WAN link
>     asterisk -rx "sip reload" >/dev/null
>     ;;
>
>   PRIMARY)
>     ## Switched back to normal using primary WAN link
>     asterisk -rx "sip reload" >/dev/null
>     ;;
> --
>
> Almost there, but when failover occurs the registration is NAT'ed at the
> AstLinux on Linode KVM end, so for my SIP provider all it took was to
> configure my SIP account to support NAT.  Even though my Asterisk is still
> configured with nat=no, the registration via the failover tunnel now works.
>
> Inbound and outbound SIP calls work perfectly over the 4G/LTE failover.
>
> Most interestingly, the calls keep working during the failover switch and
> back again ... I was not expecting that, and I am still scratching my head
> over that.  The active calls do not miss a beat as I see data over my
> 4G/LTE and then no data over 4G/LTE, the call continues perfectly.  I even
> have directmedia=no in my provider peer's sip.conf.
>
> Lonnie
>
>
>
> > On May 28, 2018, at 8:30 PM, Michael Knill <michael.knill@ipcsolutions.
> com.au> wrote:
> >
> > I decided today the architecture I want to test.
> > I will be setting up a DR Astlinux box running Asterisk and having a SIP
> Trunk with a 100 Block number range on it for indial.
> > All Astklinux boxes configured for failover will establish a VPN to this
> box and a SIP Trunk to the DR server will be second choice for outgoing
> calls. I can set the Caller ID to be anything I want for DR outgoing so no
> issues there. Billing should be fine also as long as the Originating Caller
> ID is correct.
> > All my providers allow the setting of a call forward on busy (and
> unreachable) to forward to one of the numbers in the 100 block which is
> redirected to the associated Astlinux box. So incoming calls are sorted
> also. If it's the same provider, then all forwarded calls are free.
> >
> > I think it should work with no manual intervention required.
> >
> > Regards
> > Michael Knill
> >
> > On 29/5/18, 10:07 am, "Lonnie Abelbeck" <li...@lo...>
> wrote:
> >
> >    Hey Michael,
> >
> >    Currently my "cloud" AstLinux Linode KVM (4G/LTE over VPN endpoint)
> has Asterisk disabled, ASTERISK_DAHDI_DISABLE="yes" so when my main
> AstLinux box goes to failover the SIP packets originate from my "home"
> WireGuard private 10.0.0.0/24 address and are NAT'ed at the Linode end.
> Normally there is no NAT and SIP packets originate with my public IP.
> >
> >    Surprisingly outbound calls work without any changes, though a remote
> hangup BYE is not received.  Inbound failover could be handled on my SIP
> provider's platform.
> >
> >    I could enable Asterisk at the Linode end and use it as a proxy of
> sorts.
> >
> >    Possibly better, per what you suggested, is to implement an outbound
> call failover in the "main" Asterisk regardless of the WAN Failover status
> ... if the standard outbound call fails it tries the call over the 4G/LTE
> VPN path.
> >
> >    I'm still pondering my options.  The exact solution is somewhat
> dependent on the user's SIP provider.
> >
> >    Lonnie
> >
> >
> >
> >
> >> On May 28, 2018, at 5:08 PM, Michael Knill <michael.knill@ipcsolutions.
> com.au> wrote:
> >>
> >> Hi Lonnie
> >>
> >> So what are you trying to solve with Asterisk failover?
> >>
> >> Regards
> >> Michael Knill
> >>
> >> On 28/5/18, 10:00 pm, "Lonnie Abelbeck" <li...@lo...>
> wrote:
> >>
> >>   Hi Michael,
> >>
> >>   Yes, you can use OpenVPN and WireGuard at the same time, no problem.
> I do.
> >>
> >>   WireGuard is much faster / more efficient than OpenVPN, mostly since
> it resides in the kernel and can use multiple cores.  Here are some
> benchmarks I posted to the WireGuard mailing list:
> >>
> >>   https://lists.zx2c4.com/pipermail/wireguard/2017-December/002204.html
> >>
> >>   There are user-space implementations of WireGuard, written in Golang,
> starting to appear for testing, but for non-Linux endpoints I would stick
> with OpenVPN for now.
> >>
> >>   BTW, I currently have WAN Failover on my production AstLinux box
> using the Netgear LB1121 4G/LTE over WireGuard VPN to a Linode KVM running
> AstLinux.  Working is dual stack IPv4/IPv6 failover for the AstLinux box
> itself and any internal network of my choosing.  I have outbound Asterisk
> failover working, but that is still a work in progress, not sure the best
> method yet.
> >>
> >>   Lonnie
> >>
> >>
> >>
> >>
> >>> On May 28, 2018, at 5:03 AM, Michael Knill <
> mic...@ip...> wrote:
> >>>
> >>> Hi group
> >>>
> >>> Im ready to do some testing.
> >>> I have a number of sites that are set up as OpenVPN Servers. Should
> there be any issues using Wireguard as well?
> >>> PS I just looked up Wireguard and I cant believe the difference in
> benchmarks to Open VPN. That's crazy!
> >>>
> >>> Regards
> >>> Michael Knill
> >>>
> >>> On 24/5/18, 9:23 am, "Michael Knill" <michael.knill@ipcsolutions.
> com.au> wrote:
> >>>
> >>>  Thanks Lonnie. I don't have a specific scenario yet but handy to know
> its possible.
> >>>
> >>>  Regards
> >>>  Michael Knill
> >>>
> >>>  On 24/5/18, 8:54 am, "Lonnie Abelbeck" <li...@lo...>
> wrote:
> >>>
> >>>      Michael,
> >>>
> >>>> So are you saying that you can configure a second external interface
> and the associated routing to it with the Failover Tab but just leave
> Failover disabled?
> >>>
> >>>      Yes, "External Failover Destination Routes:" automatically
> defines static routes, automatically removed and added for DHCP changes.
> >>>
> >>>
> >>>> If so, I assume it uses the same EXT firewall rules?
> >>>
> >>>      Yes.  There is a way to treat EXTIF and EXT2IF firewall rules
> differently, but the same is usually OK.
> >>>
> >>>      Lonnie
> >>>
> >>>
> >>>
> >>>> On May 23, 2018, at 5:17 PM, Michael Knill <
> mic...@ip...> wrote:
> >>>>
> >>>> Hi Lonnie
> >>>>
> >>>> So are you saying that you can configure a second external interface
> and the associated routing to it with the Failover Tab but just leave
> Failover disabled?
> >>>> If so, I assume it uses the same EXT firewall rules?
> >>>>
> >>>> Regards
> >>>> Michael Knill
> >>>>
> >>>> On 22/5/18, 8:59 am, "Lonnie Abelbeck" <li...@lo...>
> wrote:
> >>>>
> >>>> Hi Michael,
> >>>>
> >>>>> I noticed you also pass the VPN traffic to the site LAN
> >>>>
> >>>> Yes, I tried to implement the general case, easy to remove stuff.
> >>>>
> >>>>> the VPN would normally just be used for voice traffic and management
> only.
> >>>>
> >>>> In that case "External Failover Destination Routes: IPv4 Routes:"
> could define all the destination routes you need without "Failover" enabled
> ... and let Asterisk dynamically choose the SIP route.  Handling inbound
> calls over the 4G/LTE VPN would also be possible.
> >>>>
> >>>>
> >>>> All seems to work well, the only fundamental issue may be the latency
> of 4G/LTE for SIP traffic ... though clearly much better than no traffic.
> >>>>
> >>>> Lonnie
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> On May 21, 2018, at 5:36 PM, Michael Knill <
> mic...@ip...> wrote:
> >>>>>
> >>>>> Thanks Lonnie you beat me to it.
> >>>>> Interestingly one of my partners is using Asterisk as their
> Softswitch and they were thinking of setting up a single VPN Tunnel to the
> SoftSwitch for voice traffic and so everything still works on both the
> primary and failover links. There should be no failover scripts required!
> >>>>>
> >>>>> I noticed you also pass the VPN traffic to the site LAN but this
> would not actually be required in practice as the VPN would normally just
> be used for voice traffic and management only. On all VPN connections that
> run voice traffic I set directmedia=no in sip.conf. PS I actually now use a
> directmedia ACL on the VPN subnet so I don't need to configure anything.
> E.g.
> >>>>>
> >>>>> directmedia=yes
> >>>>> directmediapermit=0.0.0.0/0
> >>>>> directmediadeny=<VPN Subnet>
> >>>>>
> >>>>> Thanks again Lonnie for testing. Im looking forward to implementing
> it.
> >>>>>
> >>>>> Regards
> >>>>> Michael Knill
> >>>>>
> >>>>> On 22/5/18, 6:59 am, "Lonnie Abelbeck" <li...@lo...>
> wrote:
> >>>>>
> >>>>> Followup, Enabling Failover using a Netgear LB1121-100NAS (review
> below):
> >>>>>
> >>>>> The basic failover configuration is documented here:
> >>>>>
> >>>>> WAN Failover
> >>>>> https://doc.astlinux-project.org/userdoc:tt_wan_failover
> >>>>>
> >>>>> Since most 4G/LTE providers only support outbound-only (NAT'ed),
> IPv4-only, dynamic IPv4 address networks, any basic failover configuration
> over 4G/LTE must deal with those constraints.
> >>>>>
> >>>>> But, there is another way ...
> >>>>>
> >>>>> Enhanced WAN Failover using WireGuard:
> >>>>>
> >>>>> If you are able to run a second AstLinux instance (or most any
> distro with WireGuard) on a static IPv4 address you can establish an
> always-up WireGuard VPN over the 4G/LTE connection.  When idle the VPN
> consumes less than 0.5 MB/day of data.
> >>>>>
> >>>>> With this setup, both IPv4 and IPv6 can be supported as well as
> allowing inbound traffic to the failover.  When failover occurs, all the
> IPv4/IPv6 traffic is sent over the WireGuard VPN to the "Static" WireGuard
> endpoint.
> >>>>>
> >>>>> To be clear, while the WireGuard VPN is established over IPv4-only,
> the tunnel can simultaneously transport IPv4 and IPv6.
> >>>>>
> >>>>> Example:
> >>>>>
> >>>>> AstLinux "4G/LTE": Cable/DSL Modem on external interface and 4G/LTE
> Modem on failover interface.
> >>>>> --
> >>>>> Internal 1st LAN IPv4: 192.168.101.1/255.255.255.0
> >>>>> Internal 1st LAN IPv6: fda6:a6:a6:d2::1/64
> >>>>> WireGuard IPv4: 10.4.1.10/255.255.255.0
> >>>>> WireGuard IPv6: fda6:a6:a6:ff::10/64
> >>>>> IPv6 ULA/NPTv6: fda6:a6:a6::/56
> >>>>>
> >>>>> AstLinux "Static": Static IPv4 (or IPv4/IPv6) on external interface.
> >>>>> --
> >>>>> Routable Public IPv4: 1.2.3.4
> >>>>> WireGuard IPv4: 10.4.1.1/255.255.255.0
> >>>>> WireGuard IPv6: fda6:a6:a6:ff::1/64
> >>>>> IPv6 ULA/NPTv6: fda6:a6:a6::/56
> >>>>>
> >>>>>
> >>>>> == AstLinux "4G/LTE" Endpoint Configuration
> >>>>>
> >>>>> Network tab -> WireGuard Configuration:
> >>>>>  Tunnel Options:
> >>>>>    IPv4 Address: 10.4.1.10
> >>>>>    IPv4 NetMask: 255.255.255.0
> >>>>>    IPv6/nn Address: fda6:a6:a6:ff::10/64
> >>>>>
> >>>>> -- /mnt/kd/wireguard/peer/wg0.peer snippet --
> >>>>> [Peer]
> >>>>> ## 4G/LTE Endpoint
> >>>>> PublicKey = <For Static Endpoint>
> >>>>> Endpoint = 1.2.3.4:51820
> >>>>> AllowedIPs = 0.0.0.0/0, ::/0
> >>>>> PersistentKeepalive = 25
> >>>>> --
> >>>>>
> >>>>> Network tab -> WAN Failover Configuration:
> >>>>>  WAN Failover:
> >>>>>    Failover: [enabled]
> >>>>>    Secondary Gateway IPv4: 10.4.1.1
> >>>>>    Secondary Gateway IPv6: fda6:a6:a6:ff::1
> >>>>>
> >>>>>  External Failover Interface:
> >>>>>    Connection Type: [DHCP]
> >>>>>
> >>>>>  External Failover Destination Routes:
> >>>>>    IPv4 Routes: 192.168.5.0/24 1.2.3.4
> >>>>>
> >>>>>
> >>>>> Network tab -> Firewall Configuration:
> >>>>>  Firewall Options:
> >>>>>    _x_ Allow WireGuard VPN tunnel to the [1st] LAN Interface(s)
> >>>>>
> >>>>>
> >>>>> == AstLinux "Static" Endpoint Configuration
> >>>>>
> >>>>> Network tab -> WireGuard Configuration:
> >>>>>  Tunnel Options:
> >>>>>    IPv4 Address: 10.4.1.1
> >>>>>    IPv4 NetMask: 255.255.255.0
> >>>>>    IPv6/nn Address: fda6:a6:a6:ff::1/64
> >>>>>
> >>>>>
> >>>>> -- /mnt/kd/wireguard/peer/wg0.peer snippet --
> >>>>> [Peer]
> >>>>> ## Static Endpoint
> >>>>> PublicKey = <For 4G/LTE Endpoint>
> >>>>> AllowedIPs = 10.4.1.10/32, 192.168.101.0/24, fda6:a6:a6:ff::10/128,
> fda6:a6:a6:d2::/64
> >>>>> --
> >>>>>
> >>>>> -- /mnt/kd/rc.conf.d/user.conf snippet --
> >>>>> NAT_FOREIGN_NETWORK="192.168.101.0/24"
> >>>>> --
> >>>>>
> >>>>> ==
> >>>>>
> >>>>> I personally tested this scenario and it worked as expected.
> >>>>>
> >>>>> Note that one AstLinux "Static" server can support many remote
> failover AstLinux "4G/LTE" boxes.
> >>>>>
> >>>>> Tip: if you have shell access to AstLinux "Static", 'ssh
> root@10.4.1.10' will access AstLinux "4G/LTE" over the VPN connection,
> regardless if failover is active.
> >>>>>
> >>>>> Lonnie
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> ==================================
> >>>>> Per a post by Michael Knill "4G backup" I purchased a Netgear
> LB1121-100NAS (North America) supporting PoE and includes a power adapter.
> >>>>>
> >>>>> LTE Modem LB1120 and LB1121 User Manual
> >>>>> https://www.downloads.netgear.com/files/GDC/LB1120/LB112x_UM_EN.pdf
> >>>>>
> >>>>> Overall, I'm pleased with the LB1121, the PoE is good to have, makes
> easy positioning for good reception.
> >>>>>
> >>>>> I also tested the Netgear 6000450 MIMO Antenna, it can add 1-bar,
> but with no antenna and 4 out of 5 bars sitting on the lab bench I was able
> to get 90/20 Mbps (down/up) on a speed test.
> >>>>>
> >>>>> If a person were to mount the modem on a wall next to a window, the
> antenna would be useful to reach over and place on the glass.
> >>>>>
> >>>>> I tested with "Ting" a MVNO (Mobile Virtual Network Operator) for
> T-Mobile's GSM network.  I ordered a GSM SIM card from Ting, the Netgear
> LB1121 comes with an empty SIM slot.
> >>>>>
> >>>>> I connected the Netgear LB1121 to a spare ethernet interface,
> Network tab -> Failover Interface: [eth2] and also ...
> >>>>> -- Network tab -> WAN Failover Configuration: --
> >>>>> External Failover Interface:
> >>>>> Connection Type: [DHCP]
> >>>>>
> >>>>> External Failover Destination Routes:
> >>>>> IPv4 Routes: 192.168.5.0/24
> >>>>> --
> >>>>> If you change the LB1121's IPv4 address, also change the above IPv4
> Routes: as this is required when the LB1121 is set to "Bridge Mode".
> >>>>> Note: WAN Failover is disabled at this point in time.  We are now
> simply defining a 2nd external interface.
> >>>>>
> >>>>> With Ting I needed to edit the APN ...
> >>>>> --
> >>>>> Ting (GSM) T-Mobile
> >>>>> APN: wholesale
> >>>>> --
> >>>>> and the LB1121 easily allows for that via the web interface, which
> defaults to http://192.168.5.1
> >>>>>
> >>>>> Firmware updates are via the web interface, but you must have a SIM
> card activated and installed to perform an upgrade over the GSM network.
> >>>>>
> >>>>> Web interface password changes don't ask for a match, so a typo
> requires a reset to factory defaults to fix it.  But overall, the web
> interface is nicely done.
> >>>>>
> >>>>> After I got the LB1121 configured as desired, working, and firmware
> upgraded, I then switched to "Bridge Mode", depending on your 4G/LTE
> carrier your DHCP will acquire a publicly routable IPv4 address or an
> address that looks public but is actually behind NAT.
> >>>>> BTW: Ting/T-Mobile uses odd "private" address ranges like 25.0.0.0/8
> (UK Ministry of Defense) and 100.128.0.0/9 (T-Mobile), they look publicly
> routable, but they are NAT'ed to a different public address :-(
> >>>>>
> >>>>> On a PoE 802.3af switch, the LB1121 draws 1.1 Watts, cool to the
> touch.
> >>>>>
> >>>>> The main issues are the 4G/LTE networks, the Ting MVNO for T-Mobile
> is IPv4 only, and NAT'ed even when in bridge mode.  So a true failover is
> difficult to do, but by limiting your failover requirements this can still
> be useful.  Below is one such technique using WireGuard VPN.
> >>>>>
> >>>>> I have a test AstLinux box talking to my main AstLinux box over
> WireGuard over 4G/LTE ... works nicely.  Though "PersistentKeepalive = 25"
> is required to deal with the NAT and dynamic addressing.
> >>>>>
> >>>>> FYI: Interestingly, the WireGuard overhead even with a keepalive
> every 25 seconds results in 454 KB/day of data, which at $10/GB is only
> 0.00454 $/day.
> >>>>>
> >>>>> == Dynamic 4G/LTE Modem Endpoint
> >>>>>
> >>>>> -- WireGuard IPv4 10.4.1.10/255.255.255.0 --
> >>>>> [Peer]
> >>>>> ## 4G/LTE Endpoint
> >>>>> PublicKey = <For Static Endpoint>
> >>>>> Endpoint = 1.2.3.4:51820
> >>>>> AllowedIPs = 10.4.1.1/32
> >>>>> PersistentKeepalive = 25
> >>>>> --
> >>>>>
> >>>>> -- Network tab -> WAN Failover Configuration: --
> >>>>> External Failover Interface:
> >>>>> Connection Type: [DHCP]
> >>>>>
> >>>>> External Failover Destination Routes:
> >>>>> IPv4 Routes: 192.168.5.0/24 1.2.3.4
> >>>>> --
> >>>>>
> >>>>> == Static IPv4 1.2.3.4 Endpoint
> >>>>>
> >>>>> -- WireGuard IPv4 10.4.1.1/255.255.255.0 --
> >>>>> [Peer]
> >>>>> ## Static Endpoint
> >>>>> PublicKey = <For 4G/LTE Endpoint>
> >>>>> AllowedIPs = 10.4.1.10/32
> >>>>> --
> >>>>>
> >>>>> iperf3 test across the VPN ...
> >>>>>
> >>>>> 4G/LTE ~ # iperf3 -s
> >>>>>
> >>>>> Static ~ # iperf3 -c 10.4.1.10 -u
> >>>>> Connecting to host 10.4.1.10, port 5201
> >>>>> [  5] local 10.4.1.1 port 37415 connected to 10.4.1.10 port 5201
> >>>>> [ ID] Interval           Transfer     Bitrate         Total Datagrams
> >>>>> [  5]   0.00-1.00   sec   128 KBytes  1.05 Mbits/sec  96
> >>>>> ...
> >>>>> [  5]   9.00-10.00  sec   128 KBytes  1.05 Mbits/sec  96
> >>>>> - - - - - - - - - - - - - - - - - - - - - - - - -
> >>>>> [ ID] Interval           Transfer     Bitrate         Jitter
> Lost/Total Datagrams
> >>>>> [  5]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec  0.000 ms
> 0/959 (0%)  sender
> >>>>> [  5]   0.00-10.16  sec  1.25 MBytes  1.03 Mbits/sec  2.543 ms
> 0/959 (0%)  receiver
> >>>>>
> >>>>>
> >>>>> Typical ping times: 100-400 ms
> >>>>>
> >>>>> Note that without the VPN there would be no way to reach "4G/LTE"
> from "Static" with the network NAT issues described above.
> >>>>>
> >>>>> So with a Netgear LB1121 4G/LTE Modem, by using this WireGuard VPN
> technique on the "Failover Interface" (2nd External) your public server on
> 1.2.3.4 will be able to access a remote AstLinux box via 4G/LTE.
> >>>>>
> >>>>>
> >>>>> Lonnie
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------
> ------------------
> >>>>> Check out the vibrant tech community on one of the world's most
> >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>>>> _______________________________________________
> >>>>> 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....
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------
> ------------------
> >>>>> Check out the vibrant tech community on one of the world's most
> >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>>>> _______________________________________________
> >>>>> 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....
> >>>>
> >>>>
> >>>> ------------------------------------------------------------
> ------------------
> >>>> Check out the vibrant tech community on one of the world's most
> >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>>> _______________________________________________
> >>>> 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....
> >>>>
> >>>> ------------------------------------------------------------
> ------------------
> >>>> Check out the vibrant tech community on one of the world's most
> >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>>> _______________________________________________
> >>>> 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....
> >>>
> >>>
> >>>      ------------------------------------------------------------
> ------------------
> >>>      Check out the vibrant tech community on one of the world's most
> >>>      engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>>      _______________________________________________
> >>>      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....
> >>>
> >>>  ------------------------------------------------------------
> ------------------
> >>>  Check out the vibrant tech community on one of the world's most
> >>>  engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>>  _______________________________________________
> >>>  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....
> >>>
> >>> ------------------------------------------------------------
> ------------------
> >>> Check out the vibrant tech community on one of the world's most
> >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>> _______________________________________________
> >>> 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....
> >>
> >>
> >>   ------------------------------------------------------------
> ------------------
> >>   Check out the vibrant tech community on one of the world's most
> >>   engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>   _______________________________________________
> >>   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....
> >>
> >> ------------------------------------------------------------
> ------------------
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> _______________________________________________
> >> 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....
> >
> >
> >    ------------------------------------------------------------
> ------------------
> >    Check out the vibrant tech community on one of the world's most
> >    engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >    _______________________________________________
> >    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....
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > 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....
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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....

Re: [Astlinux-users] WAN Failover using Netgear LB1121 4G/LTE Modem

[Lonnie A. <li...@lo...>]

I have now more completely tested my WAN Failover using 4G/LTE over WireGuard ...and now works perfectly with Asterisk with a configuration change.

My 4G/LTE over WireGuard tunnel endpoint is with AstLinux on a Linode KVM (as documented previously).  The AstLinux on the Linode KVM instance is not running Asterisk.

Previously my local Asterisk was configured with nat=no and since I have a static IPv4 address my SIP provider has an option to authenticate using the static address (no registration).  If I added the static IPv4 of my Linode KVM instance it mostly worked for outbound calls during failover but would require failover call configuration at the SIP provided end to handle inbound calls.

Instead, I switched my SIP provider configuration to require registration and removed my static IPv4 authentication.  In order to force a quick registration update on the switch I use the wan-failover.script to reload sip:

-- /mnt/kd/wan-failover.script snippet --
  SECONDARY)
    ## Switched to Failover using secondary WAN link
    asterisk -rx "sip reload" >/dev/null
    ;;

  PRIMARY)
    ## Switched back to normal using primary WAN link
    asterisk -rx "sip reload" >/dev/null
    ;;
--

Almost there, but when failover occurs the registration is NAT'ed at the AstLinux on Linode KVM end, so for my SIP provider all it took was to configure my SIP account to support NAT.  Even though my Asterisk is still configured with nat=no, the registration via the failover tunnel now works.

Inbound and outbound SIP calls work perfectly over the 4G/LTE failover.

Most interestingly, the calls keep working during the failover switch and back again ... I was not expecting that, and I am still scratching my head over that.  The active calls do not miss a beat as I see data over my 4G/LTE and then no data over 4G/LTE, the call continues perfectly.  I even have directmedia=no in my provider peer's sip.conf.

Lonnie



> On May 28, 2018, at 8:30 PM, Michael Knill <mic...@ip...> wrote:
> 
> I decided today the architecture I want to test.
> I will be setting up a DR Astlinux box running Asterisk and having a SIP Trunk with a 100 Block number range on it for indial.
> All Astklinux boxes configured for failover will establish a VPN to this box and a SIP Trunk to the DR server will be second choice for outgoing calls. I can set the Caller ID to be anything I want for DR outgoing so no issues there. Billing should be fine also as long as the Originating Caller ID is correct.
> All my providers allow the setting of a call forward on busy (and unreachable) to forward to one of the numbers in the 100 block which is redirected to the associated Astlinux box. So incoming calls are sorted also. If it's the same provider, then all forwarded calls are free.
> 
> I think it should work with no manual intervention required.
> 
> Regards
> Michael Knill
> 
> On 29/5/18, 10:07 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> 
>    Hey Michael,
> 
>    Currently my "cloud" AstLinux Linode KVM (4G/LTE over VPN endpoint) has Asterisk disabled, ASTERISK_DAHDI_DISABLE="yes" so when my main AstLinux box goes to failover the SIP packets originate from my "home" WireGuard private 10.0.0.0/24 address and are NAT'ed at the Linode end.  Normally there is no NAT and SIP packets originate with my public IP.
> 
>    Surprisingly outbound calls work without any changes, though a remote hangup BYE is not received.  Inbound failover could be handled on my SIP provider's platform.
> 
>    I could enable Asterisk at the Linode end and use it as a proxy of sorts.
> 
>    Possibly better, per what you suggested, is to implement an outbound call failover in the "main" Asterisk regardless of the WAN Failover status ... if the standard outbound call fails it tries the call over the 4G/LTE VPN path.
> 
>    I'm still pondering my options.  The exact solution is somewhat dependent on the user's SIP provider.
> 
>    Lonnie
> 
> 
> 
> 
>> On May 28, 2018, at 5:08 PM, Michael Knill <mic...@ip...> wrote:
>> 
>> Hi Lonnie
>> 
>> So what are you trying to solve with Asterisk failover?
>> 
>> Regards
>> Michael Knill
>> 
>> On 28/5/18, 10:00 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>> 
>>   Hi Michael,
>> 
>>   Yes, you can use OpenVPN and WireGuard at the same time, no problem.  I do.
>> 
>>   WireGuard is much faster / more efficient than OpenVPN, mostly since it resides in the kernel and can use multiple cores.  Here are some benchmarks I posted to the WireGuard mailing list:
>> 
>>   https://lists.zx2c4.com/pipermail/wireguard/2017-December/002204.html
>> 
>>   There are user-space implementations of WireGuard, written in Golang, starting to appear for testing, but for non-Linux endpoints I would stick with OpenVPN for now.
>> 
>>   BTW, I currently have WAN Failover on my production AstLinux box using the Netgear LB1121 4G/LTE over WireGuard VPN to a Linode KVM running AstLinux.  Working is dual stack IPv4/IPv6 failover for the AstLinux box itself and any internal network of my choosing.  I have outbound Asterisk failover working, but that is still a work in progress, not sure the best method yet.
>> 
>>   Lonnie
>> 
>> 
>> 
>> 
>>> On May 28, 2018, at 5:03 AM, Michael Knill <mic...@ip...> wrote:
>>> 
>>> Hi group
>>> 
>>> Im ready to do some testing.
>>> I have a number of sites that are set up as OpenVPN Servers. Should there be any issues using Wireguard as well?
>>> PS I just looked up Wireguard and I cant believe the difference in benchmarks to Open VPN. That's crazy!
>>> 
>>> Regards
>>> Michael Knill
>>> 
>>> On 24/5/18, 9:23 am, "Michael Knill" <mic...@ip...> wrote:
>>> 
>>>  Thanks Lonnie. I don't have a specific scenario yet but handy to know its possible.
>>> 
>>>  Regards
>>>  Michael Knill
>>> 
>>>  On 24/5/18, 8:54 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>>> 
>>>      Michael,
>>> 
>>>> So are you saying that you can configure a second external interface and the associated routing to it with the Failover Tab but just leave Failover disabled?
>>> 
>>>      Yes, "External Failover Destination Routes:" automatically defines static routes, automatically removed and added for DHCP changes.
>>> 
>>> 
>>>> If so, I assume it uses the same EXT firewall rules?
>>> 
>>>      Yes.  There is a way to treat EXTIF and EXT2IF firewall rules differently, but the same is usually OK.
>>> 
>>>      Lonnie
>>> 
>>> 
>>> 
>>>> On May 23, 2018, at 5:17 PM, Michael Knill <mic...@ip...> wrote:
>>>> 
>>>> Hi Lonnie
>>>> 
>>>> So are you saying that you can configure a second external interface and the associated routing to it with the Failover Tab but just leave Failover disabled?
>>>> If so, I assume it uses the same EXT firewall rules?
>>>> 
>>>> Regards
>>>> Michael Knill
>>>> 
>>>> On 22/5/18, 8:59 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>>>> 
>>>> Hi Michael,
>>>> 
>>>>> I noticed you also pass the VPN traffic to the site LAN
>>>> 
>>>> Yes, I tried to implement the general case, easy to remove stuff.
>>>> 
>>>>> the VPN would normally just be used for voice traffic and management only.
>>>> 
>>>> In that case "External Failover Destination Routes: IPv4 Routes:" could define all the destination routes you need without "Failover" enabled ... and let Asterisk dynamically choose the SIP route.  Handling inbound calls over the 4G/LTE VPN would also be possible.
>>>> 
>>>> 
>>>> All seems to work well, the only fundamental issue may be the latency of 4G/LTE for SIP traffic ... though clearly much better than no traffic.
>>>> 
>>>> Lonnie
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On May 21, 2018, at 5:36 PM, Michael Knill <mic...@ip...> wrote:
>>>>> 
>>>>> Thanks Lonnie you beat me to it.
>>>>> Interestingly one of my partners is using Asterisk as their Softswitch and they were thinking of setting up a single VPN Tunnel to the SoftSwitch for voice traffic and so everything still works on both the primary and failover links. There should be no failover scripts required!
>>>>> 
>>>>> I noticed you also pass the VPN traffic to the site LAN but this would not actually be required in practice as the VPN would normally just be used for voice traffic and management only. On all VPN connections that run voice traffic I set directmedia=no in sip.conf. PS I actually now use a directmedia ACL on the VPN subnet so I don't need to configure anything. E.g.
>>>>> 
>>>>> directmedia=yes
>>>>> directmediapermit=0.0.0.0/0
>>>>> directmediadeny=<VPN Subnet>
>>>>> 
>>>>> Thanks again Lonnie for testing. Im looking forward to implementing it.
>>>>> 
>>>>> Regards
>>>>> Michael Knill
>>>>> 
>>>>> On 22/5/18, 6:59 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>>>>> 
>>>>> Followup, Enabling Failover using a Netgear LB1121-100NAS (review below):
>>>>> 
>>>>> The basic failover configuration is documented here:
>>>>> 
>>>>> WAN Failover
>>>>> https://doc.astlinux-project.org/userdoc:tt_wan_failover
>>>>> 
>>>>> Since most 4G/LTE providers only support outbound-only (NAT'ed), IPv4-only, dynamic IPv4 address networks, any basic failover configuration over 4G/LTE must deal with those constraints.
>>>>> 
>>>>> But, there is another way ...
>>>>> 
>>>>> Enhanced WAN Failover using WireGuard:
>>>>> 
>>>>> If you are able to run a second AstLinux instance (or most any distro with WireGuard) on a static IPv4 address you can establish an always-up WireGuard VPN over the 4G/LTE connection.  When idle the VPN consumes less than 0.5 MB/day of data.
>>>>> 
>>>>> With this setup, both IPv4 and IPv6 can be supported as well as allowing inbound traffic to the failover.  When failover occurs, all the IPv4/IPv6 traffic is sent over the WireGuard VPN to the "Static" WireGuard endpoint.
>>>>> 
>>>>> To be clear, while the WireGuard VPN is established over IPv4-only, the tunnel can simultaneously transport IPv4 and IPv6.
>>>>> 
>>>>> Example:
>>>>> 
>>>>> AstLinux "4G/LTE": Cable/DSL Modem on external interface and 4G/LTE Modem on failover interface.
>>>>> --
>>>>> Internal 1st LAN IPv4: 192.168.101.1/255.255.255.0
>>>>> Internal 1st LAN IPv6: fda6:a6:a6:d2::1/64
>>>>> WireGuard IPv4: 10.4.1.10/255.255.255.0
>>>>> WireGuard IPv6: fda6:a6:a6:ff::10/64
>>>>> IPv6 ULA/NPTv6: fda6:a6:a6::/56
>>>>> 
>>>>> AstLinux "Static": Static IPv4 (or IPv4/IPv6) on external interface.
>>>>> --
>>>>> Routable Public IPv4: 1.2.3.4
>>>>> WireGuard IPv4: 10.4.1.1/255.255.255.0
>>>>> WireGuard IPv6: fda6:a6:a6:ff::1/64
>>>>> IPv6 ULA/NPTv6: fda6:a6:a6::/56
>>>>> 
>>>>> 
>>>>> == AstLinux "4G/LTE" Endpoint Configuration
>>>>> 
>>>>> Network tab -> WireGuard Configuration:
>>>>>  Tunnel Options:
>>>>>    IPv4 Address: 10.4.1.10
>>>>>    IPv4 NetMask: 255.255.255.0
>>>>>    IPv6/nn Address: fda6:a6:a6:ff::10/64
>>>>> 
>>>>> -- /mnt/kd/wireguard/peer/wg0.peer snippet --
>>>>> [Peer]
>>>>> ## 4G/LTE Endpoint
>>>>> PublicKey = <For Static Endpoint>
>>>>> Endpoint = 1.2.3.4:51820
>>>>> AllowedIPs = 0.0.0.0/0, ::/0
>>>>> PersistentKeepalive = 25
>>>>> --
>>>>> 
>>>>> Network tab -> WAN Failover Configuration:
>>>>>  WAN Failover:
>>>>>    Failover: [enabled]
>>>>>    Secondary Gateway IPv4: 10.4.1.1
>>>>>    Secondary Gateway IPv6: fda6:a6:a6:ff::1
>>>>> 
>>>>>  External Failover Interface:
>>>>>    Connection Type: [DHCP]
>>>>> 
>>>>>  External Failover Destination Routes: 
>>>>>    IPv4 Routes: 192.168.5.0/24 1.2.3.4
>>>>> 
>>>>> 
>>>>> Network tab -> Firewall Configuration:
>>>>>  Firewall Options:
>>>>>    _x_ Allow WireGuard VPN tunnel to the [1st] LAN Interface(s)
>>>>> 
>>>>> 
>>>>> == AstLinux "Static" Endpoint Configuration
>>>>> 
>>>>> Network tab -> WireGuard Configuration:
>>>>>  Tunnel Options:
>>>>>    IPv4 Address: 10.4.1.1
>>>>>    IPv4 NetMask: 255.255.255.0
>>>>>    IPv6/nn Address: fda6:a6:a6:ff::1/64
>>>>> 
>>>>> 
>>>>> -- /mnt/kd/wireguard/peer/wg0.peer snippet --
>>>>> [Peer]
>>>>> ## Static Endpoint
>>>>> PublicKey = <For 4G/LTE Endpoint>
>>>>> AllowedIPs = 10.4.1.10/32, 192.168.101.0/24, fda6:a6:a6:ff::10/128, fda6:a6:a6:d2::/64
>>>>> --
>>>>> 
>>>>> -- /mnt/kd/rc.conf.d/user.conf snippet --
>>>>> NAT_FOREIGN_NETWORK="192.168.101.0/24"
>>>>> --
>>>>> 
>>>>> ==
>>>>> 
>>>>> I personally tested this scenario and it worked as expected.
>>>>> 
>>>>> Note that one AstLinux "Static" server can support many remote failover AstLinux "4G/LTE" boxes.
>>>>> 
>>>>> Tip: if you have shell access to AstLinux "Static", 'ssh root@10.4.1.10' will access AstLinux "4G/LTE" over the VPN connection, regardless if failover is active.
>>>>> 
>>>>> Lonnie
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ==================================
>>>>> Per a post by Michael Knill "4G backup" I purchased a Netgear LB1121-100NAS (North America) supporting PoE and includes a power adapter.
>>>>> 
>>>>> LTE Modem LB1120 and LB1121 User Manual
>>>>> https://www.downloads.netgear.com/files/GDC/LB1120/LB112x_UM_EN.pdf
>>>>> 
>>>>> Overall, I'm pleased with the LB1121, the PoE is good to have, makes easy positioning for good reception.
>>>>> 
>>>>> I also tested the Netgear 6000450 MIMO Antenna, it can add 1-bar, but with no antenna and 4 out of 5 bars sitting on the lab bench I was able to get 90/20 Mbps (down/up) on a speed test.
>>>>> 
>>>>> If a person were to mount the modem on a wall next to a window, the antenna would be useful to reach over and place on the glass.
>>>>> 
>>>>> I tested with "Ting" a MVNO (Mobile Virtual Network Operator) for T-Mobile's GSM network.  I ordered a GSM SIM card from Ting, the Netgear LB1121 comes with an empty SIM slot.
>>>>> 
>>>>> I connected the Netgear LB1121 to a spare ethernet interface, Network tab -> Failover Interface: [eth2] and also ...
>>>>> -- Network tab -> WAN Failover Configuration: --
>>>>> External Failover Interface:
>>>>> Connection Type: [DHCP]
>>>>> 
>>>>> External Failover Destination Routes:
>>>>> IPv4 Routes: 192.168.5.0/24
>>>>> --
>>>>> If you change the LB1121's IPv4 address, also change the above IPv4 Routes: as this is required when the LB1121 is set to "Bridge Mode".
>>>>> Note: WAN Failover is disabled at this point in time.  We are now simply defining a 2nd external interface.
>>>>> 
>>>>> With Ting I needed to edit the APN ...
>>>>> --
>>>>> Ting (GSM) T-Mobile
>>>>> APN: wholesale
>>>>> --
>>>>> and the LB1121 easily allows for that via the web interface, which defaults to http://192.168.5.1
>>>>> 
>>>>> Firmware updates are via the web interface, but you must have a SIM card activated and installed to perform an upgrade over the GSM network.
>>>>> 
>>>>> Web interface password changes don't ask for a match, so a typo requires a reset to factory defaults to fix it.  But overall, the web interface is nicely done.
>>>>> 
>>>>> After I got the LB1121 configured as desired, working, and firmware upgraded, I then switched to "Bridge Mode", depending on your 4G/LTE carrier your DHCP will acquire a publicly routable IPv4 address or an address that looks public but is actually behind NAT.
>>>>> BTW: Ting/T-Mobile uses odd "private" address ranges like 25.0.0.0/8 (UK Ministry of Defense) and 100.128.0.0/9 (T-Mobile), they look publicly routable, but they are NAT'ed to a different public address :-(
>>>>> 
>>>>> On a PoE 802.3af switch, the LB1121 draws 1.1 Watts, cool to the touch.
>>>>> 
>>>>> The main issues are the 4G/LTE networks, the Ting MVNO for T-Mobile is IPv4 only, and NAT'ed even when in bridge mode.  So a true failover is difficult to do, but by limiting your failover requirements this can still be useful.  Below is one such technique using WireGuard VPN.
>>>>> 
>>>>> I have a test AstLinux box talking to my main AstLinux box over WireGuard over 4G/LTE ... works nicely.  Though "PersistentKeepalive = 25" is required to deal with the NAT and dynamic addressing.
>>>>> 
>>>>> FYI: Interestingly, the WireGuard overhead even with a keepalive every 25 seconds results in 454 KB/day of data, which at $10/GB is only 0.00454 $/day.
>>>>> 
>>>>> == Dynamic 4G/LTE Modem Endpoint
>>>>> 
>>>>> -- WireGuard IPv4 10.4.1.10/255.255.255.0 --
>>>>> [Peer]
>>>>> ## 4G/LTE Endpoint
>>>>> PublicKey = <For Static Endpoint>
>>>>> Endpoint = 1.2.3.4:51820
>>>>> AllowedIPs = 10.4.1.1/32
>>>>> PersistentKeepalive = 25
>>>>> --
>>>>> 
>>>>> -- Network tab -> WAN Failover Configuration: --
>>>>> External Failover Interface:
>>>>> Connection Type: [DHCP]
>>>>> 
>>>>> External Failover Destination Routes:
>>>>> IPv4 Routes: 192.168.5.0/24 1.2.3.4
>>>>> --
>>>>> 
>>>>> == Static IPv4 1.2.3.4 Endpoint
>>>>> 
>>>>> -- WireGuard IPv4 10.4.1.1/255.255.255.0 --
>>>>> [Peer]
>>>>> ## Static Endpoint
>>>>> PublicKey = <For 4G/LTE Endpoint>
>>>>> AllowedIPs = 10.4.1.10/32
>>>>> --
>>>>> 
>>>>> iperf3 test across the VPN ...
>>>>> 
>>>>> 4G/LTE ~ # iperf3 -s
>>>>> 
>>>>> Static ~ # iperf3 -c 10.4.1.10 -u
>>>>> Connecting to host 10.4.1.10, port 5201
>>>>> [  5] local 10.4.1.1 port 37415 connected to 10.4.1.10 port 5201
>>>>> [ ID] Interval           Transfer     Bitrate         Total Datagrams
>>>>> [  5]   0.00-1.00   sec   128 KBytes  1.05 Mbits/sec  96  
>>>>> ...
>>>>> [  5]   9.00-10.00  sec   128 KBytes  1.05 Mbits/sec  96  
>>>>> - - - - - - - - - - - - - - - - - - - - - - - - -
>>>>> [ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
>>>>> [  5]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec  0.000 ms  0/959 (0%)  sender
>>>>> [  5]   0.00-10.16  sec  1.25 MBytes  1.03 Mbits/sec  2.543 ms  0/959 (0%)  receiver
>>>>> 
>>>>> 
>>>>> Typical ping times: 100-400 ms
>>>>> 
>>>>> Note that without the VPN there would be no way to reach "4G/LTE" from "Static" with the network NAT issues described above.
>>>>> 
>>>>> So with a Netgear LB1121 4G/LTE Modem, by using this WireGuard VPN technique on the "Failover Interface" (2nd External) your public server on 1.2.3.4 will be able to access a remote AstLinux box via 4G/LTE.
>>>>> 
>>>>> 
>>>>> Lonnie
>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> 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....
>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> 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....
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> 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....
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> 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....
>>> 
>>> 
>>>      ------------------------------------------------------------------------------
>>>      Check out the vibrant tech community on one of the world's most
>>>      engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>      _______________________________________________
>>>      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....
>>> 
>>>  ------------------------------------------------------------------------------
>>>  Check out the vibrant tech community on one of the world's most
>>>  engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>  _______________________________________________
>>>  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....
>>> 
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> 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....
>> 
>> 
>>   ------------------------------------------------------------------------------
>>   Check out the vibrant tech community on one of the world's most
>>   engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>   _______________________________________________
>>   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....
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> 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....
> 
> 
>    ------------------------------------------------------------------------------
>    Check out the vibrant tech community on one of the world's most
>    engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>    _______________________________________________
>    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....
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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....

Re: [Astlinux-users] ddclient on Astlinux 1.3.3 ( and some earlier? )

[Lonnie A. <li...@lo...>]

Hi John,

First, let's see if your file editing has caused issues, does this output anything ?
--
show-union | grep ddclient
--

What dynamic DNS service are you using ?

Using sanitized passwords and such, what do you think your /etc/ddclient.conf should look like ?

Lonnie



> On Jun 2, 2018, at 3:45 PM, John Novack SCII_U <jn...@co...> wrote:
> 
> I have been attempting to get ddclient working on the later versions and it seems that the "user defined" input to the GUI is not working properly
> Because of the free service we use none of the canned defined services cannot be used
> Input the data and then reboot, and no evidence that ddclient runs. The input information is correct in gui.network.conf, but nothing in /var/log/messages there was an attempt.
> This USED to work in prehistoric times ( 1.4.44 ) and probably some later ones
> In order to get it to work, I had to do several things  to please ddclient that generally are not correct ( or dangerous? )
> Manually create the file in /etc/ddclient/ddclient.conf
> manual create directory /var/cache/ddclient
> 
> This does persist a reboot, but I am sure there is a better/proper way
> Something in the ddclient script not revised for AstLinux?
> Something I am not doing correctly?
> 
> 
> John Novack
> 
> 
> -- 
> Dog is my Co-Pilot
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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....
> 
> 

Re: [Astlinux-users] ddclient on Astlinux 1.3.3 ( and some earlier? )

[Michael K. <li...@mk...>]

Hi John,

do you have read our Wiki page?
https://doc.astlinux.org/userdoc:tt_dynamic_dns_client

Sent from a mobile device.

Michael Keuter

> Am 02.06.2018 um 22:45 schrieb John Novack SCII_U <jn...@co...>:
> 
> I have been attempting to get ddclient working on the later versions and it seems that the "user defined" input to the GUI is not working properly
> Because of the free service we use none of the canned defined services cannot be used
> Input the data and then reboot, and no evidence that ddclient runs. The input information is correct in gui.network.conf, but nothing in /var/log/messages there was an attempt.
> This USED to work in prehistoric times ( 1.4.44 ) and probably some later ones
> In order to get it to work, I had to do several things  to please ddclient that generally are not correct ( or dangerous? )
> Manually create the file in /etc/ddclient/ddclient.conf
> manual create directory /var/cache/ddclient
> 
> This does persist a reboot, but I am sure there is a better/proper way
> Something in the ddclient script not revised for AstLinux?
> Something I am not doing correctly?
> 
> 
> John Novack
> 
> 
> -- 
> Dog is my Co-Pilot
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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] ddclient on Astlinux 1.3.3 ( and some earlier? )

[John N. S. <jn...@co...>]

I have been attempting to get ddclient working on the later versions and it seems that the "user defined" input to the GUI is not working properly
Because of the free service we use none of the canned defined services cannot be used
Input the data and then reboot, and no evidence that ddclient runs. The input information is correct in gui.network.conf, but nothing in /var/log/messages there was an attempt.
This USED to work in prehistoric times ( 1.4.44 ) and probably some later ones
In order to get it to work, I had to do several things  to please ddclient that generally are not correct ( or dangerous? )
Manually create the file in /etc/ddclient/ddclient.conf
manual create directory /var/cache/ddclient

This does persist a reboot, but I am sure there is a better/proper way
Something in the ddclient script not revised for AstLinux?
Something I am not doing correctly?


John Novack


-- 
Dog is my Co-Pilot

Re: [Astlinux-users] Resource requirements for 150 seat system

[Michael K. <mic...@ip...>]

Hmm interesting idea.

Regards
Michael Knill

From: Michael Keuter <li...@mk...>
Reply-To: AstLinux List <ast...@li...>
Date: Saturday, 2 June 2018 at 7:40 pm
To: AstLinux List <ast...@li...>
Subject: Re: [Astlinux-users] Resource requirements for 150 seat system

Hi Michael,

The main point with real servers could be, that there might be a lot of drivers missing in AstLinux (especially harddisk controllers and NICs).
While there are all drivers needed for virtualization already included within AstLinux.

You could easily buy a server, install the Debian-based free Proxmox VE and then install AstLinux in Proxmox without any driver issues.

Sent from a mobile device.

Michael Keuter

Am 02.06.2018 um 03:44 schrieb Michael Knill <mic...@ip...<mailto:mic...@ip...>>:
Thanks Michael

Yes certainly the most flexible but if I have to provide the server then I don't see any point virtualising it!

Regards
Michael Knill

From: Michael Keuter <li...@mk...<mailto:li...@mk...>>
Reply-To: AstLinux List <ast...@li...<mailto:ast...@li...>>
Date: Saturday, 2 June 2018 at 11:40 am
To: AstLinux List <ast...@li...<mailto:ast...@li...>>
Subject: Re: [Astlinux-users] Resource requirements for 150 seat system

Hi Michael,

I usually use for systems with more than 60-80 seats  AstLinux in a virtual machine running under VMWare or Proxmox. Theses systems have usually a dedicated firewall (like PFSense or similar).

Sent from a mobile device.

Michael Keuter

Am 02.06.2018 um 03:33 schrieb Michael Knill <mic...@ip...<mailto:mic...@ip...>>:
Hi All

I am quoting for a 120 seat system which will likely expand to 150 seats. It should be pretty basic with no significant firewalling required.
Do you thing the Qotom box should be fine?
Should we include a high end server in the Astlinux tested architectures?

Regards
Michael Knill
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot
_______________________________________________
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...>.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot
_______________________________________________
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...>.