astlinux-users — AstLinux Users Mailing List

Re: [Astlinux-users] Weird routing problem

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

Great thanks Lonnie!

Regards
Michael Knill

On 27/3/21, 10:57 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    It tells you that 0 packets were SNAT'ed via eth3 ... so it seems your fix worked.

    Lonnie


    > On Mar 26, 2021, at 5:10 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > Hi Lonnie
    > 
    > I haven’t managed to test out this site yet but as they are currently having an internet outage I thought I would hop in and have a look as ppp0 is now down.
    > How is the best way to determine that SNAT is turned off other than being onsite?
    > 
    > I tried 'arno-iptables-firewall status':
    > ....
    > Chain OUTBOUND_SNAT (0 references)
    >    pkts      bytes target     prot opt in     out     source               destination
    > 1172540 140692582 SNAT       all  --  *      ppp+    172.30.10.2         !172.30.10.2          to:139.218.40.144
    >       0        0 SNAT       all  --  *      eth3    172.30.10.2         !172.30.10.2          to:139.218.40.144
    > ....
    > 
    > Has that told me anything.
    > 
    > Regards
    > Michael Knill
    > 
    > On 20/3/21, 9:30 am, "Michael Knill" <mic...@ip...> wrote:
    > 
    >    Thanks. Will do.
    > 
    >    Regards
    >    Michael Knill
    > 
    >    On 20/3/21, 9:29 am, "Lonnie Abelbeck" <li...@lo...> wrote:
    > 
    >> So just to confirm, there shouldn't be any issues in having this in my default wan-failover.script e.g. whether outbound-snat is configured or not?
    > 
    >        Correct, the OUTBOUND_SNAT nat chain should only exist when the outbound-snat plugin is enabled.
    > 
    >        But test anyway :-)
    > 
    >        Lonnie
    > 
    > 
    >> On Mar 19, 2021, at 5:13 PM, Michael Knill <mic...@ip...> wrote:
    >> 
    >> Thanks Lonnie
    >> 
    >> So just to confirm, there shouldn't be any issues in having this in my default wan-failover.script e.g. whether outbound-snat is configured or not?
    >> 
    >> Regards
    >> Michael Knill
    >> 
    >> On 20/3/21, 9:08 am, "Lonnie Abelbeck" <li...@lo...> wrote:
    >> 
    >>  Hi Michael,
    >> 
    >>  Again off the top of my head (needs testing), this would be more general...
    >>  -- /mnt/kd/wan-failover.script snippet --
    >> 
    >>     SECONDARY)
    >>  ...
    >>       ## Disable outbound-snat plugin in iptables
    >>       if iptables -t nat -nL OUTBOUND_SNAT >/dev/null 2>&1; then
    >>         iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
    >>       fi
    >>       ;;
    >> 
    >>     PRIMARY)
    >>  ...
    >>       ## Re-Enable outbound-snat plugin
    >>       if iptables -t nat -nL OUTBOUND_SNAT >/dev/null 2>&1; then
    >>         iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
    >>       fi
    >>       ;;
    >>  --
    >> 
    >>  I'm having second thoughts about editing the ENABLED variable ... what if the box was rebooted while on failover, with ENABLED set to 0 on SECONDARY you would have effectively disabled the outbound-snat plugin after reboot.
    >> 
    >>  But, the above snippet should work whether the outbound-snat plugin is enabled or not.
    >> 
    >>  But still not perfect.
    >> 
    >>> PS. Would this be worth doing as part of the standard failover as I cant think of any instance where we would not want to disable SNAT when it fails over to another WAN interface.
    >> 
    >>  Yes, but I doubt the outbound-snat plugin is enabled very commonly, implying multiple IPv4 WAN addresses.  My first though is to do as above in the wan-failover.script.
    >> 
    >>  Lonnie
    >> 
    >> 
    >>> On Mar 19, 2021, at 4:05 PM, Michael Knill <mic...@ip...> wrote:
    >>> 
    >>> Thanks Lonnie
    >>> 
    >>> Sorry for the late reply. Yes I'm using the outbound-snat plugin.
    >>> So just to confirm:
    >>> SECONDARY)
    >>> ....
    >>>   ## Disable outbound-snat plugin in both iptables and config file in case of reboot
    >>>   iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
    >>>   sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
    >>>   ;;
    >>> 
    >>> PRIMARY)
    >>> ...
    >>>   ## Re-Enable outbound-snat plugin and config file
    >>>   iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
    >>>   sed -i 's/^ENABLED=.*$/ENABLED=1/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
    >>>   ;;
    >>> 
    >>> I'm thinking that I might look at OUTBOUND_SNAT_NET_HOST to see if something is set to make the decision on whether I disable and re-enable so it can be a generic script.
    >>> 
    >>> PS. Would this be worth doing as part of the standard failover as I cant think of any instance where we would not want to disable SNAT when it fails over to another WAN interface.
    >>> 
    >>> Regards
    >>> Michael Knill
    >>> 
    >>> On 18/3/21, 1:49 am, "Lonnie Abelbeck" <li...@lo...> wrote:
    >>> 
    >>> Hi Michael,
    >>> 
    >>> When you say you have SNAT configured, are you using the nat-loopback plugin or the outbound-snat plugin ?
    >>> 
    >>> Either of those require obtaining the WAN IPv4 address to attach iptables "-j SNAT --to-source $ip" rules, and as written only look at the primary external address.  Even if the Failover interface was looked at, the firewall would have to be rebuilt for the failover context switch with the /mnt/kd/wan-failover.script .
    >>> 
    >>> Question, does either of these plugins make sense for a failover situation ?
    >>> 
    >>> Possibly you want to disable the outbound-snat plugin on failover and re-enable it on return to primary ?
    >>> 
    >>> If you have the special case of the outbound-snat plugin enabled, you could (untested code):
    >>> 
    >>> -- /mnt/kd/wan-failover.script snippet --
    >>> 
    >>> SECONDARY)
    >>>   ## Switched to Failover using secondary WAN link
    >>> 
    >>>   ## Disable outbound-snat plugin
    >>>   iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
    >>>   ;;
    >>> 
    >>> PRIMARY)
    >>>   ## Switched back to normal using primary WAN link
    >>> 
    >>>   ## Re-Enable outbound-snat plugin
    >>>   iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
    >>>   ;;
    >>> 
    >>> --
    >>> but this is somewhat fragile, such that if the firewall was restarted during failover it would revert to the PRIMARY setting.  To be less fragile, you could also add:
    >>> --
    >>> sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf"
    >>> --
    >>> and ENABLED=1 on return to PRIMARY.
    >>> 
    >>> 
    >>> Lonnie
    >>> 
    >>> 
    >>> 
    >>>> On Mar 17, 2021, at 1:16 AM, Michael Knill <mic...@ip...> wrote:
    >>>> 
    >>>> Grr problem now found. I had SNAT configured which didn't work on the second WAN connection.
    >>>> Any way I can fix this e.g. don't do SNAT on the failover WAN?
    >>>> 
    >>>> Regards
    >>>> Michael Knill
    >>>> 
    >>>> From: Michael Knill <mic...@ip...>
    >>>> Reply to: AstLinux List <ast...@li...>
    >>>> Date: Wednesday, 17 March 2021 at 4:27 pm
    >>>> To: AstLinux List <ast...@li...>
    >>>> Subject: [Astlinux-users] Weird routing problem
    >>>> 
    >>>> Hi Group
    >>>> 
    >>>> I'm currently at a site that has a primary and failover WAN connection and a two LAN connections. The primary WAN connection has failed over to the secondary WAN connection however it is only working on one of the LAN interfaces and not the other. I can ping the interface address fine so its not an interface problem.
    >>>> 
    >>>> Does anyone have any idea why this would be happenning?
    >>>> 
    >>>> Regards
    >>>> Michael Knill
    >>>> _______________________________________________
    >>>> Astlinux-users mailing list
    >>>> Ast...@li...
    >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
    >>>> 
    >>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    >>> 
    >>> 
    >>> 
    >>> _______________________________________________
    >>> Astlinux-users mailing list
    >>> Ast...@li...
    >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
    >>> 
    >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    >>> 
    >>> 
    >>> _______________________________________________
    >>> Astlinux-users mailing list
    >>> Ast...@li...
    >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
    >>> 
    >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    >> 
    >> 
    >> 
    >>  _______________________________________________
    >>  Astlinux-users mailing list
    >>  Ast...@li...
    >>  https://lists.sourceforge.net/lists/listinfo/astlinux-users
    >> 
    >>  Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    >> 
    >> 
    >> _______________________________________________
    >> Astlinux-users mailing list
    >> Ast...@li...
    >> https://lists.sourceforge.net/lists/listinfo/astlinux-users
    >> 
    >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    > 
    > 
    > 
    >        _______________________________________________
    >        Astlinux-users mailing list
    >        Ast...@li...
    >        https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    >        Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    > 
    > 
    >    _______________________________________________
    >    Astlinux-users mailing list
    >    Ast...@li...
    >    https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    >    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    > 
    > 
    > _______________________________________________
    > Astlinux-users mailing list
    > Ast...@li...
    > https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....



    _______________________________________________
    Astlinux-users mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-users

    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Weird routing problem

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

It tells you that 0 packets were SNAT'ed via eth3 ... so it seems your fix worked.

Lonnie


