On 10/09/2018 02:10 AM, Vieri Di Paola via Shorewall-users wrote:
>  
>
> On Monday, October 8, 2018, 7:30:45 PM GMT+2, Tom Eastep 
> <teas...@shorewall.net> wrote: 
>>     default via 192.168.144.1 dev ppp3 metric 4009
>>
>>   'reenable' does not delete that route, but 'restart' and 'reload' do
>>   delete the route.
>>
>>   This issue will be corrected by omitting 'defaultroute' from your
>>   ppp configuration.
> I removed that option. Now my ppp options are as follows:
>
> noauth
> persist
> holdoff 0
> maxfail 0
> noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp
>
> Restarting both the ppp links and shorewall works as expected (this 
> contradicts one of my previous findings that I required the default route, 
> but at this point it's better to just look forward).
>
> So let's move on to the test. Just to make things a tad more exciting, I 
> found out that my pppoe links do not re-sync at all after rebooting my 
> modems, ie., nothing in syslog indicates that pppd has tried to reconnect to 
> my providers. I don't know if it's due to the "UNKNOWN state" of all my ppp 
> links, or if I'm not setting up my ppp options appropriately. In any case, I 
> am required to manually restart my ppp script each time I reboot a modem... 
> So here's the script I ran today:
>
> ping -c 5 -n -I ppp3 8.8.8.8
> shorewall show routing > routing0
> echo "Reboot modem (ISP3), and wait until it's back up again (check ppp 
> ip-up.d script), then press ENTER"
> read
> shorewall show routing > routing1
> shorewall disable ppp3
> shorewall show routing > routing2
> shorewall enable ppp3
> shorewall show routing > routing3
> ping -c 5 -n -I ppp3 8.8.8.8
> echo "Press ENTER if ping fails"
> read
> shorewall reload
> ping -c 5 -n -I ppp3 8.8.8.8
> shorewall show routing > routing4
> echo "Press ENTER if ping fails again"
> read
> /etc/init.d/net.ppp3 restart
> echo "Check ppp ip-up.d script and press ENTER"
> read
> shorewall show routing > routing1b
> shorewall disable ppp3
> shorewall show routing > routing2b
> shorewall enable ppp3
> shorewall show routing > routing3b
> ping -c 5 -n -I ppp3 8.8.8.8
> echo "Press ENTER if ping fails"
> read
> shorewall reload
> ping -c 5 -n -I ppp3 8.8.8.8
> shorewall show routing > routing4b
>
>
> The ping test above starts working ONLY after the last shorewall reload -- so 
> routing4b is the working config (routing0 too, of course).
>
> In the link below you will find the routing* files and a custom ppp ip-up.d 
> script (99-custom.sh) with the related output in ppp_up_data which was 
> obtained only after restarting the net.ppp3 init script.
>
> https://drive.google.com/open?id=1Ly445Qzx9RXICMeC5UdQ9YK5Hcgywtf2
>
> The only difference between the dump after reenabling ppp3 (routing3b) and 
> reloading shorewall (routing4b) is:
>
> -default dev ppp3
> +default nexthop dev ppp1 weight 1 nexthop dev ppp2 weight 1 nexthop dev ppp3 
> weight 1
>
> Just one last test... I decided to restart the ppp3 init script without 
> rebooting the modem or restarting shorewall.
>
> # ping -n -I ppp3 8.8.8.8
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=121 time=14.0 ms
> ping: sendmsg: Network is unreachable
> ping: sendmsg: Network is unreachable
> ping: sendmsg: Network is unreachable
> ^C
>
> Please find the routing data here:
>
> https://drive.google.com/open?id=1K8DB5Xs05MuMG1botQ3htLlsh3MrPB4F
>
> In this case  "shorewall reenable ppp3" DOES restore proper traffic through 
> ppp3.
> Please note that when I reboot the modem the local public ppp-assigned IP 
> address may have changed. It was the case in my routing{1-4}{,b} test above, 
> but not in this one.
>
> Still don't quite get why I'm getting the "Network is unreachable" message 
> before reenabling in the last test.
Okay -- lets go through the routing* files one by one:

