On Sat, Jan 21, 2023 at 01:32:18PM -0800, patrick keshishian wrote: > On 1/20/23, Hrvoje Popovski <hrv...@srce.hr> wrote: > > On 20.1.2023. 20:09, patrick keshishian wrote: > >> Hello, > >> > >> I am trying get a new ISP setup working. The Router is > >> causing some pain. There is a /28 public block assigned. > >> The DSL router can't be configured in transparent bridge > >> mode (they say). It holds on to one of the /28 addresses. > >> > >> The setup looks something like this: > >> (and hopefully the ascii "art" remains intact from gmail) > >> > >> ( internet ) > >> | > >> | [WAN IP] > >> +-----o------+ > >> / DSL ROUTER / <-- Transparent bridge mode NOT possible > >> +-----o------+ > >> | [ one of /28 Public IPs = $dslgw_ip ] > >> | > >> | > >> | $ext > >> +-----o------+ > >> | | > >> | OpenBSD/pf o--- ( rest of /28 Public IP network ) > >> | | $dmz (DMZ: httpd, smtpd, ...) > >> +-----o------+ > >> $lan | [10.x.x.1] > >> | > >> ( 10.x.x.x network ) > >> > >> > >> As far as networking goes, I need to be spoken to as if I'm > >> a fledgling. > >> > >> I want to do the obvious: use OpenBSD/pf(4) to: > >> - Filter traffic from $ext to $dmz > >> - Filter traffic from $dmz outbound > >> - Filter traffic from $lan (10.x.x.x) to $dmz > >> - NAT traffic from $lan (10.x.x.x) outbound to internet > >> > >> > >> I'm bridge(4)-ing $ext and $dmz. Which means I must give > >> one of the /28 public IP addresses to either $ext or $dmz > >> to be able to do: > >> > >> # route add default $dslgw_ip > >> > >> (!?) > >> > >> Am I missing something? > >> Is there a better way to configure things? > >> > >> Thanks, > >> --patrick > >> > > > > Hi, > > > > If your ext interface is in same subnet as that /28 from your ISP then > > you could: > > > > - use veb(4) to bridge ext, dmz and vport(4) interface and add default > > route to dslgw_ip. vport is ip interface for veb > > I started out looking at veb(4) but I wasn't confident > how I could filter traffic in/out of $dmz. Also, the > description of vport(4) which states "packets traversing > vport interfaces appear to travel in the opposite direction > to packets travelling over other ports" confused me even > more. So I started using bridge(4).
When you add a port to veb(4), it takes it over completely and by default it only uses it to switch traffic at layer 2 (Ethernet). In other words, by default veb(4) does not run pf against packets on ports. vport is an exception because it operates as if it is a normal ethernet interface plugged into a switchport, it's just that the switch in this situation is veb, and the other ports on that switch are the non-vport interfaces you added to the veb. So, by default veb lets you build a switch out of other interfaces in the system, and vport lets you plug the kernel network stack into that virtual switch. Because packets from a normal switch coming into a normal physical interface go in to the network stack, that is also how it behaves with vport. ie, you write rules in pf like this for packets coming from a veb into a vport: pass in on vport0 inet tcp from any to port ssh If you do enable IP filtering on veb (ie, you ifconfig veb0 link1 as per the ifconfig manpage), then packets coming from the "wire" into the interface are filtered by pf too. This means that if a packet is coming from the wire and is destined to your network stack via a vport interface, it will be going through pf twice: once when it comes into the physical interface and again when it goes over vport. pf is not designed for a packet to be processed twice. TCP packets in particular going through pf twice will confuse the window tracking. If you're doing NAT or something like that, it can also get confused. So if you're going to enable link1 on veb(4), you need to either skip pf on the vport interface, or put the veb and vport into different rdomains so pf will keep separate the states for them. It is doable and supported, you just need to be mindful of this semantic. I found running pf on bridge(4) to be a nightmare, cos every interface you add as a port on bridge kind of acts as two ports, one that goes to the wire and another that goes to the stack, but it's hard to say which will happen and what the right way to filter it is. veb(4) taking over interfaces completely and not running pf by default is in large part because of this pain I had with bridge. > > - or on ext interface put ip alias with ip addresses from /28 public > > range and than do binat-to or nat-to in pf to hosts in dmz > > > > or maybe i totally misunderstood you :) > > I think you understood me fine. I'm just not too familiar > with how networking actually works. Then on top of the networking theory there's the quirks of how different systems implement things...