> On Mar 26, 2021, at 5:10 PM, Michael Knill <mic...@ip...> wrote:
> 
> Hi Lonnie
> 
> I haven’t managed to test out this site yet but as they are currently having an internet outage I thought I would hop in and have a look as ppp0 is now down.
> How is the best way to determine that SNAT is turned off other than being onsite?
> 
> I tried 'arno-iptables-firewall status':
> ....
> Chain OUTBOUND_SNAT (0 references)
>    pkts      bytes target     prot opt in     out     source               destination
> 1172540 140692582 SNAT       all  --  *      ppp+    172.30.10.2         !172.30.10.2          to:139.218.40.144
>       0        0 SNAT       all  --  *      eth3    172.30.10.2         !172.30.10.2          to:139.218.40.144
> ....
> 
> Has that told me anything.
> 
> Regards
> Michael Knill
> 
> On 20/3/21, 9:30 am, "Michael Knill" <mic...@ip...> wrote:
> 
>    Thanks. Will do.
> 
>    Regards
>    Michael Knill
> 
>    On 20/3/21, 9:29 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> 
>> So just to confirm, there shouldn't be any issues in having this in my default wan-failover.script e.g. whether outbound-snat is configured or not?
> 
>        Correct, the OUTBOUND_SNAT nat chain should only exist when the outbound-snat plugin is enabled.
> 
>        But test anyway :-)
> 
>        Lonnie
> 
> 
>> On Mar 19, 2021, at 5:13 PM, Michael Knill <mic...@ip...> wrote:
>> 
>> Thanks Lonnie
>> 
>> So just to confirm, there shouldn't be any issues in having this in my default wan-failover.script e.g. whether outbound-snat is configured or not?
>> 
>> Regards
>> Michael Knill
>> 
>> On 20/3/21, 9:08 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>> 
>>  Hi Michael,
>> 
>>  Again off the top of my head (needs testing), this would be more general...
>>  -- /mnt/kd/wan-failover.script snippet --
>> 
>>     SECONDARY)
>>  ...
>>       ## Disable outbound-snat plugin in iptables
>>       if iptables -t nat -nL OUTBOUND_SNAT >/dev/null 2>&1; then
>>         iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
>>       fi
>>       ;;
>> 
>>     PRIMARY)
>>  ...
>>       ## Re-Enable outbound-snat plugin
>>       if iptables -t nat -nL OUTBOUND_SNAT >/dev/null 2>&1; then
>>         iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
>>       fi
>>       ;;
>>  --
>> 
>>  I'm having second thoughts about editing the ENABLED variable ... what if the box was rebooted while on failover, with ENABLED set to 0 on SECONDARY you would have effectively disabled the outbound-snat plugin after reboot.
>> 
>>  But, the above snippet should work whether the outbound-snat plugin is enabled or not.
>> 
>>  But still not perfect.
>> 
>>> PS. Would this be worth doing as part of the standard failover as I cant think of any instance where we would not want to disable SNAT when it fails over to another WAN interface.
>> 
>>  Yes, but I doubt the outbound-snat plugin is enabled very commonly, implying multiple IPv4 WAN addresses.  My first though is to do as above in the wan-failover.script.
>> 
>>  Lonnie
>> 
>> 
>>> On Mar 19, 2021, at 4:05 PM, Michael Knill <mic...@ip...> wrote:
>>> 
>>> Thanks Lonnie
>>> 
>>> Sorry for the late reply. Yes I'm using the outbound-snat plugin.
>>> So just to confirm:
>>> SECONDARY)
>>> ....
>>>   ## Disable outbound-snat plugin in both iptables and config file in case of reboot
>>>   iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
>>>   sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
>>>   ;;
>>> 
>>> PRIMARY)
>>> ...
>>>   ## Re-Enable outbound-snat plugin and config file
>>>   iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
>>>   sed -i 's/^ENABLED=.*$/ENABLED=1/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
>>>   ;;
>>> 
>>> I'm thinking that I might look at OUTBOUND_SNAT_NET_HOST to see if something is set to make the decision on whether I disable and re-enable so it can be a generic script.
>>> 
>>> PS. Would this be worth doing as part of the standard failover as I cant think of any instance where we would not want to disable SNAT when it fails over to another WAN interface.
>>> 
>>> Regards
>>> Michael Knill
>>> 
>>> On 18/3/21, 1:49 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>>> 
>>> Hi Michael,
>>> 
>>> When you say you have SNAT configured, are you using the nat-loopback plugin or the outbound-snat plugin ?
>>> 
>>> Either of those require obtaining the WAN IPv4 address to attach iptables "-j SNAT --to-source $ip" rules, and as written only look at the primary external address.  Even if the Failover interface was looked at, the firewall would have to be rebuilt for the failover context switch with the /mnt/kd/wan-failover.script .
>>> 
>>> Question, does either of these plugins make sense for a failover situation ?
>>> 
>>> Possibly you want to disable the outbound-snat plugin on failover and re-enable it on return to primary ?
>>> 
>>> If you have the special case of the outbound-snat plugin enabled, you could (untested code):
>>> 
>>> -- /mnt/kd/wan-failover.script snippet --
>>> 
>>> SECONDARY)
>>>   ## Switched to Failover using secondary WAN link
>>> 
>>>   ## Disable outbound-snat plugin
>>>   iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
>>>   ;;
>>> 
>>> PRIMARY)
>>>   ## Switched back to normal using primary WAN link
>>> 
>>>   ## Re-Enable outbound-snat plugin
>>>   iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
>>>   ;;
>>> 
>>> --
>>> but this is somewhat fragile, such that if the firewall was restarted during failover it would revert to the PRIMARY setting.  To be less fragile, you could also add:
>>> --
>>> sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf"
>>> --
>>> and ENABLED=1 on return to PRIMARY.
>>> 
>>> 
>>> Lonnie
>>> 
>>> 
>>> 
>>>> On Mar 17, 2021, at 1:16 AM, Michael Knill <mic...@ip...> wrote:
>>>> 
>>>> Grr problem now found. I had SNAT configured which didn't work on the second WAN connection.
>>>> Any way I can fix this e.g. don't do SNAT on the failover WAN?
>>>> 
>>>> Regards
>>>> Michael Knill
>>>> 
>>>> From: Michael Knill <mic...@ip...>
>>>> Reply to: AstLinux List <ast...@li...>
>>>> Date: Wednesday, 17 March 2021 at 4:27 pm
>>>> To: AstLinux List <ast...@li...>
>>>> Subject: [Astlinux-users] Weird routing problem
>>>> 
>>>> Hi Group
>>>> 
>>>> I'm currently at a site that has a primary and failover WAN connection and a two LAN connections. The primary WAN connection has failed over to the secondary WAN connection however it is only working on one of the LAN interfaces and not the other. I can ping the interface address fine so its not an interface problem.
>>>> 
>>>> Does anyone have any idea why this would be happenning?
>>>> 
>>>> Regards
>>>> Michael Knill
>>>> _______________________________________________
>>>> Astlinux-users mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>> 
>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>> 
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>> 
>>> 
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>> 
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>> 
>> 
>> 
>>  _______________________________________________
>>  Astlinux-users mailing list
>>  Ast...@li...
>>  https://lists.sourceforge.net/lists/listinfo/astlinux-users
>> 
>>  Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>> 
>> 
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> 
>        _______________________________________________
>        Astlinux-users mailing list
>        Ast...@li...
>        https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
>        Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
>    _______________________________________________
>    Astlinux-users mailing list
>    Ast...@li...
>    https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
>    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> _______________________________________________
> 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] Weird routing problem

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

Hi Lonnie

I haven’t managed to test out this site yet but as they are currently having an internet outage I thought I would hop in and have a look as ppp0 is now down.
How is the best way to determine that SNAT is turned off other than being onsite?

I tried 'arno-iptables-firewall status':
....
Chain OUTBOUND_SNAT (0 references)
    pkts      bytes target     prot opt in     out     source               destination
 1172540 140692582 SNAT       all  --  *      ppp+    172.30.10.2         !172.30.10.2          to:139.218.40.144
       0        0 SNAT       all  --  *      eth3    172.30.10.2         !172.30.10.2          to:139.218.40.144
....

Has that told me anything.

Regards
Michael Knill

