On 10/08/2018 05:53 AM, Vieri Di Paola via Shorewall-users wrote: > On Friday, October 5, 2018, 6:51:04 PM GMT+2, Tom Eastep > <teas...@shorewall.net> wrote: > >>> >>> Finally, a shorewall restart (full stop and start) actually DID solve the >>> issue. I magically got my ppp3 link working again. >>> So, of course, I'm worried that if there's a power outage or if someone >>> reboots the modems then the gateway might get cut off from the Internet if >>> shorewall doesn't restart. >> >> I can't comment without seeing the difference between the ruleset after > '> reenable' and the ruleset after 'restart'. > > Here's the dump after "reenable ppp3" (no traffic through provider): > > https://drive.google.com/open?id=13MOhqHX7Im6uu8khr5DQTNuMypxQG8U3
It is remarkable that there was no traffic via ppp3, given that ppp3 was the ONLY interface that should have been working. > > And here's the dump after "restart" (traffic OK through provider): > > https://drive.google.com/open?id=1GKOjtcEzc8H7JLI1V7hgPwMe3n6ECiXg There are two significant differences between the two dumps: - Given that you specify 'defaultroute' in your ppp configuraton, the following route appears in the 'main' table after you have brought ppp3 back up: 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. - In the 'balance' table, we have this route after 'reenable': default dev ppp3 After 'restart', we have: default nexthop dev ppp1 weight 1 nexthop dev ppp2 weight 1 nexthop dev ppp3 weight 1 I'm not sure what to make of this: - 'reenable' is the same as 'disable' then 'enable' - After the 'disable', there was apparently no default route in the 'balance' table, but we don't know what was there before the 'disable'. At the next opportunity that you have to disrupt the firewall, it would be instructive to do the following: shorewall show routing > routing1 shorewall disable ppp3 shorewall show routing > routing2 shorewall enable ppp3 shorewall show routing > routing3 If you don't feel that traffic is being sent via ppp3, then shorewall reload shorewall show routing > routing4 Thanks! > >>>> 10003: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc tbf state >>>> UP group default qlen >>> 3: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state >>> UP group default qlen 1000 >>> I still don't know why some interfaces are set to use pfifo_fast, or if >>> it's recommended or not for a gateway/router. >> >> Which has nothing to do with Shorewall... > > OK, I was just asking because the tbf qdisc is set by Shorewall when enabling > traffic shaping. Also , /usr/share/shorewall/Shorewall/Tc.pm seems to deal > with fq_codel, and there's documentation referencing fq_codel here: > > http://shorewall.net/manpages4/manpages/shorewall-tcclasses.html > http://shorewall.org/traffic_shaping.htm > > Anyway, I'll study that later on if time permits. > What I really meant was that setting fq_codel as the default queuing discipline has nothing to do with Shorewall, and I can't comment on whether that is a good idea or not. -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 \_______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