a) routing0 and routing1 are identical.

b) Disabling ppp3 results in it being removed from the balanced route
and in the removal of the fwmark rule for that provider which is correct.

--- routing1    2018-10-09 01:04:53.000000000 -0700
+++ routing2    2018-10-09 01:04:53.000000000 -0700
@@ -7,7 +7,6 @@
 999:    from all lookup main 
 10000:    from all fwmark 0x1/0xff lookup ISP1 
 10001:    from all fwmark 0x2/0xff lookup ISP2 
-10002:    from all fwmark 0x3/0xff lookup ISP3 
 20000:    from 83.61.3.216 lookup ISP1 
 20000:    from 79.148.120.225 lookup ISP2 
 20000:    from 83.50.142.116 lookup ISP3 
@@ -28,7 +27,7 @@
 
 Table balance:
 
-default nexthop dev ppp1 weight 1 nexthop dev ppp2 weight 1 nexthop dev ppp3 
weight 1
+default nexthop dev ppp1 weight 1 nexthop dev ppp2 weight 1
 
 Table default:

c) Enabling ppp3 reverses the changes make by disabling it, which is
also correct:

--- routing2    2018-10-09 01:04:53.000000000 -0700
+++ routing3    2018-10-09 01:04:53.000000000 -0700
@@ -7,6 +7,7 @@
 999:   from all lookup main 
 10000: from all fwmark 0x1/0xff lookup ISP1 
 10001: from all fwmark 0x2/0xff lookup ISP2 
+10002: from all fwmark 0x3/0xff lookup ISP3 
 20000: from 83.61.3.216 lookup ISP1 
 20000: from 79.148.120.225 lookup ISP2 
 20000: from 83.50.142.116 lookup ISP3 
@@ -27,7 +28,7 @@
 
 Table balance:
 
-default nexthop dev ppp1 weight 1 nexthop dev ppp2 weight 1
+default nexthop dev ppp1 weight 1 nexthop dev ppp2 weight 1 nexthop dev ppp3 
weight 1
 
 Table default:

    Note that routing1 and routing3 are identical.

d) Reloading shorewall results in no change in routing; routing3 and
routing4 are identical except for the timestamp.

e) Running the ppp3 init script has serious effects on routing:

    - A new IP address was assigned, resulting in changes to both the
local and main tables.
    - Default routes that included ppp3 were deleted entirely, including
the one in the balance table.

--- routing4    2018-10-09 01:06:33.000000000 -0700
+++ routing1b   2018-10-09 01:09:53.000000000 -0700
@@ -1,4 +1,4 @@
-Shorewall 5.2.0.5 Routing at inf-gw1 - Tue Oct  9 10:06:33 CEST 2018
+Shorewall 5.2.0.5 Routing at inf-gw1 - Tue Oct  9 10:09:53 CEST 2018
 
 
 Routing Rules
@@ -24,11 +24,9 @@
 
 Table ISP3:
 
-default dev ppp3 scope link
 
 Table balance:
 
-default nexthop dev ppp1 weight 1 nexthop dev ppp2 weight 1 nexthop dev ppp3 
weight 1
 
 Table default:
 
@@ -36,8 +34,8 @@
 Table local:
 
 local 83.61.3.216 dev ppp1 proto kernel scope host src 83.61.3.216
-local 83.50.142.116 dev ppp3 proto kernel scope host src 83.50.142.116
 local 79.148.120.225 dev ppp2 proto kernel scope host src 79.148.120.225
+local 79.146.182.205 dev ppp3 proto kernel scope host src 79.146.182.205
 local 192.168.92.2 dev enp7s0 proto kernel scope host src 192.168.92.2
 local 192.168.228.1 dev enp5s0 proto kernel scope host src 192.168.228.1
 local 192.168.101.2 dev enp8s5 proto kernel scope host src 192.168.101.2
