On 2019-03-02, Rachel Roch <rr...@tutanota.de> wrote: > Hi, > > I would be interested to find out the community's view on whether separating > "router" and "firewall" roles is still a good thing or whether developments > in recent iterations of OpenBSD would permit aggregation whilst maintaining > integrity and security ? > > If you forgive my attempt at ASCII art (which I hope survives internet > mangling), this would be representative of what I would do for a > "traditional" setup: > > (BGP) (BGP) > | | > ["router"] ["router"] | \ / | > | \ / | > | / \ | > | / \ | > ["firewall"] ["firewall"] > > > • The routers talk full BGP externally and default-route BGP to the firewalls. > • The firewalls talk offer VRRP internally and also BGP default-route > internally to those that can talk BGP > • The firewalls also offer other internal services such as NTP etc.• The > firewalls also act as a VPN endpoint externally using a combination of iked, > ifstated and other stuff to make it work > • The firewalls are very much perimeter firewalls, they don't do detailed > content handling such as mail etc., that is done elsewhere > Various factors have led to a hardware refresh for this kit, and as part of > that I'm curious as to whether I can consolidate without (a) loosing the > benefits of the split model and (b) introducing too much un-necessary > additional complexity. > > Thanks ! > > Rachel > >
The biggest problem is that, if you're advertising on both BGP routers, traffic coming from the internet can hit either machine. And traffic from your internal networks to the internet will be via whichever is carp master. So you can end up with the situation where packets associated with one connection are going via different machines, which can cause problems with stateful firewalling (in particular the TCP sequence number checks). There are several ways to work with this but there are trade-offs with all of them, and if none are acceptable then - Best option if your peer sessions are run on a subnet large enough for carp: upstream 192.0.2.1 rtr1+2 carp ip 192.0.2.2 rtr1 real 192.0.2.3 rtr2 real 192.0.2.4 Run these BGP sessions: 192.0.2.3 <> 192.0.2.1 192.0.2.4 <> 192.0.2.1 And set nexthop on your announcements to the carp ip (192.0.2.2). That way you can keep the bgp sessions up all the time on both machines and have the traffic flow towards whichever machine is carp master. (thanks Tony Sarendal for the clue about this method - https://marc.info/?l=openbsd-misc&m=153684583625250&w=2) - There is a way to handle this with PF by using pfsync(4) with the "defer" flag but it's not perfect and it would be better to avoid that if possible. You need to wait until the second firewall has added the state before passing the traffic (this is what "defer" does), and also pfsync needs to send TCP sequence number updates all the time during the session so the other firewall can keep in sync, - Another way to handle it is to hold the BGP sessions down on the machine that is carp backup (bgpd.conf "depend on carpX") but that's not ideal in a carp switchover situation as you'll have some delay while BGP brings up the sessions and pulls routes from the peer. Also you're reliant on sessions on the carp master to send you traffic, if an important peer on that machine goes down, you won't see traffic flow via the backup. - Or you can have the BGP sessions up all the time but only announce your networks from the carp master, you should be able to do that with ifstated and "bgpctl network add". As above you're still reliant on sessions on the carp master, but at least you don't need to pull the routing table after a carp switchover. If the first method is viable then there's not too much of a problem collapsing this onto one pair of machines. The tradeoffs for the other methods aren't so nice and in that case I'd usually want the extra machines so I could avoid them..
