On Tue, May 03, 2022 at 04:16:11PM +0100, Ian Chilton wrote:
> Hi Claudio,
>
> This makes sense in terms of protecting the firewall hosts and is useful:
>
> > If not I would normally use something like:
> > set block-policy drop
> >
> > pass no state
> > block all to <self>
> > pass in proto tcp from <allowed> to <self> port { bgp ssh }
> > # more rules using to <self> here
> > # locally initiated connections should establish state
> > pass out ! received-on any
>
> ...however you don't explain how you would do VLANs behind these hosts.
Everything behind the hosts hit the 'pass no state' rule and that's it.
> With ICMP, it can be allowed, so I can use `no state`. However, with
> TCP/UDP, then some state tracking is required to allow replies. This is
> what i'm struggling with, the best way to achieve that.
Not at all with 'pass no state' every packet that is not denied will be
forwarded. So you can add extra block rules if needed but there is little
smarts.
I feel you try to shoehorn too many things into gw1 and gw2.
If you want stateful firewalls then all traffic needs to pass via the
active firewall. There can be a hot-standby to take over but active-active
is not worth the trouble. You have more issues and downtime from fiddling
with such a setup.
My setups normally look like this:
br1 br2 br3 brX
< IGP CLOUD, FULLMESH OR EQUIVALENT >
l1-fw1 l1-fw2 l2-fw1 lw-fw2
NET1 NET2 NET3
The border routers terminate all ebgp sessions. Then an ibgp full mesh
connects the firewalls with the border routers. The firewalls are
redundant. Depending is OSPF is in use or not the way NET1, NET2 and NET3
are announced differs. In anycase the goal is that the active firewall
gets all the traffic and the passive one gets none.
In a pure BGP setup this is a bit tricky because bgpd does not offer a
usable 'depend on' for announcements. In that case I use an external carp
address (towards the ibgp cloud) and announce the network with the carp IP
as nexthop.
There is no BGP or OSPF inside NET1, NET2 or NET3 (pure leafs).
The goal is KISS. I also avoid doubling up on redundancy protocols like
LACP. At least I had more issues and down time because of too much
redundancy.
> > pfsync(4) is at best eventually consistant and it is not fast enough to
> > handle asymetric routing. Sure there is the option to defer packets until
> > after a state has been synced but that is a bandaid introducing additional
> > delays in all connections.
>
> Yes... this is something i'm now starting to hit.
>
> When I first set up pfsync, it all seemed fine. I am using defer and
> there was a pause while it created/sync'd the state and it seemed to
> work as intended.
>
> However, now I am seeing things like the first few packets missing on
> some pings etc, which is not ideal.
>
> Thanks,
>
> Ian
--
:wq Claudio