On 20/3/21, 9:30 am, "Michael Knill" <mic...@ip...> wrote:

    Thanks. Will do.

    Regards
    Michael Knill

    On 20/3/21, 9:29 am, "Lonnie Abelbeck" <li...@lo...> wrote:

        > So just to confirm, there shouldn't be any issues in having this in my default wan-failover.script e.g. whether outbound-snat is configured or not?

        Correct, the OUTBOUND_SNAT nat chain should only exist when the outbound-snat plugin is enabled.

        But test anyway :-)

        Lonnie


        > On Mar 19, 2021, at 5:13 PM, Michael Knill <mic...@ip...> wrote:
        > 
        > Thanks Lonnie
        > 
        > So just to confirm, there shouldn't be any issues in having this in my default wan-failover.script e.g. whether outbound-snat is configured or not?
        > 
        > Regards
        > Michael Knill
        > 
        > On 20/3/21, 9:08 am, "Lonnie Abelbeck" <li...@lo...> wrote:
        > 
        >   Hi Michael,
        > 
        >   Again off the top of my head (needs testing), this would be more general...
        >   -- /mnt/kd/wan-failover.script snippet --
        > 
        >      SECONDARY)
        >   ...
        >        ## Disable outbound-snat plugin in iptables
        >        if iptables -t nat -nL OUTBOUND_SNAT >/dev/null 2>&1; then
        >          iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
        >        fi
        >        ;;
        > 
        >      PRIMARY)
        >   ...
        >        ## Re-Enable outbound-snat plugin
        >        if iptables -t nat -nL OUTBOUND_SNAT >/dev/null 2>&1; then
        >          iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
        >        fi
        >        ;;
        >   --
        > 
        >   I'm having second thoughts about editing the ENABLED variable ... what if the box was rebooted while on failover, with ENABLED set to 0 on SECONDARY you would have effectively disabled the outbound-snat plugin after reboot.
        > 
        >   But, the above snippet should work whether the outbound-snat plugin is enabled or not.
        > 
        >   But still not perfect.
        > 
        >> PS. Would this be worth doing as part of the standard failover as I cant think of any instance where we would not want to disable SNAT when it fails over to another WAN interface.
        > 
        >   Yes, but I doubt the outbound-snat plugin is enabled very commonly, implying multiple IPv4 WAN addresses.  My first though is to do as above in the wan-failover.script.
        > 
        >   Lonnie
        > 
        > 
        >> On Mar 19, 2021, at 4:05 PM, Michael Knill <mic...@ip...> wrote:
        >> 
        >> Thanks Lonnie
        >> 
        >> Sorry for the late reply. Yes I'm using the outbound-snat plugin.
        >> So just to confirm:
        >> SECONDARY)
        >> ....
        >>    ## Disable outbound-snat plugin in both iptables and config file in case of reboot
        >>    iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
        >>    sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
        >>    ;;
        >> 
        >>  PRIMARY)
        >> ...
        >>    ## Re-Enable outbound-snat plugin and config file
        >>    iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
        >>    sed -i 's/^ENABLED=.*$/ENABLED=1/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
        >>    ;;
        >> 
        >> I'm thinking that I might look at OUTBOUND_SNAT_NET_HOST to see if something is set to make the decision on whether I disable and re-enable so it can be a generic script.
        >> 
        >> PS. Would this be worth doing as part of the standard failover as I cant think of any instance where we would not want to disable SNAT when it fails over to another WAN interface.
        >> 
        >> Regards
        >> Michael Knill
        >> 
        >> On 18/3/21, 1:49 am, "Lonnie Abelbeck" <li...@lo...> wrote:
        >> 
        >>  Hi Michael,
        >> 
        >>  When you say you have SNAT configured, are you using the nat-loopback plugin or the outbound-snat plugin ?
        >> 
        >>  Either of those require obtaining the WAN IPv4 address to attach iptables "-j SNAT --to-source $ip" rules, and as written only look at the primary external address.  Even if the Failover interface was looked at, the firewall would have to be rebuilt for the failover context switch with the /mnt/kd/wan-failover.script .
        >> 
        >>  Question, does either of these plugins make sense for a failover situation ?
        >> 
        >>  Possibly you want to disable the outbound-snat plugin on failover and re-enable it on return to primary ?
        >> 
        >>  If you have the special case of the outbound-snat plugin enabled, you could (untested code):
        >> 
        >>  -- /mnt/kd/wan-failover.script snippet --
        >> 
        >>  SECONDARY)
        >>    ## Switched to Failover using secondary WAN link
        >> 
        >>    ## Disable outbound-snat plugin
        >>    iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
        >>    ;;
        >> 
        >>  PRIMARY)
        >>    ## Switched back to normal using primary WAN link
        >> 
        >>    ## Re-Enable outbound-snat plugin
        >>    iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
        >>    ;;
        >> 
        >>  --
        >>  but this is somewhat fragile, such that if the firewall was restarted during failover it would revert to the PRIMARY setting.  To be less fragile, you could also add:
        >>  --
        >>  sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf"
        >>  --
        >>  and ENABLED=1 on return to PRIMARY.
        >> 
        >> 
        >>  Lonnie
        >> 
        >> 
        >> 
        >>> On Mar 17, 2021, at 1:16 AM, Michael Knill <mic...@ip...> wrote:
        >>> 
        >>> Grr problem now found. I had SNAT configured which didn't work on the second WAN connection.
        >>> Any way I can fix this e.g. don't do SNAT on the failover WAN?
        >>> 
        >>> Regards
        >>> Michael Knill
        >>> 
        >>> From: Michael Knill <mic...@ip...>
        >>> Reply to: AstLinux List <ast...@li...>
        >>> Date: Wednesday, 17 March 2021 at 4:27 pm
        >>> To: AstLinux List <ast...@li...>
        >>> Subject: [Astlinux-users] Weird routing problem
        >>> 
        >>> Hi Group
        >>> 
        >>> I'm currently at a site that has a primary and failover WAN connection and a two LAN connections. The primary WAN connection has failed over to the secondary WAN connection however it is only working on one of the LAN interfaces and not the other. I can ping the interface address fine so its not an interface problem.
        >>> 
        >>> Does anyone have any idea why this would be happenning?
        >>> 
        >>> Regards
        >>> Michael Knill
        >>> _______________________________________________
        >>> Astlinux-users mailing list
        >>> Ast...@li...
        >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
        >>> 
        >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
        >> 
        >> 
        >> 
        >>  _______________________________________________
        >>  Astlinux-users mailing list
        >>  Ast...@li...
        >>  https://lists.sourceforge.net/lists/listinfo/astlinux-users
        >> 
        >>  Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
        >> 
        >> 
        >> _______________________________________________
        >> Astlinux-users mailing list
        >> Ast...@li...
        >> https://lists.sourceforge.net/lists/listinfo/astlinux-users
        >> 
        >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
        > 
        > 
        > 
        >   _______________________________________________
        >   Astlinux-users mailing list
        >   Ast...@li...
        >   https://lists.sourceforge.net/lists/listinfo/astlinux-users
        > 
        >   Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
        > 
        > 
        > _______________________________________________
        > Astlinux-users mailing list
        > Ast...@li...
        > https://lists.sourceforge.net/lists/listinfo/astlinux-users
        > 
        > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....



        _______________________________________________
        Astlinux-users mailing list
        Ast...@li...
        https://lists.sourceforge.net/lists/listinfo/astlinux-users

        Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....


    _______________________________________________
    Astlinux-users mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-users

    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Wireguard VPN disconnection

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

Thanks. Guess I will need to test it out.

Regards
Michael Knill

On 20/3/21, 2:03 pm, "Lonnie Abelbeck" <li...@lo...> wrote:

    While playing with the WG MTU, it seemed to work with only setting one end and the tunnel used the smallest, but I played it safe and set everything to 1340.

    It would be good to know what the precise answer is.

    Lonnie


    > On Mar 19, 2021, at 9:57 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > Thanks Lonnie.
    > 
    > PS I was just thinking (dangerous I know). I would need to set it on both ends so do you think there would there be any issues with different MTU's at each end?
    > Ultimately it would be the same eventually but there would be a migration period.
    > 
    > Regards
    > Michael Knill
    > 
    > On 20/3/21, 1:41 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
    > 
    >    I haven't seen any issues with a WG MTU of 1340, yet anyway.
    > 
    >    Lonnie
    > 
    > 
    >> On Mar 19, 2021, at 9:29 PM, Michael Knill <mic...@ip...> wrote:
    >> 
    >> Thanks Lonnie
    >> 
    >> Hmm that may have something to do with it. Might also be when it fails over to 4G.
    >> As most of my VPN's carry voice only, I think a standard MTU of 1340 for all my systems should be fine. What do you think?
    >> 
    >> Regards
    >> Michael Knill
    >> 
    >> On 20/3/21, 10:40 am, "Lonnie Abelbeck" <li...@lo...> wrote:
    >> 
    >>   Hi Michael,
    >> 
    >>   I have not experienced anything like that, WireGuard connectivity is rock solid for me.
    >> 
    >>   I don't recall later WireGuard versions having any fixes for what you are describing.
    >> 
    >>   Just guessing, the standard MTU for WG is 1420 (1500-80), if you have a PPPoE connection with a MTU of 1492 you might try setting the WG MTU to 1412 (1500-8-80) or lower to test.
    >> 
    >>   I'm testing a 4G-LTE/5G fixed wireless internet service from T-Mobile, they use Carrier Grade NAT (CGNAT) for IPv4 which lowers the MTU to 1420 (just like WG) so WG needs a MTU setting of 1340 to work over the CGNAT or else it hangs.
    >> 
    >>   Lonnie
    >> 
    >> 
    >> 
    >> 
    >>> On Mar 19, 2021, at 3:42 PM, Michael Knill <mic...@ip...> wrote:
    >>> 
    >>> Hi Group
    >>> 
    >>> Not sure if anyone else is experiencing this. I'm on 1.3.10 and all my systems connect via Wireguard VPN to both my softswitches.
    >>> Its generally all pretty stable but occasionally one of the VPN’s will be disconnected and I have tried everything I can think of to bring it back up but only a reboot has managed to do so at this stage.
    >>> Any ideas?
    >>> 
    >>> Regards
    >>> Michael Knill
    >>> _______________________________________________
    >>> Astlinux-users mailing list
    >>> Ast...@li...
    >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
    >>> 
    >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    >> 
    >> 
    >> 
    >>   _______________________________________________
    >>   Astlinux-users mailing list
    >>   Ast...@li...
    >>   https://lists.sourceforge.net/lists/listinfo/astlinux-users
    >> 
    >>   Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    >> 
    >> 
    >> _______________________________________________
    >> Astlinux-users mailing list
    >> Ast...@li...
    >> https://lists.sourceforge.net/lists/listinfo/astlinux-users
    >> 
    >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    > 
    > 
    > 
    >    _______________________________________________
    >    Astlinux-users mailing list
    >    Ast...@li...
    >    https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    >    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    > 
    > 
    > _______________________________________________
    > Astlinux-users mailing list
    > Ast...@li...
    > https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....



    _______________________________________________
    Astlinux-users mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-users

    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Wireguard VPN disconnection

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

While playing with the WG MTU, it seemed to work with only setting one end and the tunnel used the smallest, but I played it safe and set everything to 1340.

It would be good to know what the precise answer is.

Lonnie


> On Mar 19, 2021, at 9:57 PM, Michael Knill <mic...@ip...> wrote:
> 
> Thanks Lonnie.
> 
> PS I was just thinking (dangerous I know). I would need to set it on both ends so do you think there would there be any issues with different MTU's at each end?
> Ultimately it would be the same eventually but there would be a migration period.
> 
> Regards
> Michael Knill
> 
> On 20/3/21, 1:41 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
> 
>    I haven't seen any issues with a WG MTU of 1340, yet anyway.
> 
>    Lonnie
> 
> 
>> On Mar 19, 2021, at 9:29 PM, Michael Knill <mic...@ip...> wrote:
>> 
>> Thanks Lonnie
>> 
>> Hmm that may have something to do with it. Might also be when it fails over to 4G.
>> As most of my VPN's carry voice only, I think a standard MTU of 1340 for all my systems should be fine. What do you think?
>> 
>> Regards
>> Michael Knill
>> 
>> On 20/3/21, 10:40 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>> 
>>   Hi Michael,
>> 
>>   I have not experienced anything like that, WireGuard connectivity is rock solid for me.
>> 
>>   I don't recall later WireGuard versions having any fixes for what you are describing.
>> 
>>   Just guessing, the standard MTU for WG is 1420 (1500-80), if you have a PPPoE connection with a MTU of 1492 you might try setting the WG MTU to 1412 (1500-8-80) or lower to test.
>> 
>>   I'm testing a 4G-LTE/5G fixed wireless internet service from T-Mobile, they use Carrier Grade NAT (CGNAT) for IPv4 which lowers the MTU to 1420 (just like WG) so WG needs a MTU setting of 1340 to work over the CGNAT or else it hangs.
>> 
>>   Lonnie
>> 
>> 
>> 
>> 
>>> On Mar 19, 2021, at 3:42 PM, Michael Knill <mic...@ip...> wrote:
>>> 
>>> Hi Group
>>> 
>>> Not sure if anyone else is experiencing this. I'm on 1.3.10 and all my systems connect via Wireguard VPN to both my softswitches.
>>> Its generally all pretty stable but occasionally one of the VPN’s will be disconnected and I have tried everything I can think of to bring it back up but only a reboot has managed to do so at this stage.
>>> Any ideas?
>>> 
>>> Regards
>>> Michael Knill
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>> 
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>> 
>> 
>> 
>>   _______________________________________________
>>   Astlinux-users mailing list
>>   Ast...@li...
>>   https://lists.sourceforge.net/lists/listinfo/astlinux-users
>> 
>>   Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>> 
>> 
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> 
>    _______________________________________________
>    Astlinux-users mailing list
>    Ast...@li...
>    https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
>    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Wireguard VPN disconnection

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

