On Sun, 17 Nov 2013 15:32:01 +0100, Marko Cupać <[email protected]> wrote: > I have two routers in active/passive carp mode that share three pairs > of carp interfaces: > bge1 - DMZ > em0 - ISP1 > em1 - ISP2 > > They are also syncing pf states over syncdev bge0. > > Both routers are in BGP sessions with two upstream providers (via /29 > networks), and I am achieving graceful failover by means of bgpd.conf: > ... > network MY.NET.WO.RK/24 set nexthop <carp ip to isp1> > network MY.NET.WO.RK/24 set nexthop <carp ip to isp2> > ... > > I noticed ssh login attempts to one of my DMZ servers even though this > server is not in table of hosts for which ssh login is permitted: > $pass in on $if_isp1 inet proto tcp from any to <ssh> port ssh \ > modulate state \ > ( max-src-conn-rate 5/60, overload <badsshlogins> flush global) \ > set queue (isp1-run,isp1-ack) > > Question #1: > How can I troubleshoot this? Is it possible that some ancient state is > keeping ssh to that host possible (eg. if I enabled it in past, and > later reloaded pf.conf but without flushing states)? > If you have large rulsets you may have overlapping rules. Try connecting from a test machine on the outside to the public ip mapped to the internal server (but which isn't in the 'ssh' table). Once you have tried to connect if you are successful but shouldn't have been, run 'pfctl -ss -vv' greping for the IP of your outside host. Look for the pf rule number on the active pf state.
If the rule number is a '*' i think this means the original pf rule which created the state no longer exists in pf rule memory. Sure thats the case with 'systat 8' anyway. Finally run 'pfctl -sr -vv' and find the matching pf rule number.. > I have source track rule which should drop all > traffic with any host that fails to login 5 times over 60 seconds > period by dynamically updating <badsshlogins>, as I have: > block log quick from <badsshlogins> > block log quick to <badsshlogins> > > ...early in the ruleset. > > Question #2: how come that, even though table <badsshlogins> is > filling up over time, I see some host violating this in security logs > of my DMZ servers but not being put in <badsshlogins> table > Probably another old rule without any statefull source tracking applied matching the connection. The above steps would also show you if this was the case. > Question #3: <badsshlogins> on 2nd firewall is empty. Can they be > synced like states, or violators need to violate the rule on 2nd > firewall in order to have all the traffic with them blocked? No I don't think tables are sync'ed yet. Hopefully one day > > Question #4: Is there a better way of connecting to 2 upstream > providers with graceful failover ability? You could try tuning your BGP attributes with your transit providers to improve BGP responsiveness maybe. BFD (Bidirectional Forward Detection) is probably the best way to handle BGP timeliness. The benefit of BFD is that the moment your link goes down, within less than a second /both/ sides have gracefully torn down their eBGP neighbour relationships and pulled the routes. This means your public announce on that side should also go down quickly reducing the chance of inbound connections heading towards you via the down ISP, because they are still announcing you.. Of course you always suffer any BGP dampening systems networks might have. BFD is supported on various commercial routers including Cisco and Juniper etc, but not yet by OpenBSD. Rivo Nurges kindly said he would try to find some time to look at implementing this for OpenBSD, so if we're lucky we might have something soon to really improve BGP responsiveness when using OpenBSD. Andy. > > Thank you in advance,
