On 1/21/23, David Gwynne <da...@gwynne.id.au> wrote: > 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.
Thanks for taking the time to explain in these two paragraphs. I definitely have a better sense of veb/vport now. > 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 Nice. > 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... >