Thanks Lonnie.

PS I was just thinking (dangerous I know). I would need to set it on both ends so do you think there would there be any issues with different MTU's at each end?
Ultimately it would be the same eventually but there would be a migration period.

Regards
Michael Knill

On 20/3/21, 1:41 pm, "Lonnie Abelbeck" <li...@lo...> wrote:

    I haven't seen any issues with a WG MTU of 1340, yet anyway.

    Lonnie


    > On Mar 19, 2021, at 9:29 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > Thanks Lonnie
    > 
    > Hmm that may have something to do with it. Might also be when it fails over to 4G.
    > As most of my VPN's carry voice only, I think a standard MTU of 1340 for all my systems should be fine. What do you think?
    > 
    > Regards
    > Michael Knill
    > 
    > On 20/3/21, 10:40 am, "Lonnie Abelbeck" <li...@lo...> wrote:
    > 
    >    Hi Michael,
    > 
    >    I have not experienced anything like that, WireGuard connectivity is rock solid for me.
    > 
    >    I don't recall later WireGuard versions having any fixes for what you are describing.
    > 
    >    Just guessing, the standard MTU for WG is 1420 (1500-80), if you have a PPPoE connection with a MTU of 1492 you might try setting the WG MTU to 1412 (1500-8-80) or lower to test.
    > 
    >    I'm testing a 4G-LTE/5G fixed wireless internet service from T-Mobile, they use Carrier Grade NAT (CGNAT) for IPv4 which lowers the MTU to 1420 (just like WG) so WG needs a MTU setting of 1340 to work over the CGNAT or else it hangs.
    > 
    >    Lonnie
    > 
    > 
    > 
    > 
    >> On Mar 19, 2021, at 3:42 PM, Michael Knill <mic...@ip...> wrote:
    >> 
    >> Hi Group
    >> 
    >> Not sure if anyone else is experiencing this. I'm on 1.3.10 and all my systems connect via Wireguard VPN to both my softswitches.
    >> Its generally all pretty stable but occasionally one of the VPN’s will be disconnected and I have tried everything I can think of to bring it back up but only a reboot has managed to do so at this stage.
    >> Any ideas?
    >> 
    >> Regards
    >> Michael Knill
    >> _______________________________________________
    >> Astlinux-users mailing list
    >> Ast...@li...
    >> https://lists.sourceforge.net/lists/listinfo/astlinux-users
    >> 
    >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    > 
    > 
    > 
    >    _______________________________________________
    >    Astlinux-users mailing list
    >    Ast...@li...
    >    https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    >    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    > 
    > 
    > _______________________________________________
    > Astlinux-users mailing list
    > Ast...@li...
    > https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....



    _______________________________________________
    Astlinux-users mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-users

    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Wireguard VPN disconnection

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

I haven't seen any issues with a WG MTU of 1340, yet anyway.

Lonnie


> On Mar 19, 2021, at 9:29 PM, Michael Knill <mic...@ip...> wrote:
> 
> Thanks Lonnie
> 
> Hmm that may have something to do with it. Might also be when it fails over to 4G.
> As most of my VPN's carry voice only, I think a standard MTU of 1340 for all my systems should be fine. What do you think?
> 
> Regards
> Michael Knill
> 
> On 20/3/21, 10:40 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> 
>    Hi Michael,
> 
>    I have not experienced anything like that, WireGuard connectivity is rock solid for me.
> 
>    I don't recall later WireGuard versions having any fixes for what you are describing.
> 
>    Just guessing, the standard MTU for WG is 1420 (1500-80), if you have a PPPoE connection with a MTU of 1492 you might try setting the WG MTU to 1412 (1500-8-80) or lower to test.
> 
>    I'm testing a 4G-LTE/5G fixed wireless internet service from T-Mobile, they use Carrier Grade NAT (CGNAT) for IPv4 which lowers the MTU to 1420 (just like WG) so WG needs a MTU setting of 1340 to work over the CGNAT or else it hangs.
> 
>    Lonnie
> 
> 
> 
> 
>> On Mar 19, 2021, at 3:42 PM, Michael Knill <mic...@ip...> wrote:
>> 
>> Hi Group
>> 
>> Not sure if anyone else is experiencing this. I'm on 1.3.10 and all my systems connect via Wireguard VPN to both my softswitches.
>> Its generally all pretty stable but occasionally one of the VPN’s will be disconnected and I have tried everything I can think of to bring it back up but only a reboot has managed to do so at this stage.
>> Any ideas?
>> 
>> Regards
>> Michael Knill
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> 
>    _______________________________________________
>    Astlinux-users mailing list
>    Ast...@li...
>    https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
>    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Wireguard VPN disconnection

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

Thanks Lonnie

Hmm that may have something to do with it. Might also be when it fails over to 4G.
As most of my VPN's carry voice only, I think a standard MTU of 1340 for all my systems should be fine. What do you think?

Regards
Michael Knill

On 20/3/21, 10:40 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    Hi Michael,

    I have not experienced anything like that, WireGuard connectivity is rock solid for me.

    I don't recall later WireGuard versions having any fixes for what you are describing.

    Just guessing, the standard MTU for WG is 1420 (1500-80), if you have a PPPoE connection with a MTU of 1492 you might try setting the WG MTU to 1412 (1500-8-80) or lower to test.

    I'm testing a 4G-LTE/5G fixed wireless internet service from T-Mobile, they use Carrier Grade NAT (CGNAT) for IPv4 which lowers the MTU to 1420 (just like WG) so WG needs a MTU setting of 1340 to work over the CGNAT or else it hangs.

    Lonnie




    > On Mar 19, 2021, at 3:42 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > Hi Group
    >  
    > Not sure if anyone else is experiencing this. I'm on 1.3.10 and all my systems connect via Wireguard VPN to both my softswitches.
    > Its generally all pretty stable but occasionally one of the VPN’s will be disconnected and I have tried everything I can think of to bring it back up but only a reboot has managed to do so at this stage.
    > Any ideas?
    >  
    > Regards
    > Michael Knill
    > _______________________________________________
    > Astlinux-users mailing list
    > Ast...@li...
    > https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....



    _______________________________________________
    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] Wireguard VPN disconnection

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

Hi Michael,

I have not experienced anything like that, WireGuard connectivity is rock solid for me.

I don't recall later WireGuard versions having any fixes for what you are describing.

Just guessing, the standard MTU for WG is 1420 (1500-80), if you have a PPPoE connection with a MTU of 1492 you might try setting the WG MTU to 1412 (1500-8-80) or lower to test.

I'm testing a 4G-LTE/5G fixed wireless internet service from T-Mobile, they use Carrier Grade NAT (CGNAT) for IPv4 which lowers the MTU to 1420 (just like WG) so WG needs a MTU setting of 1340 to work over the CGNAT or else it hangs.

Lonnie




> On Mar 19, 2021, at 3:42 PM, Michael Knill <mic...@ip...> wrote:
> 
> Hi Group
>  
> Not sure if anyone else is experiencing this. I'm on 1.3.10 and all my systems connect via Wireguard VPN to both my softswitches.
> Its generally all pretty stable but occasionally one of the VPN’s will be disconnected and I have tried everything I can think of to bring it back up but only a reboot has managed to do so at this stage.
> Any ideas?
>  
> Regards
> Michael Knill
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Weird routing problem

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

Thanks. Will do.

Regards
Michael Knill