@@ -61,7 +59,7 @@
 
 Table main:
 
-192.168.144.1 dev ppp3 proto kernel scope link src 83.50.142.116
+192.168.144.1 dev ppp3 proto kernel scope link src 79.146.182.205
 192.168.144.1 dev ppp2 proto kernel scope link src 79.148.120.225
 192.168.144.1 dev ppp1 proto kernel scope link src 83.61.3.216
 172.16.0.0/28 dev enp10s0 proto kernel scope link src 172.16.0.2

f) Now, disabling ppp3 causes the change in IP address to be picked up
in the routing rules, and the default route in table ISP3 to be
re-added. Note that there is nothing to change in the balance table,
since the default route there got blown away by the init script.

--- routing1b   2018-10-09 01:09:53.000000000 -0700
+++ routing2b   2018-10-09 01:09:53.000000000 -0700
@@ -7,10 +7,9 @@
 999:   from all lookup main 
 10000: from all fwmark 0x1/0xff lookup ISP1 
 10001: from all fwmark 0x2/0xff lookup ISP2 
-10002: from all fwmark 0x3/0xff lookup ISP3 
 20000: from 83.61.3.216 lookup ISP1 
 20000: from 79.148.120.225 lookup ISP2 
-20000: from 83.50.142.116 lookup ISP3 
+20000: from 79.146.182.205 lookup ISP3 
 32765: from all lookup balance 
 32767: from all lookup default 
 
@@ -24,6 +23,7 @@
 
 Table ISP3:
 
+default dev ppp3 scope link
 
 Table balance:


g) Now, re-enabling ppp3 doesn't fix things because the balance table is
empty. So only a default route out of ppp3 is added (along with the
fwmark rule):

--- routing2b   2018-10-09 01:09:53.000000000 -0700
+++ routing3b   2018-10-09 01:09:53.000000000 -0700
@@ -7,6 +7,7 @@
 999:   from all lookup main 
 10000: from all fwmark 0x1/0xff lookup ISP1 
 10001: from all fwmark 0x2/0xff lookup ISP2 
+10002: from all fwmark 0x3/0xff lookup ISP3 
 20000: from 83.61.3.216 lookup ISP1 
 20000: from 79.148.120.225 lookup ISP2 
 20000: from 79.146.182.205 lookup ISP3 
@@ -27,6 +28,7 @@
 
 Table balance:
 
+default dev ppp3
 
 Table default:

h) The final reload fixes things by rebuilding the correct default route
in the balance table:

--- routing3b   2018-10-09 01:09:53.000000000 -0700
+++ routing4b   2018-10-09 01:10:20.000000000 -0700
@@ -1,4 +1,4 @@
-Shorewall 5.2.0.5 Routing at inf-gw1 - Tue Oct  9 10:09:53 CEST 2018
+Shorewall 5.2.0.5 Routing at inf-gw1 - Tue Oct  9 10:10:20 CEST 2018
 
 
 Routing Rules
@@ -28,7 +28,7 @@
 
 Table balance:
 
-default dev ppp3
+default nexthop dev ppp1 weight 1 nexthop dev ppp2 weight 1 nexthop dev ppp3 
weight 1
 
 Table default:
 

In summary

  * If the modem is rebooted, things don't work until the ppp script is run.
  * If the ppp script is run, routing is changed behind Shorewall's back
    so that, at least in some cases, only a 'reload' can put things back
    together again.
  * You didn't capture the output of 'shorewall show routing' after you
    simply ran the ppp init script, but I'm guessing that only the ppp3
    part of the default route in the balance table got deleted in that
    case. Thus, 'enable ppp3' was able to do the right thing.

-Tom

-- 
Tom Eastep        \   Q: What do you get when you cross a mobster with
Shoreline,         \     an international standard?
Washington, USA     \ A: Someone who makes you an offer you can't 
http://shorewall.org \   understand
                      \_______________________________________________


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to