Re: sshguard fails to start

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

On Fri, May 25, 2018 at 10:05:22AM -0400, Greg Troxel wrote:
> 
> Patrick Welche <prlw1%cam.ac.uk@localhost> writes:
> 
> > On Wed, May 23, 2018 at 11:03:38PM +0100, Mike Pumford wrote:
> >> I'm going to be attempting to reproduce it in npf as well as I've got an
> >> updated firewall box to deploy which I'm hoping will use npf instead of ipf
> >> (assuming I can make npf do everything I want).
> >
> > FWIW I'm going back to ipf: AFAICT keep state with ipf sends replies back
> > through the interface the requests came in on, but npf obeys the routing
> > table. It seems I was relying on ipf's behaviour. Feature? Bug?
> 
> To first order, a firewall should pass/drop, and not adjust routing,
> unless there's some extra rule which makes an affirmative request to
> grab a packet and reroute it contrary to the routing table.   keep state
> is just a 2nd-order rule to add temporary rules for replies to packets
> seen in one direction.
> 
> So I think you are relying on a probably-bug.
> 
> If you disable the firewall briefly, does your system still work?  (Or
> do you think it would, if you don't want to?)

Maybe this use-case is "don't do that". Essentially: take an "internal"
computer, with its default gateway. Add another network card. Connect
it directly to "outside", and say run a webserver on it. If you run
ipf saying block everything on the external card except to port http
keep state, anyone can successfully connect to your webserver, but
not to your sshd. If you try the same with npf, the reply from the
server will be routed via the default gateway, and the 3rd packet,
i.e., the second from the web client, will be blocked as not matching
the connection state. (I was confused for ages in PR 53199)
("outside" has its own gateway.)

Cheers,

Patrick