On 20/3/21, 9:29 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    > So just to confirm, there shouldn't be any issues in having this in my default wan-failover.script e.g. whether outbound-snat is configured or not?

    Correct, the OUTBOUND_SNAT nat chain should only exist when the outbound-snat plugin is enabled.

    But test anyway :-)

    Lonnie


    > On Mar 19, 2021, at 5:13 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > Thanks Lonnie
    > 
    > So just to confirm, there shouldn't be any issues in having this in my default wan-failover.script e.g. whether outbound-snat is configured or not?
    > 
    > Regards
    > Michael Knill
    > 
    > On 20/3/21, 9:08 am, "Lonnie Abelbeck" <li...@lo...> wrote:
    > 
    >   Hi Michael,
    > 
    >   Again off the top of my head (needs testing), this would be more general...
    >   -- /mnt/kd/wan-failover.script snippet --
    > 
    >      SECONDARY)
    >   ...
    >        ## Disable outbound-snat plugin in iptables
    >        if iptables -t nat -nL OUTBOUND_SNAT >/dev/null 2>&1; then
    >          iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
    >        fi
    >        ;;
    > 
    >      PRIMARY)
    >   ...
    >        ## Re-Enable outbound-snat plugin
    >        if iptables -t nat -nL OUTBOUND_SNAT >/dev/null 2>&1; then
    >          iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
    >        fi
    >        ;;
    >   --
    > 
    >   I'm having second thoughts about editing the ENABLED variable ... what if the box was rebooted while on failover, with ENABLED set to 0 on SECONDARY you would have effectively disabled the outbound-snat plugin after reboot.
    > 
    >   But, the above snippet should work whether the outbound-snat plugin is enabled or not.
    > 
    >   But still not perfect.
    > 
    >> PS. Would this be worth doing as part of the standard failover as I cant think of any instance where we would not want to disable SNAT when it fails over to another WAN interface.
    > 
    >   Yes, but I doubt the outbound-snat plugin is enabled very commonly, implying multiple IPv4 WAN addresses.  My first though is to do as above in the wan-failover.script.
    > 
    >   Lonnie
    > 
    > 
    >> On Mar 19, 2021, at 4:05 PM, Michael Knill <mic...@ip...> wrote:
    >> 
    >> Thanks Lonnie
    >> 
    >> Sorry for the late reply. Yes I'm using the outbound-snat plugin.
    >> So just to confirm:
    >> SECONDARY)
    >> ....
    >>    ## Disable outbound-snat plugin in both iptables and config file in case of reboot
    >>    iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
    >>    sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
    >>    ;;
    >> 
    >>  PRIMARY)
    >> ...
    >>    ## Re-Enable outbound-snat plugin and config file
    >>    iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
    >>    sed -i 's/^ENABLED=.*$/ENABLED=1/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
    >>    ;;
    >> 
    >> I'm thinking that I might look at OUTBOUND_SNAT_NET_HOST to see if something is set to make the decision on whether I disable and re-enable so it can be a generic script.
    >> 
    >> PS. Would this be worth doing as part of the standard failover as I cant think of any instance where we would not want to disable SNAT when it fails over to another WAN interface.
    >> 
    >> Regards
    >> Michael Knill
    >> 
    >> On 18/3/21, 1:49 am, "Lonnie Abelbeck" <li...@lo...> wrote:
    >> 
    >>  Hi Michael,
    >> 
    >>  When you say you have SNAT configured, are you using the nat-loopback plugin or the outbound-snat plugin ?
    >> 
    >>  Either of those require obtaining the WAN IPv4 address to attach iptables "-j SNAT --to-source $ip" rules, and as written only look at the primary external address.  Even if the Failover interface was looked at, the firewall would have to be rebuilt for the failover context switch with the /mnt/kd/wan-failover.script .
    >> 
    >>  Question, does either of these plugins make sense for a failover situation ?
    >> 
    >>  Possibly you want to disable the outbound-snat plugin on failover and re-enable it on return to primary ?
    >> 
    >>  If you have the special case of the outbound-snat plugin enabled, you could (untested code):
    >> 
    >>  -- /mnt/kd/wan-failover.script snippet --
    >> 
    >>  SECONDARY)
    >>    ## Switched to Failover using secondary WAN link
    >> 
    >>    ## Disable outbound-snat plugin
    >>    iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
    >>    ;;
    >> 
    >>  PRIMARY)
    >>    ## Switched back to normal using primary WAN link
    >> 
    >>    ## Re-Enable outbound-snat plugin
    >>    iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
    >>    ;;
    >> 
    >>  --
    >>  but this is somewhat fragile, such that if the firewall was restarted during failover it would revert to the PRIMARY setting.  To be less fragile, you could also add:
    >>  --
    >>  sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf"
    >>  --
    >>  and ENABLED=1 on return to PRIMARY.
    >> 
    >> 
    >>  Lonnie
    >> 
    >> 
    >> 
    >>> On Mar 17, 2021, at 1:16 AM, Michael Knill <mic...@ip...> wrote:
    >>> 
    >>> Grr problem now found. I had SNAT configured which didn't work on the second WAN connection.
    >>> Any way I can fix this e.g. don't do SNAT on the failover WAN?
    >>> 
    >>> Regards
    >>> Michael Knill
    >>> 
    >>> From: Michael Knill <mic...@ip...>
    >>> Reply to: AstLinux List <ast...@li...>
    >>> Date: Wednesday, 17 March 2021 at 4:27 pm
    >>> To: AstLinux List <ast...@li...>
    >>> Subject: [Astlinux-users] Weird routing problem
    >>> 
    >>> Hi Group
    >>> 
    >>> I'm currently at a site that has a primary and failover WAN connection and a two LAN connections. The primary WAN connection has failed over to the secondary WAN connection however it is only working on one of the LAN interfaces and not the other. I can ping the interface address fine so its not an interface problem.
    >>> 
    >>> Does anyone have any idea why this would be happenning?
    >>> 
    >>> Regards
    >>> Michael Knill
    >>> _______________________________________________
    >>> Astlinux-users mailing list
    >>> Ast...@li...
    >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
    >>> 
    >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    >> 
    >> 
    >> 
    >>  _______________________________________________
    >>  Astlinux-users mailing list
    >>  Ast...@li...
    >>  https://lists.sourceforge.net/lists/listinfo/astlinux-users
    >> 
    >>  Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    >> 
    >> 
    >> _______________________________________________
    >> Astlinux-users mailing list
    >> Ast...@li...
    >> https://lists.sourceforge.net/lists/listinfo/astlinux-users
    >> 
    >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    > 
    > 
    > 
    >   _______________________________________________
    >   Astlinux-users mailing list
    >   Ast...@li...
    >   https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    >   Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    > 
    > 
    > _______________________________________________
    > Astlinux-users mailing list
    > Ast...@li...
    > https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....



    _______________________________________________
    Astlinux-users mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-users

    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Weird routing problem

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

> So just to confirm, there shouldn't be any issues in having this in my default wan-failover.script e.g. whether outbound-snat is configured or not?

Correct, the OUTBOUND_SNAT nat chain should only exist when the outbound-snat plugin is enabled.

But test anyway :-)

Lonnie


> On Mar 19, 2021, at 5:13 PM, Michael Knill <mic...@ip...> wrote:
> 
> Thanks Lonnie
> 
> So just to confirm, there shouldn't be any issues in having this in my default wan-failover.script e.g. whether outbound-snat is configured or not?
> 
> Regards
> Michael Knill
> 
> On 20/3/21, 9:08 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> 
>   Hi Michael,
> 
>   Again off the top of my head (needs testing), this would be more general...
>   -- /mnt/kd/wan-failover.script snippet --
> 
>      SECONDARY)
>   ...
>        ## Disable outbound-snat plugin in iptables
>        if iptables -t nat -nL OUTBOUND_SNAT >/dev/null 2>&1; then
>          iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
>        fi
>        ;;
> 
>      PRIMARY)
>   ...
>        ## Re-Enable outbound-snat plugin
>        if iptables -t nat -nL OUTBOUND_SNAT >/dev/null 2>&1; then
>          iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
>        fi
>        ;;
>   --
> 
>   I'm having second thoughts about editing the ENABLED variable ... what if the box was rebooted while on failover, with ENABLED set to 0 on SECONDARY you would have effectively disabled the outbound-snat plugin after reboot.
> 
>   But, the above snippet should work whether the outbound-snat plugin is enabled or not.
> 
>   But still not perfect.
> 
>> PS. Would this be worth doing as part of the standard failover as I cant think of any instance where we would not want to disable SNAT when it fails over to another WAN interface.
> 
>   Yes, but I doubt the outbound-snat plugin is enabled very commonly, implying multiple IPv4 WAN addresses.  My first though is to do as above in the wan-failover.script.
> 
>   Lonnie
> 
> 
>> On Mar 19, 2021, at 4:05 PM, Michael Knill <mic...@ip...> wrote:
>> 
>> Thanks Lonnie
>> 
>> Sorry for the late reply. Yes I'm using the outbound-snat plugin.
>> So just to confirm:
>> SECONDARY)
>> ....
>>    ## Disable outbound-snat plugin in both iptables and config file in case of reboot
>>    iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
>>    sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
>>    ;;
>> 
>>  PRIMARY)
>> ...
>>    ## Re-Enable outbound-snat plugin and config file
>>    iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
>>    sed -i 's/^ENABLED=.*$/ENABLED=1/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
>>    ;;
>> 
>> I'm thinking that I might look at OUTBOUND_SNAT_NET_HOST to see if something is set to make the decision on whether I disable and re-enable so it can be a generic script.
>> 
>> PS. Would this be worth doing as part of the standard failover as I cant think of any instance where we would not want to disable SNAT when it fails over to another WAN interface.
>> 
>> Regards
>> Michael Knill
>> 
>> On 18/3/21, 1:49 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>> 
>>  Hi Michael,
>> 
>>  When you say you have SNAT configured, are you using the nat-loopback plugin or the outbound-snat plugin ?
>> 
>>  Either of those require obtaining the WAN IPv4 address to attach iptables "-j SNAT --to-source $ip" rules, and as written only look at the primary external address.  Even if the Failover interface was looked at, the firewall would have to be rebuilt for the failover context switch with the /mnt/kd/wan-failover.script .
>> 
>>  Question, does either of these plugins make sense for a failover situation ?
>> 
>>  Possibly you want to disable the outbound-snat plugin on failover and re-enable it on return to primary ?
>> 
>>  If you have the special case of the outbound-snat plugin enabled, you could (untested code):
>> 
>>  -- /mnt/kd/wan-failover.script snippet --
>> 
>>  SECONDARY)
>>    ## Switched to Failover using secondary WAN link
>> 
>>    ## Disable outbound-snat plugin
>>    iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
>>    ;;
>> 
>>  PRIMARY)
>>    ## Switched back to normal using primary WAN link
>> 
>>    ## Re-Enable outbound-snat plugin
>>    iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
>>    ;;
>> 
>>  --
>>  but this is somewhat fragile, such that if the firewall was restarted during failover it would revert to the PRIMARY setting.  To be less fragile, you could also add:
>>  --
>>  sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf"
>>  --
>>  and ENABLED=1 on return to PRIMARY.
>> 
>> 
>>  Lonnie
>> 
>> 
>> 
>>> On Mar 17, 2021, at 1:16 AM, Michael Knill <mic...@ip...> wrote:
>>> 
>>> Grr problem now found. I had SNAT configured which didn't work on the second WAN connection.
>>> Any way I can fix this e.g. don't do SNAT on the failover WAN?
>>> 
>>> Regards
>>> Michael Knill
>>> 
>>> From: Michael Knill <mic...@ip...>
>>> Reply to: AstLinux List <ast...@li...>
>>> Date: Wednesday, 17 March 2021 at 4:27 pm
>>> To: AstLinux List <ast...@li...>
>>> Subject: [Astlinux-users] Weird routing problem
>>> 
>>> Hi Group
>>> 
>>> I'm currently at a site that has a primary and failover WAN connection and a two LAN connections. The primary WAN connection has failed over to the secondary WAN connection however it is only working on one of the LAN interfaces and not the other. I can ping the interface address fine so its not an interface problem.
>>> 
>>> Does anyone have any idea why this would be happenning?
>>> 
>>> Regards
>>> Michael Knill
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>> 
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>> 
>> 
>> 
>>  _______________________________________________
>>  Astlinux-users mailing list
>>  Ast...@li...
>>  https://lists.sourceforge.net/lists/listinfo/astlinux-users
>> 
>>  Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>> 
>> 
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> 
>   _______________________________________________
>   Astlinux-users mailing list
>   Ast...@li...
>   https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
>   Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Weird routing problem

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

