[Shorewall-users] enable <provider> failed

[Simon Hobson]

Had an oddball yesterday, when the office lost internet connectivity. In the logs I found

May 4 12:44:12 *** logger: ERROR:Shorewall 'enable ***' failed
May 4 12:44:13 *** logger: Shorewall Stopped

One of the configured FTTC (VDSL2) providers had gone down and come back up, and I have a script in /etc/ppp/ip-up.d that calls "shorewall enable ***" after the PPP connection is up - but for some reason it failed this once. It's been working fine for some time with one provider, I've recently added this one by simply cloning all the config entries from the existing one. If I manually drop the PPP connection then everything works fine, and there have been a couple more line drops since where it's worked fine.

So clearly a transient error, but any ideas what could have caused it ? I know manglement will be asking for more than "sh*t happens" !

Also, what does "shorewall enable ..." do ? I assume it's running a subset of "shorewall [re]start" to build the routing tables - is it normal for a failure like this to result in a stopped state ?

[Tom Eastep]

Post by Simon Hobson
Had an oddball yesterday, when the office lost internet
connectivity. In the logs I found
May 4 12:44:12 *** logger: ERROR:Shorewall 'enable ***' failed May
4 12:44:13 *** logger: Shorewall Stopped
One of the configured FTTC (VDSL2) providers had gone down and come
back up, and I have a script in /etc/ppp/ip-up.d that calls
"shorewall enable ***" after the PPP connection is up - but for
some reason it failed this once. It's been working fine for some
time with one provider, I've recently added this one by simply
cloning all the config entries from the existing one. If I manually
drop the PPP connection then everything works fine, and there have
been a couple more line drops since where it's worked fine.
So clearly a transient error, but any ideas what could have caused
it ? I know manglement will be asking for more than "sh*t happens"
!

The details about the failure would have been written to STDERR prior
to logging those messages.

Post by Simon Hobson
Also, what does "shorewall enable ..." do ?

It runs the part of 'start' that deals with that particular provider;
you can see the code in the function 'start_provider_<provider name>'
in the compiled script.

Post by Simon Hobson
I assume it's running a subset of "shorewall [re]start" to build
the routing tables - is it normal for a failure like this to result
in a stopped state ?

When an essential command like adding an iptables rule or adding a
route fail, the firewall is placed in the 'stopped' state. I could
take a look at changing that behavior in the case of 'enable'.

- -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.net \________________________________________________

[Simon Hobson]

Post by Tom Eastep

Post by Simon Hobson
So clearly a transient error, but any ideas what could have caused
it ? I know manglement will be asking for more than "sh*t happens"
!

The details about the failure would have been written to STDERR prior
to logging those messages.

That'll be lost then, there's nothing in syslog or messages other than that. I can see logging from PPP saying the script is starting, and then finished, nothing in between so I guess it'll have gone in the bit bucket.

Post by Tom Eastep

Post by Simon Hobson
Also, what does "shorewall enable ..." do ?

It runs the part of 'start' that deals with that particular provider;
you can see the code in the function 'start_provider_<provider name>'
in the compiled script.

That makes sense, I'll take a look - always like to know what's going on "under the hood".

Post by Tom Eastep

Post by Simon Hobson
I assume it's running a subset of "shorewall [re]start" to build
the routing tables - is it normal for a failure like this to result
in a stopped state ?

When an essential command like adding an iptables rule or adding a
route fail, the firewall is placed in the 'stopped' state. I could
take a look at changing that behavior in the case of 'enable'.

Tricky one that.
In the case of a failed enable, perhaps it might be safer to roll-back in much the same way as a safe-restart does ? Better to leave what was working still working, even if it means not having this provider working.


But right now I'm inclined to just leave it. They're wanting me to take redundancy*, and I know that this will be on their priority list of things to rip out and replace as the guy effectively in charge has a "doesn't come from Redmond, I won't learn anything about it" approach to systems.
* Makes sense of some of the business decisions lately.