Thanks Lonnie

So just to confirm, there shouldn't be any issues in having this in my default wan-failover.script e.g. whether outbound-snat is configured or not?

Regards
Michael Knill

On 20/3/21, 9:08 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    Hi Michael,

    Again off the top of my head (needs testing), this would be more general...
    -- /mnt/kd/wan-failover.script snippet --

       SECONDARY)
    ...
         ## Disable outbound-snat plugin in iptables
         if iptables -t nat -nL OUTBOUND_SNAT >/dev/null 2>&1; then
           iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
         fi
         ;;

       PRIMARY)
    ...
         ## Re-Enable outbound-snat plugin
         if iptables -t nat -nL OUTBOUND_SNAT >/dev/null 2>&1; then
           iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
         fi
         ;;
    --

    I'm having second thoughts about editing the ENABLED variable ... what if the box was rebooted while on failover, with ENABLED set to 0 on SECONDARY you would have effectively disabled the outbound-snat plugin after reboot.

    But, the above snippet should work whether the outbound-snat plugin is enabled or not.

    But still not perfect.

    > PS. Would this be worth doing as part of the standard failover as I cant think of any instance where we would not want to disable SNAT when it fails over to another WAN interface.

    Yes, but I doubt the outbound-snat plugin is enabled very commonly, implying multiple IPv4 WAN addresses.  My first though is to do as above in the wan-failover.script.

    Lonnie


    > On Mar 19, 2021, at 4:05 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > Thanks Lonnie
    > 
    > Sorry for the late reply. Yes I'm using the outbound-snat plugin.
    > So just to confirm:
    > SECONDARY)
    > ....
    >      ## Disable outbound-snat plugin in both iptables and config file in case of reboot
    >      iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
    >      sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
    >      ;;
    > 
    >    PRIMARY)
    > ...
    >      ## Re-Enable outbound-snat plugin and config file
    >      iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
    >      sed -i 's/^ENABLED=.*$/ENABLED=1/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
    >      ;;
    > 
    > I'm thinking that I might look at OUTBOUND_SNAT_NET_HOST to see if something is set to make the decision on whether I disable and re-enable so it can be a generic script.
    > 
    > PS. Would this be worth doing as part of the standard failover as I cant think of any instance where we would not want to disable SNAT when it fails over to another WAN interface.
    > 
    > Regards
    > Michael Knill
    > 
    > On 18/3/21, 1:49 am, "Lonnie Abelbeck" <li...@lo...> wrote:
    > 
    >    Hi Michael,
    > 
    >    When you say you have SNAT configured, are you using the nat-loopback plugin or the outbound-snat plugin ?
    > 
    >    Either of those require obtaining the WAN IPv4 address to attach iptables "-j SNAT --to-source $ip" rules, and as written only look at the primary external address.  Even if the Failover interface was looked at, the firewall would have to be rebuilt for the failover context switch with the /mnt/kd/wan-failover.script .
    > 
    >    Question, does either of these plugins make sense for a failover situation ?
    > 
    >    Possibly you want to disable the outbound-snat plugin on failover and re-enable it on return to primary ?
    > 
    >    If you have the special case of the outbound-snat plugin enabled, you could (untested code):
    > 
    >    -- /mnt/kd/wan-failover.script snippet --
    > 
    >    SECONDARY)
    >      ## Switched to Failover using secondary WAN link
    > 
    >      ## Disable outbound-snat plugin
    >      iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
    >      ;;
    > 
    >    PRIMARY)
    >      ## Switched back to normal using primary WAN link
    > 
    >      ## Re-Enable outbound-snat plugin
    >      iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
    >      ;;
    > 
    >    --
    >    but this is somewhat fragile, such that if the firewall was restarted during failover it would revert to the PRIMARY setting.  To be less fragile, you could also add:
    >    --
    >    sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf"
    >    --
    >    and ENABLED=1 on return to PRIMARY.
    > 
    > 
    >    Lonnie
    > 
    > 
    > 
    >> On Mar 17, 2021, at 1:16 AM, Michael Knill <mic...@ip...> wrote:
    >> 
    >> Grr problem now found. I had SNAT configured which didn't work on the second WAN connection.
    >> Any way I can fix this e.g. don't do SNAT on the failover WAN?
    >> 
    >> Regards
    >> Michael Knill
    >> 
    >> From: Michael Knill <mic...@ip...>
    >> Reply to: AstLinux List <ast...@li...>
    >> Date: Wednesday, 17 March 2021 at 4:27 pm
    >> To: AstLinux List <ast...@li...>
    >> Subject: [Astlinux-users] Weird routing problem
    >> 
    >> Hi Group
    >> 
    >> I'm currently at a site that has a primary and failover WAN connection and a two LAN connections. The primary WAN connection has failed over to the secondary WAN connection however it is only working on one of the LAN interfaces and not the other. I can ping the interface address fine so its not an interface problem.
    >> 
    >> Does anyone have any idea why this would be happenning?
    >> 
    >> Regards
    >> Michael Knill
    >> _______________________________________________
    >> Astlinux-users mailing list
    >> Ast...@li...
    >> https://lists.sourceforge.net/lists/listinfo/astlinux-users
    >> 
    >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    > 
    > 
    > 
    >    _______________________________________________
    >    Astlinux-users mailing list
    >    Ast...@li...
    >    https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    >    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    > 
    > 
    > _______________________________________________
    > Astlinux-users mailing list
    > Ast...@li...
    > https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....



    _______________________________________________
    Astlinux-users mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-users

    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Weird routing problem

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

Hi Michael,

Again off the top of my head (needs testing), this would be more general...
-- /mnt/kd/wan-failover.script snippet --

   SECONDARY)
...
     ## Disable outbound-snat plugin in iptables
     if iptables -t nat -nL OUTBOUND_SNAT >/dev/null 2>&1; then
       iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
     fi
     ;;

   PRIMARY)
...
     ## Re-Enable outbound-snat plugin
     if iptables -t nat -nL OUTBOUND_SNAT >/dev/null 2>&1; then
       iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
     fi
     ;;
--

I'm having second thoughts about editing the ENABLED variable ... what if the box was rebooted while on failover, with ENABLED set to 0 on SECONDARY you would have effectively disabled the outbound-snat plugin after reboot.

But, the above snippet should work whether the outbound-snat plugin is enabled or not.

But still not perfect.

> PS. Would this be worth doing as part of the standard failover as I cant think of any instance where we would not want to disable SNAT when it fails over to another WAN interface.

Yes, but I doubt the outbound-snat plugin is enabled very commonly, implying multiple IPv4 WAN addresses.  My first though is to do as above in the wan-failover.script.

Lonnie


> On Mar 19, 2021, at 4:05 PM, Michael Knill <mic...@ip...> wrote:
> 
> Thanks Lonnie
> 
> Sorry for the late reply. Yes I'm using the outbound-snat plugin.
> So just to confirm:
> SECONDARY)
> ....
>      ## Disable outbound-snat plugin in both iptables and config file in case of reboot
>      iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
>      sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
>      ;;
> 
>    PRIMARY)
> ...
>      ## Re-Enable outbound-snat plugin and config file
>      iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
>      sed -i 's/^ENABLED=.*$/ENABLED=1/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
>      ;;
> 
> I'm thinking that I might look at OUTBOUND_SNAT_NET_HOST to see if something is set to make the decision on whether I disable and re-enable so it can be a generic script.
> 
> PS. Would this be worth doing as part of the standard failover as I cant think of any instance where we would not want to disable SNAT when it fails over to another WAN interface.
> 
> Regards
> Michael Knill
> 
> On 18/3/21, 1:49 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> 
>    Hi Michael,
> 
>    When you say you have SNAT configured, are you using the nat-loopback plugin or the outbound-snat plugin ?
> 
>    Either of those require obtaining the WAN IPv4 address to attach iptables "-j SNAT --to-source $ip" rules, and as written only look at the primary external address.  Even if the Failover interface was looked at, the firewall would have to be rebuilt for the failover context switch with the /mnt/kd/wan-failover.script .
> 
>    Question, does either of these plugins make sense for a failover situation ?
> 
>    Possibly you want to disable the outbound-snat plugin on failover and re-enable it on return to primary ?
> 
>    If you have the special case of the outbound-snat plugin enabled, you could (untested code):
> 
>    -- /mnt/kd/wan-failover.script snippet --
> 
>    SECONDARY)
>      ## Switched to Failover using secondary WAN link
> 
>      ## Disable outbound-snat plugin
>      iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
>      ;;
> 
>    PRIMARY)
>      ## Switched back to normal using primary WAN link
> 
>      ## Re-Enable outbound-snat plugin
>      iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
>      ;;
> 
>    --
>    but this is somewhat fragile, such that if the firewall was restarted during failover it would revert to the PRIMARY setting.  To be less fragile, you could also add:
>    --
>    sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf"
>    --
>    and ENABLED=1 on return to PRIMARY.
> 
> 
>    Lonnie
> 
> 
> 
>> On Mar 17, 2021, at 1:16 AM, Michael Knill <mic...@ip...> wrote:
>> 
>> Grr problem now found. I had SNAT configured which didn't work on the second WAN connection.
>> Any way I can fix this e.g. don't do SNAT on the failover WAN?
>> 
>> Regards
>> Michael Knill
>> 
>> From: Michael Knill <mic...@ip...>
>> Reply to: AstLinux List <ast...@li...>
>> Date: Wednesday, 17 March 2021 at 4:27 pm
>> To: AstLinux List <ast...@li...>
>> Subject: [Astlinux-users] Weird routing problem
>> 
>> Hi Group
>> 
>> I'm currently at a site that has a primary and failover WAN connection and a two LAN connections. The primary WAN connection has failed over to the secondary WAN connection however it is only working on one of the LAN interfaces and not the other. I can ping the interface address fine so its not an interface problem.
>> 
>> Does anyone have any idea why this would be happenning?
>> 
>> Regards
>> Michael Knill
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> 
>    _______________________________________________
>    Astlinux-users mailing list
>    Ast...@li...
>    https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
>    Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Weird routing problem

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

Thanks Lonnie

Sorry for the late reply. Yes I'm using the outbound-snat plugin.
So just to confirm:
SECONDARY)
....
      ## Disable outbound-snat plugin in both iptables and config file in case of reboot
      iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
      sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
      ;;

    PRIMARY)
...
      ## Re-Enable outbound-snat plugin and config file
      iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
      sed -i 's/^ENABLED=.*$/ENABLED=1/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
      ;;

I'm thinking that I might look at OUTBOUND_SNAT_NET_HOST to see if something is set to make the decision on whether I disable and re-enable so it can be a generic script.

PS. Would this be worth doing as part of the standard failover as I cant think of any instance where we would not want to disable SNAT when it fails over to another WAN interface.

Regards
Michael Knill

On 18/3/21, 1:49 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    Hi Michael,

    When you say you have SNAT configured, are you using the nat-loopback plugin or the outbound-snat plugin ?

    Either of those require obtaining the WAN IPv4 address to attach iptables "-j SNAT --to-source $ip" rules, and as written only look at the primary external address.  Even if the Failover interface was looked at, the firewall would have to be rebuilt for the failover context switch with the /mnt/kd/wan-failover.script .

    Question, does either of these plugins make sense for a failover situation ?

    Possibly you want to disable the outbound-snat plugin on failover and re-enable it on return to primary ?

    If you have the special case of the outbound-snat plugin enabled, you could (untested code):

    -- /mnt/kd/wan-failover.script snippet --

    SECONDARY)
      ## Switched to Failover using secondary WAN link

      ## Disable outbound-snat plugin
      iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
      ;;

    PRIMARY)
      ## Switched back to normal using primary WAN link

      ## Re-Enable outbound-snat plugin
      iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
      ;;

    --
    but this is somewhat fragile, such that if the firewall was restarted during failover it would revert to the PRIMARY setting.  To be less fragile, you could also add:
    --
    sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf"
    --
    and ENABLED=1 on return to PRIMARY.


    Lonnie



    > On Mar 17, 2021, at 1:16 AM, Michael Knill <mic...@ip...> wrote:
    > 
    > Grr problem now found. I had SNAT configured which didn't work on the second WAN connection.
    > Any way I can fix this e.g. don't do SNAT on the failover WAN?
    >  
    > Regards
    > Michael Knill
    >  
    > From: Michael Knill <mic...@ip...>
    > Reply to: AstLinux List <ast...@li...>
    > Date: Wednesday, 17 March 2021 at 4:27 pm
    > To: AstLinux List <ast...@li...>
    > Subject: [Astlinux-users] Weird routing problem
    >  
    > Hi Group
    >  
    > I'm currently at a site that has a primary and failover WAN connection and a two LAN connections. The primary WAN connection has failed over to the secondary WAN connection however it is only working on one of the LAN interfaces and not the other. I can ping the interface address fine so its not an interface problem.
    >  
    > Does anyone have any idea why this would be happenning?
    >  
    > Regards
    > Michael Knill
    > _______________________________________________
    > Astlinux-users mailing list
    > Ast...@li...
    > https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....



    _______________________________________________
    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] Wireguard VPN disconnection

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

Hi Group

Not sure if anyone else is experiencing this. I'm on 1.3.10 and all my systems connect via Wireguard VPN to both my softswitches.
Its generally all pretty stable but occasionally one of the VPN’s will be disconnected and I have tried everything I can think of to bring it back up but only a reboot has managed to do so at this stage.
Any ideas?

Regards
Michael Knill

Re: [Astlinux-users] Weird routing problem

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

Typo (remove trailing double-quote):
--
sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf
--

Lonnie


> On Mar 17, 2021, at 9:48 AM, Lonnie Abelbeck <li...@lo...> wrote:
> 
> Hi Michael,
> 
> When you say you have SNAT configured, are you using the nat-loopback plugin or the outbound-snat plugin ?
> 
> Either of those require obtaining the WAN IPv4 address to attach iptables "-j SNAT --to-source $ip" rules, and as written only look at the primary external address.  Even if the Failover interface was looked at, the firewall would have to be rebuilt for the failover context switch with the /mnt/kd/wan-failover.script .
> 
> Question, does either of these plugins make sense for a failover situation ?
> 
> Possibly you want to disable the outbound-snat plugin on failover and re-enable it on return to primary ?
> 
> If you have the special case of the outbound-snat plugin enabled, you could (untested code):
> 
> -- /mnt/kd/wan-failover.script snippet --
> 
> SECONDARY)
>  ## Switched to Failover using secondary WAN link
> 
>  ## Disable outbound-snat plugin
>  iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
>  ;;
> 
> PRIMARY)
>  ## Switched back to normal using primary WAN link
> 
>  ## Re-Enable outbound-snat plugin
>  iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
>  ;;
> 
> --
> but this is somewhat fragile, such that if the firewall was restarted during failover it would revert to the PRIMARY setting.  To be less fragile, you could also add:
> --
> sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf"
> --
> and ENABLED=1 on return to PRIMARY.
> 
> 
> Lonnie
> 
> 
> 
>> On Mar 17, 2021, at 1:16 AM, Michael Knill <mic...@ip...> wrote:
>> 
>> Grr problem now found. I had SNAT configured which didn't work on the second WAN connection.
>> Any way I can fix this e.g. don't do SNAT on the failover WAN?
>> 
>> Regards
>> Michael Knill
>> 
>> From: Michael Knill <mic...@ip...>
>> Reply to: AstLinux List <ast...@li...>
>> Date: Wednesday, 17 March 2021 at 4:27 pm
>> To: AstLinux List <ast...@li...>
>> Subject: [Astlinux-users] Weird routing problem
>> 
>> Hi Group
>> 
>> I'm currently at a site that has a primary and failover WAN connection and a two LAN connections. The primary WAN connection has failed over to the secondary WAN connection however it is only working on one of the LAN interfaces and not the other. I can ping the interface address fine so its not an interface problem.
>> 
>> Does anyone have any idea why this would be happenning?
>> 
>> Regards
>> Michael Knill
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> 
> _______________________________________________
> 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] Weird routing problem

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

Hi Michael,

When you say you have SNAT configured, are you using the nat-loopback plugin or the outbound-snat plugin ?

Either of those require obtaining the WAN IPv4 address to attach iptables "-j SNAT --to-source $ip" rules, and as written only look at the primary external address.  Even if the Failover interface was looked at, the firewall would have to be rebuilt for the failover context switch with the /mnt/kd/wan-failover.script .

Question, does either of these plugins make sense for a failover situation ?

Possibly you want to disable the outbound-snat plugin on failover and re-enable it on return to primary ?

If you have the special case of the outbound-snat plugin enabled, you could (untested code):

-- /mnt/kd/wan-failover.script snippet --

SECONDARY)
  ## Switched to Failover using secondary WAN link

  ## Disable outbound-snat plugin
  iptables -t nat -D POSTROUTING -j OUTBOUND_SNAT
  ;;

PRIMARY)
  ## Switched back to normal using primary WAN link

  ## Re-Enable outbound-snat plugin
  iptables -t nat -I POSTROUTING -j OUTBOUND_SNAT
  ;;

--
but this is somewhat fragile, such that if the firewall was restarted during failover it would revert to the PRIMARY setting.  To be less fragile, you could also add:
--
sed -i 's/^ENABLED=.*$/ENABLED=0/' /etc/arno-iptables-firewall/plugins/outbound-snat.conf"
--
and ENABLED=1 on return to PRIMARY.


Lonnie



> On Mar 17, 2021, at 1:16 AM, Michael Knill <mic...@ip...> wrote:
> 
> Grr problem now found. I had SNAT configured which didn't work on the second WAN connection.
> Any way I can fix this e.g. don't do SNAT on the failover WAN?
>  
> Regards
> Michael Knill
>  
> From: Michael Knill <mic...@ip...>
> Reply to: AstLinux List <ast...@li...>
> Date: Wednesday, 17 March 2021 at 4:27 pm
> To: AstLinux List <ast...@li...>
> Subject: [Astlinux-users] Weird routing problem
>  
> Hi Group
>  
> I'm currently at a site that has a primary and failover WAN connection and a two LAN connections. The primary WAN connection has failed over to the secondary WAN connection however it is only working on one of the LAN interfaces and not the other. I can ping the interface address fine so its not an interface problem.
>  
> Does anyone have any idea why this would be happenning?
>  
> Regards
> Michael Knill
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Weird routing problem

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

Grr problem now found. I had SNAT configured which didn't work on the second WAN connection.
Any way I can fix this e.g. don't do SNAT on the failover WAN?

Regards
Michael Knill

From: Michael Knill <mic...@ip...>
Reply to: AstLinux List <ast...@li...>
Date: Wednesday, 17 March 2021 at 4:27 pm
To: AstLinux List <ast...@li...>
Subject: [Astlinux-users] Weird routing problem

Hi Group

I'm currently at a site that has a primary and failover WAN connection and a two LAN connections. The primary WAN connection has failed over to the secondary WAN connection however it is only working on one of the LAN interfaces and not the other. I can ping the interface address fine so its not an interface problem.

Does anyone have any idea why this would be happenning?

Regards
Michael Knill

[Astlinux-users] Weird routing problem

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

Hi Group

I'm currently at a site that has a primary and failover WAN connection and a two LAN connections. The primary WAN connection has failed over to the secondary WAN connection however it is only working on one of the LAN interfaces and not the other. I can ping the interface address fine so its not an interface problem.

Does anyone have any idea why this would be happenning?

Regards
Michael Knill

[Astlinux-users] Announcing AstLinux Release: 1.4.2

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

Announcing AstLinux Release: 1.4.2

More Info: AstLinux Project
https://www.astlinux-project.org/

AstLinux 1.4.2 Highlights:
* Asterisk Versions: 13.29.2, 13.38.2, 16.16.2
* Linux Kernel 4.19.177, security and bug fixes
* ipsec-tools (racoon) package has been removed.
* OpenSSL, version bump to 1.1.1j, security fixes
* OpenVPN, version bump to 2.4.10
* WireGuard VPN, module 1.0.20210219 (version bump), tools 1.0.20210223 (version bump)
* dnsmasq, version 2.84, patch: upstream DNS retries regression fix
* unbound, version bump to 1.13.1
* sudo, version bump to 1.8.32, security fixes
* zabbix, version bump to 4.0.29
* vnStat, new package, version 2.6, interface counter history is saved to /mnt/kd/vnstat/vnstat.db every hour.
	Enabled by default to keep a log of network traffic for external interface(s). No sniffing of traffic is performed.
	New rc.conf variable VNSTAT_ENABLE can be set to "no" to disable.
* Web Interface, added vnStat tab, available to "admin/staff" users. Hidden by default in Prefs tab.
* All Asterisk versions now have sRTP replay protection, new rtp.conf config option: srtpreplayprotection=yes
	This new rtp.conf option is enabled by default.
	Buggy SIP user agents may require srtpreplayprotection=no if audio issues occur with sRTP streams.
* Package upgrades providing important security and bug fixes

Full ChangeLog:
https://raw.githubusercontent.com/astlinux-project/astlinux/1.4.2/docs/ChangeLog.txt

All users are encouraged to upgrade, read the ChangeLog for the details.

AstLinux Team

[Astlinux-users] AstLinux Pre-Release: astlinux-1.4-5073-ea8b0c (Release Candidate1 pre-1.4.2)

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

Release Candidate1 pre-1.4.2, please report any issues, ASAP.

Due to many security fixes, Asterisk (pjsip), sRTP replay protection, et al., we plan on releasing AstLinux 1.4.2 sooner than the typical 3-4 month release cycle.


** IMPORTANT NOTICE

-- The ipsec-tools (racoon) support in AstLinux has been removed. The development of ipsec-tools has been ABANDONED.
	The Network tab -> VPN Type: "IPsec Peers" and "IPsec Mobile" in the web interface has been removed.
	The AstLinux Team suggests using either WireGuard or OpenVPN for your VPN needs, but if IPsec is required for
	compatibility reasons the Network tab -> VPN Type: "IPsec strongSwan" should be able to do what you want,
	albeit in a less than ideal text based configuration.
	More info: https://doc.astlinux-project.org/userdoc:tt_ipsec_vpn_strongswan

** The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.

-- Linux Kernel 4.19.177 (version bump), security and bug fixes

-- ipsec-tools (racoon) package has been removed.
	More info: https://doc.astlinux-project.org/userdoc:tt_ipsec_vpn_strongswan

-- OpenSSL, version bump to 1.1.1j, security fixes

-- OpenVPN, version bump to 2.4.10

-- WireGuard VPN, module 1.0.20210219 (version bump), tools 1.0.20210223 (version bump)

-- unbound, version bump to 1.13.1

-- zabbix, version bump to 4.0.29

-- vnStat, new package, version 2.6, interface counter history is saved to /mnt/kd/vnstat/vnstat.db every hour.
	Enabled by default to keep a log of network traffic for external interface(s). No sniffing of traffic is performed.
	New rc.conf variable VNSTAT_ENABLE can be set to "no" to disable.

-- Web Interface, added vnStat tab, available to "admin/staff" users.  Hidden by default in Prefs tab.

-- Asterisk 13.29.2 ('13se' no change)
	Older than latest Asterisk 13.x version but more tested, built --without-pjproject

-- Asterisk 13.38.2 (version bump) and 16.16.2 (version bump)

-- Note: All Asterisk versions now have sRTP replay protection, new rtp.conf config option: srtpreplayprotection=yes
  This new rtp.conf option is enabled by default.
  Buggy SIP user agents may require srtpreplayprotection=no if audio issues occur with sRTP streams.

-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt

The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...

AstLinux Project -> Development
https://www.astlinux-project.org/dev.html


AstLinux Team

[Astlinux-users] AstLinux Pre-Release: astlinux-1.4-5067-7a9a8c

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

Announcing AstLinux Pre-Release: astlinux-1.4-5067-7a9a8c

Due to many security fixes, Asterisk (pjsip), sRTP replay protection, et al., we plan on releasing AstLinux 1.4.2 sooner than the typical 3-4 month release cycle.

Please test this pre-release, to be followed by a release-candidate and AstLinux 1.4.2 in the next couple weeks.


** IMPORTANT NOTICE

-- The ipsec-tools (racoon) support in AstLinux has been removed. The development of ipsec-tools has been ABANDONED.
	The Network tab -> VPN Type: "IPsec Peers" and "IPsec Mobile" in the web interface has been removed.
	The AstLinux Team suggests using either WireGuard or OpenVPN for your VPN needs, but if IPsec is required for
	compatibility reasons the Network tab -> VPN Type: "IPsec strongSwan" should be able to do what you want,
	albeit in a less than ideal text based configuration.
	More info: https://doc.astlinux-project.org/userdoc:tt_ipsec_vpn_strongswan

** The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.

-- Linux Kernel 4.19.177 (version bump), security and bug fixes

-- ipsec-tools (racoon) package has been removed.
	More info: https://doc.astlinux-project.org/userdoc:tt_ipsec_vpn_strongswan

-- OpenSSL, version bump to 1.1.1j, security fixes

-- OpenVPN, version bump to 2.4.10

-- WireGuard VPN, module 1.0.20210219 (version bump), tools 1.0.20210223 (version bump)

-- unbound, version bump to 1.13.1

-- zabbix, version bump to 4.0.29

-- vnStat, new package, version 2.6, interface counter history is saved to /mnt/kd/vnstat/vnstat.db every hour.
	Enabled by default to keep a log of network traffic for external interface(s). No sniffing of traffic is performed.
	New rc.conf variable VNSTAT_ENABLE can be set to "no" to disable.

-- Web Interface, added vnStat tab, available to "admin/staff" users.  Hidden by default in Prefs tab.

-- Asterisk 13.29.2 ('13se' no change)
	Older than latest Asterisk 13.x version but more tested, built --without-pjproject

-- Asterisk 13.38.2 (version bump) and 16.16.1 (version bump)

-- Note: All Asterisk versions now have sRTP replay protection, new rtp.conf config option: srtpreplayprotection=yes
   This new rtp.conf option is enabled by default.
   Buggy SIP user agents may require srtpreplayprotection=no if audio issues occur with sRTP streams.

-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt

The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...

AstLinux Project -> Development
https://www.astlinux-project.org/dev.html


AstLinux Team

Re: [Astlinux-users] astlinux behind a firewall

[Jerry G. <jer...@gm...>]

Thanks for the advice Lonnie. Why do we want to keep it behind the
firewall? I ask from curiosity, not from spite. I plan on vlaning the
phones. Thank you for the starting point.

--
Kind Regards,
Jerry Gartner


On Fri, Feb 19, 2021 at 7:50 PM Lonnie Abelbeck <li...@lo...>
wrote:

> On Feb 19, 2021, at 3:27 PM, Jerry Gartner <jer...@gm...> wrote:
> >
> > I need to put an astlinux system that is currently acting as the network
> WAN firewall and gateway behind a new device that will be acting as the WAN
> firewall and gateway. What all is involved in doing this? After I disable
> the firewall and change the internal IP of the box, I'll need to
> re-provision the phones to point them to the new IP for the phone system.
> That seems like an oversimplification on my part, so please tell me what I
> am missing.
>
> Hi Jerry,
>
> I would not disable the firewall in your AstLinux system, but tweak it
> with its new private WAN address.
>
> I would consider placing all your phones in a LAN behind AstLinux (as you
> have now), possibly use a VLAN if your switches support them.
>
> Your asterisk will now be NAT'ed by the new edge firewall, that will
> require some minor asterisk configuration changes.
>
> Draw a network diagram of all the subnets, VLANs, edge IPs to help.
>
> Plan on it taking a few attempts to get things working again.
>
> Lonnie
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

Re: [Astlinux-users] astlinux behind a firewall

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

On Feb 19, 2021, at 3:27 PM, Jerry Gartner <jer...@gm...> wrote:
> 
> I need to put an astlinux system that is currently acting as the network WAN firewall and gateway behind a new device that will be acting as the WAN firewall and gateway. What all is involved in doing this? After I disable the firewall and change the internal IP of the box, I'll need to re-provision the phones to point them to the new IP for the phone system. That seems like an oversimplification on my part, so please tell me what I am missing.

Hi Jerry,

I would not disable the firewall in your AstLinux system, but tweak it with its new private WAN address.

I would consider placing all your phones in a LAN behind AstLinux (as you have now), possibly use a VLAN if your switches support them.

Your asterisk will now be NAT'ed by the new edge firewall, that will require some minor asterisk configuration changes.

Draw a network diagram of all the subnets, VLANs, edge IPs to help.

Plan on it taking a few attempts to get things working again.

Lonnie

[Astlinux-users] astlinux behind a firewall

[Jerry G. <jer...@gm...>]

I need to put an astlinux system that is currently acting as the network
WAN firewall and gateway behind a new device that will be acting as the WAN
firewall and gateway. What all is involved in doing this? After I disable
the firewall and change the internal IP of the box, I'll need to
re-provision the phones to point them to the new IP for the phone system.
That seems like an oversimplification on my part, so please tell me what I
am missing.

--
Kind Regards,
Jerry Gartner