pf on bridge interface not working
This came through to me from the list with “no content”, so I’m trying again.
——
My box has three interfaces, dc0 to manage, em0 and em1 for bridging external
LAN to internal LAN.
hostname.em0: up
hostname.em1: up
hostname.bridge0: add em0 add em1 up
Bridge works, traffic flows across no problem.
Add filtering.
pf.conf:
filtered = "{ em1 }”
not_filtered = "{ lo, dc0, em0, bridge0 }”
block log on $filtered
set skip on $not_filtered
`doas pfctl -sr`
block drop log on em1 all
`tcpdump -nettti pflog0` shows lots of filtered packets. Traffic is blocked.
-But-
make one simple change to filter on the bridge0 interface—
pf.conf:
filtered = "{ bridge0 }”
not_filtered = "{ lo, dc0, em0, em1 }”
block log on $filtered
set skip on $not_filtered
`doas pfctl -sr`
block drop log on bridge0 all
traffic is NOT blocked and everything flows right on through. (!?)
`tcpdump -nettti pflog0` shows no packets being filtered.
Am I overlooking something?
E
Re: pf on bridge interface not working
On Sat, Feb 20, 2021 at 04:17:11PM -0600, Eric Zylstra wrote:
> -But-
> make one simple change to filter on the bridge0 interface—
>
> pf.conf:
> filtered = "{ bridge0 }”
> not_filtered = "{ lo, dc0, em0, em1 }”
> block log on $filtered
> set skip on $not_filtered
>
> `doas pfctl -sr`
> block drop log on bridge0 all
>
> traffic is NOT blocked and everything flows right on through. (!?)
> `tcpdump -nettti pflog0` shows no packets being filtered.
>
> Am I overlooking something?
Perhaps this from bridge(4):
--8<--
NOTES
Bridged packets pass through pf(4) filters once as input on the receiving
interface and once as output on all interfaces on which they are
forwarded. In order to pass through the bridge packets must pass any in
rules on the input and any out rules on the output interface. Packets
may be blocked either entering or leaving the bridge.
-->8--
I partly recall a phrasing that I cannot find again now, unsure whether
it was from a manpage or from the FAQ; Something along: "Due to the
nature of bridged interfaces [...] you really have to understand this
very well to do [packet filtering] right".
Erling
Re: pf on bridge interface not working
Re: pf on bridge interface not working
On 2021-02-20, Eric Zylstra wrote:
> -But- make one simple change to filter on the bridge0 interface--
> pf.conf:
>
> filtered = "{ bridge0 }"
> not_filtered = "{ lo, dc0, em0, em1 }"
> block log on $filtered
> set skip on $not_filtered
>
>
>> doas pfctl -f /etc/pf.conf
>
>> doas pfctl -sr
>
> block drop log on bridge0 all
>
>
>
> Despite the rules displayed by pfctl, traffic is NOT filtered. (!?)
> `tcpdump -nettti pflog0` shows no packets being filtered.
>
>
>
> What am I overlooking?
bridge(4) doesn't work like that on OpenBSD. You need to filter the member
ports instead.
On the whole bridge and PF interactions are a bit complicated. Keep an eye
out for veb(4) (https://marc.info/?l=openbsd-tech=161335364329307=2)
which maybe coming to a tree near you soon which will simplify things a lot.
pf on bridge interface not working
Re: pf vs. bridge vs. spamd
On Wed, Mar 24, 2010 at 09:08:48PM -0400, Geoff wrote: I'm trying to set up spamd on my firewall system. The configuration is tricky because my upstream provider (Verizon) only gives me 5 IPs, all on the same subnet. The firewall system is acting as a bridge and as a router. SNEEP I think you're taking the wrong approach here by including a bridge. Configure the interface with the default route to have all 5 IP addresses. Configure the hosts to be protected by the firewall, but reachable by the public internet to be on one or more subnets within the RFC 1918 space. Use rdr rules (or the newer equivalent) for the SPECIFIC access required by from the public internet. Use nat rules for the specific access they need to the public internet. *IF* you do that you can use relayd or some of the fancier rdr rules to load balance across multiple backend hosts. You can also use one IP address to service multiple services that are actually provided by multiple backend boxes if the load demands such separation. -- Chris Dukes
Re: pf vs. bridge vs. spamd
From owner-m...@openbsd.org Received: from shear.ucar.edu (lists.openbsd.org [192.43.244.163]) by lib.oat.com (8.14.3/8.14.3) with ESMTP id o2PHfPNN023169 for g...@oat.com; Thu, 25 Mar 2010 13:41:28 -0400 (EDT) Received: from openbsd.org (localhost.ucar.edu [127.0.0.1]) by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id o2PHdSXJ009239; Thu, 25 Mar 2010 11:39:28 -0600 (MDT) Received: from pr.neotoma.org (raleigh.neotoma.org [24.106.182.151]) by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id o2PHarnF026642 for misc@openbsd.org; Thu, 25 Mar 2010 11:36:54 -0600 (MDT) Received: by pr.neotoma.org (Postfix, from userid 1002) id 66CF52EC3B; Thu, 25 Mar 2010 13:36:53 -0400 (EDT) Date: Thu, 25 Mar 2010 13:36:53 -0400 To: Geoff g...@oat.com Cc: misc@openbsd.org Subject: Re: pf vs. bridge vs. spamd On Wed, Mar 24, 2010 at 09:08:48PM -0400, Geoff wrote: I'm trying to set up spamd on my firewall system. The configuration is tricky because my upstream provider (Verizon) only gives me 5 IPs, all on the same subnet. The firewall system is acting as a bridge and as a router. SNEEP On Thu Mar 25 at 13:41:29 2010, Chris Dukes wrote: I think you're taking the wrong approach here by including a bridge. Configure the interface with the default route to have all 5 IP addresses. Configure the hosts to be protected by the firewall, but reachable by the public internet to be on one or more subnets within the RFC 1918 space. Use rdr rules (or the newer equivalent) for the SPECIFIC access required by from the public internet. Use nat rules for the specific access they need to the public internet. *IF* you do that you can use relayd or some of the fancier rdr rules to load balance across multiple backend hosts. You can also use one IP address to service multiple services that are actually provided by multiple backend boxes if the load demands such separation. Your solution is quite nice, except for one problem: The hosts inside the firewall need to know their external addresses. That can't change. PF is an IP facility. Unfortunately, in order for it to work correctly when applied to a bridge, once a packet has been redirected it needs to get a correct link-level address. Right now, packets are assigned routes (implying link level addresses) at ingress. Routes need to be reassigned if packet destinations change during bridging. That's the core problem. I've had a lot of problems with IPSEC, etc, due to the ad-hoc interactions of IP level functions with link-level functions. I've thought of a scheme to fix this but obviously I don't want to go through development if there's a solution already. Geoff
Re: pf vs. bridge vs. spamd
On Wed, Mar 24, 2010 at 09:08:48PM -0400, Geoff wrote:
I'm trying to set up spamd on my firewall system.
The configuration is tricky because my upstream provider
(Verizon) only gives me 5 IPs, all on the same subnet.
The firewall system is acting as a bridge and as a router.
I've been looking through pf.c, if_bridge.c in -current
The changes seem to answer some of my complaints.
I'm going to have to update run some tests...
I hope all of the team's effort has made this much, much better.
There's one set of tests at lines 5770-5773 of net/pf.c:
kif-pfik_bytes[0][dir == PF_OUT][action != PF_PASS] += pd.tot_len;
kif-pfik_packets[0][dir == PF_OUT][action != PF_PASS]++;
if (action == PF_PASS || r-action == PF_DROP) {
Where I wonder if the tests for PF_PASS should also
include PF_DIVERT? It looks like PF_DIVERT packets would
be incorrectly accounted for in the two single
lines and completely missed in the large block.
thanks
geoff
pf vs. bridge vs. spamd
I'm trying to set up spamd on my firewall system. The configuration is tricky because my upstream provider (Verizon) only gives me 5 IPs, all on the same subnet. The firewall system is acting as a bridge and as a router. Two interfaces (sk0 and vr0) are in a bridge: bridge0: flags=3041UP,RUNNING,LINK0,LINK1 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp sk0 flags=7LEARNING,DISCOVER,BLOCKNONIP port 1 ifpriority 0 ifcost 0 vr0 flags=3LEARNING,DISCOVER port 3 ifpriority 0 ifcost 0 Addresses (max cache: 100, timeout: 240): 00:1b:2f:b9:6c:c5 vr0 0 flags=0 00:90:1a:a2:0a:ba sk0 1 flags=0 6c:f0:49:0c:07:79 vr0 0 flags=0 00:30:18:a8:10:76 vr0 1 flags=0 00:24:1d:19:01:0d vr0 1 flags=0 sk0 connects to my fiber connection - it is in group wan vr0 connects to a switch - my local hub - it is in group lan they are not assigned any addresses re0 is the interface for this host's traffic It is connected to the local hub and has multiple addresses in order to act as a router. It is in group int. The system is configured this way in order to have separate sets of filter nat rules on the bridge and the local interface, as well as letting the lan hosts with routable addresses talk directly to the upstream link. I know that the documentation recommends assigning an address to one interface on the bridge. I tried to assign the routable address of the firewall machine to an interface on the bridge and the pf rules became a nightmare of complexity and never worked right. There is no way I can get an additional IP from the provider to talk to the upstream link (without paying many $$$). The system is sometimes multi-homed, talks via tunnels to other networks, supports routing to test networks, etc., etc., so keeping the rule sets simple and without unexpected interactions is essential. Table locals contains my assigned subnet and 192.168.0.0/16 Table mail_servers contains my mail servers' external addresses If I put a nat rule into pf: rdr pass in on wan proto tcp from !locals to mail_servers \ port smtp - 127.0.0.1 port spamd and a filter rule pass quick in on wan from any to any port smtp flags any Then packets pass through the bridge to the switch with 1) the mail server link level address 2) IP 127.0.0.1 This doesn't work, of course, because the switch delivers the packet to the original destination. I haven't found any way to alter the link level address or force pf to put the packets on either lo0 or re0's input queue. I've tried fastroute in the filter rule. I've tried a route-to and reply-to pair. I've tried divert-to. In all cases the packets disappear - they aren't seen by tcpdump on any interface. Is there anything I haven't tried? I've searched for any examples of something like this. I am thinking of creating a virtual interface virt which is the lo code modified: delete the call to enqueue output packets on the input queue add an Ethernet header with a fabricated Ethernet address and confguring an instance of this to the bridge. I -think- that would do what I want. Maybe. The bridge might still force the packets out the lan branch because of the ethernet address on the packet. Any suggestions? I'd be willing to rearrange the bridge code to respect routing by pf, if there is no other way to make this work. thanks Geoff Steckel
Re: OpenBSD 4.4 pf+vlan+bridge problem
Hi! Wouldn't it be better to not use the bridge and use (multicast-)routing and pf to solve your problem? Multicast routing with dvrmpd is tested with pf, does not work. the same thing happens, if streamX is allowed to pass out on vlanX and streamY is allowed to pass out on vlanY, result is pretty similar: vlanX outputs both streams (streamX, streamY) and the same thing with vlanY. pf is not 100% percent multicast compat.? Since these days i tried out anyway how multicast routing is and decided to set up also similar configuration as described in the beginning of this thread assuming for pf multicast traffic is no different from any other 'ordinary' traffic. I believe the reason why with a rule like this pass out quick on vlan1101 proto udp from any to 239.16.1.1 you see the same traffic on every interface which is set up to multicast is because how pf decides to pass packets. Default state-policy is floating and it means that decision to pass traffic is based on packet's direction and src and dst ip and ports and not on what interface packet leaves (or enters). Normally this is ok and as i understand this approach for example saves memory not to keep information which excact interface is used for passing. But problem arises with multicast traffic as src ja dst addresses and ports are the same. I tried and adding 'keep state (if-bound)' seems to solve the problem. Imre Actually i experimented with tags, something like this .. pass in quick on $if_onelan inet to 239.x.x.x keep state (if-bound) tag MC pass out quick on $if_otherlan keep state (if-bound) tagged MC ...
Re: OpenBSD 4.4 pf+vlan+bridge problem
Key Aavoja schrieb: Hello, Hello, first thing: I do not have any experience with multicast traffic. But what you have build seems very strange to me. First you use vlan to separate the networks an then you put them alltogether with a bridge. I do not see the use of the vlans. Wouldn't it be better to not use the bridge and use (multicast-)routing and pf to solve your problem? As I said, I have no experience with multicast traffic, but that is how I would start digging. guido I have a problem with pf+bridge+vlan (multicast traffic) and I googled a lot, read the manuals and so on - no help. Finally I posted on wrong place :( sorry. Hopefully this time I'm writing to right place. Following setup is made for multicast traffic separation from one lan to multiple vlans. Setup: Two physical interfaces bnx0 bnx1 interfaces bnx0 and bnx1 has vlans: bnx0 vlan1100 bnx1 vlan1101 vlan1102 vlan1103 vlan1104 vlan1105 vlan1106 vlan1107 vlan1108 Bridge setup: bridge0 has all vlans as bridge members (vlan1100, vlan1101 ... vlan1108) PF config: block out on bnx1 all block out on vlan1100 all block out on vlan1101 all block out on vlan1102 all block out on vlan1103 all block out on vlan1104 all block out on vlan1105 all block out on vlan1106 all block out on vlan1107 all block out on vlan1108 all pass out quick on vlan1101 proto udp from any to 239.16.1.1 pass out quick on vlan1102 proto udp from any to 239.16.1.2 pass out quick on vlan1103 proto udp from any to 239.16.1.3 Wishful thinking, what the result should be: All multicast streams are available on vlan1100 and recieved via bnx0/vlan1100. Bridge should stream the multicast packets to what ever vlan - its the place where pf should help. Stream: 239.16.1.1 should be available only on vlan1101, and 239.16.1.2 avialable on vlan1102 and so on. . Real Result: Stream 239.16.1.1 is available on all three vlans: 11101,1102,1103 - same thing happens with other two streams (239.16.1.2, 239.16.1.3) It's really weird what's going on or did I understood something wrong and configuration is not correct? Thank you. -
Re: OpenBSD 4.4 pf+vlan+bridge problem
On 2009-01-20, Guido Tschakert guido.tschak...@src-gmbh.de wrote: first thing: I do not have any experience with multicast traffic. But what you have build seems very strange to me. First you use vlan to separate the networks an then you put them alltogether with a bridge. I do not see the use of the vlans. It can indeed be useful to do this, even without multicast traffic in the equation. You might want to filter traffic between machines in the same subnet, and this is a way you can do it. Key Aavoja schrieb: PF config: block out on bnx1 all block out on vlan1100 all block out on vlan1101 all block out on vlan1102 all block out on vlan1103 all block out on vlan1104 all block out on vlan1105 all block out on vlan1106 all block out on vlan1107 all block out on vlan1108 all pass out quick on vlan1101 proto udp from any to 239.16.1.1 pass out quick on vlan1102 proto udp from any to 239.16.1.2 pass out quick on vlan1103 proto udp from any to 239.16.1.3 Wishful thinking, what the result should be: All multicast streams are available on vlan1100 and recieved via bnx0/vlan1100. Bridge should stream the multicast packets to what ever vlan - its the place where pf should help. Stream: 239.16.1.1 should be available only on vlan1101, and 239.16.1.2 avialable on vlan1102 and so on. . Real Result: Stream 239.16.1.1 is available on all three vlans: 11101,1102,1103 - same thing happens with other two streams (239.16.1.2, 239.16.1.3) It's really weird what's going on or did I understood something wrong and configuration is not correct? you should check the simple things first. - is PF enabled? pfctl -si - is the ruleset loaded correctly? pfctl -sr - does it correctly block ordinary non-multicast traffic between the vlans? if you did indeed include your whole PF config in your email, only that particular multicast traffic should pass between the vlans, everything else should be blocked. you might have already done this, but if you did, you should have mentioned in your email what you checked. with a routed (not bridged) environment, PF is able to control multicast traffic in either direction (I just tried). from my reading of if_bridge.c, on a bridge, pf filtering for multicast frames only happens _inbound_. multicast frames sent _out_ through a bridge are not subject to the outbound PF filter rules. bridge MAC filter rules _are_ applied outbound for multicast frames, I haven't tested but I think that will give you a way you can restrict this traffic.
Re: OpenBSD 4.4 pf+vlan+bridge problem
Quoting Guido Tschakert guido.tschak...@src-gmbh.de: Key Aavoja schrieb: Hello, Hello, first thing: I do not have any experience with multicast traffic. But what you have build seems very strange to me. First you use vlan to separate the networks an then you put them alltogether with a bridge. I do not see the use of the vlans. Its needed because all those streams are already on one vlan, but its really needed to extract address based. Its the best way to put different streams on different vlans (using cisco switch is not a very good idea for this task, because some limitations, but its out of current topic). Wouldn't it be better to not use the bridge and use (multicast-)routing and pf to solve your problem? Multicast routing with dvrmpd is tested with pf, does not work. the same thing happens, if streamX is allowed to pass out on vlanX and streamY is allowed to pass out on vlanY, result is pretty similar: vlanX outputs both streams (streamX, streamY) and the same thing with vlanY. pf is not 100% percent multicast compat.? As I said, I have no experience with multicast traffic, but that is how I would start digging. guido I have a problem with pf+bridge+vlan (multicast traffic) and I googled a lot, read the manuals and so on - no help. Finally I posted on wrong place :( sorry. Hopefully this time I'm writing to right place. Following setup is made for multicast traffic separation from one lan to multiple vlans. Setup: Two physical interfaces bnx0 bnx1 interfaces bnx0 and bnx1 has vlans: bnx0 vlan1100 bnx1 vlan1101 vlan1102 vlan1103 vlan1104 vlan1105 vlan1106 vlan1107 vlan1108 Bridge setup: bridge0 has all vlans as bridge members (vlan1100, vlan1101 ... vlan1108) PF config: block out on bnx1 all block out on vlan1100 all block out on vlan1101 all block out on vlan1102 all block out on vlan1103 all block out on vlan1104 all block out on vlan1105 all block out on vlan1106 all block out on vlan1107 all block out on vlan1108 all pass out quick on vlan1101 proto udp from any to 239.16.1.1 pass out quick on vlan1102 proto udp from any to 239.16.1.2 pass out quick on vlan1103 proto udp from any to 239.16.1.3 Wishful thinking, what the result should be: All multicast streams are available on vlan1100 and recieved via bnx0/vlan1100. Bridge should stream the multicast packets to what ever vlan - its the place where pf should help. Stream: 239.16.1.1 should be available only on vlan1101, and 239.16.1.2 avialable on vlan1102 and so on. . Real Result: Stream 239.16.1.1 is available on all three vlans: 11101,1102,1103 - same thing happens with other two streams (239.16.1.2, 239.16.1.3) It's really weird what's going on or did I understood something wrong and configuration is not correct? Thank you. -
Re: OpenBSD 4.4 pf+vlan+bridge problem
Quoting Stuart Henderson s...@spacehopper.org: On 2009-01-20, Guido Tschakert guido.tschak...@src-gmbh.de wrote: first thing: I do not have any experience with multicast traffic. But what you have build seems very strange to me. First you use vlan to separate the networks an then you put them alltogether with a bridge. I do not see the use of the vlans. It can indeed be useful to do this, even without multicast traffic in the equation. You might want to filter traffic between machines in the same subnet, and this is a way you can do it. Key Aavoja schrieb: PF config: block out on bnx1 all block out on vlan1100 all block out on vlan1101 all block out on vlan1102 all block out on vlan1103 all block out on vlan1104 all block out on vlan1105 all block out on vlan1106 all block out on vlan1107 all block out on vlan1108 all pass out quick on vlan1101 proto udp from any to 239.16.1.1 pass out quick on vlan1102 proto udp from any to 239.16.1.2 pass out quick on vlan1103 proto udp from any to 239.16.1.3 Wishful thinking, what the result should be: All multicast streams are available on vlan1100 and recieved via bnx0/vlan1100. Bridge should stream the multicast packets to what ever vlan - its the place where pf should help. Stream: 239.16.1.1 should be available only on vlan1101, and 239.16.1.2 avialable on vlan1102 and so on. . Real Result: Stream 239.16.1.1 is available on all three vlans: 11101,1102,1103 - same thing happens with other two streams (239.16.1.2, 239.16.1.3) It's really weird what's going on or did I understood something wrong and configuration is not correct? you should check the simple things first. - is PF enabled? pfctl -si PF is enabled, btw removing the last three rules the whole mcast traffic is diabled - for testing I have 10 streams as input but trying to allow only three. - is the ruleset loaded correctly? pfctl -sr yes this command shows that all rules are loaded - does it correctly block ordinary non-multicast traffic between the vlans? if you did indeed include your whole PF config in your email, only that particular multicast traffic should pass between the vlans, everything else should be blocked. I pasted here 100% of pf config, this non-multicast traffic needs to be tested, tomorrow I will do that. you might have already done this, but if you did, you should have mentioned in your email what you checked. with a routed (not bridged) environment, PF is able to control multicast traffic in either direction (I just tried). from my reading of if_bridge.c, on a bridge, pf filtering for multicast frames only happens _inbound_. multicast frames sent _out_ through a bridge are not subject to the outbound PF filter rules. bridge MAC filter rules _are_ applied outbound for multicast frames, I haven't tested but I think that will give you a way you can restrict this traffic.
Re: OpenBSD 4.4 pf+vlan+bridge problem
On 2009-01-20, Key Aavoja k...@neoon.com wrote: Wouldn't it be better to not use the bridge and use (multicast-)routing and pf to solve your problem? Multicast routing with dvrmpd is tested with pf, does not work. the same thing happens, if streamX is allowed to pass out on vlanX and streamY is allowed to pass out on vlanY, result is pretty similar: vlanX outputs both streams (streamX, streamY) and the same thing with vlanY. if you get rid of the bridge and change it for a routed setup with igmpproxy (it's in packages), does that do what you're looking for? pf is not 100% percent multicast compat.? see the last couple of paragraphs of my earlier post about that - fine when it's routed, some limitations as a bridge.
Re: OpenBSD 4.4 pf+vlan+bridge problem
Quoting Stuart Henderson s...@spacehopper.org: On 2009-01-20, Key Aavoja k...@neoon.com wrote: Wouldn't it be better to not use the bridge and use (multicast-)routing and pf to solve your problem? Multicast routing with dvrmpd is tested with pf, does not work. the same thing happens, if streamX is allowed to pass out on vlanX and streamY is allowed to pass out on vlanY, result is pretty similar: vlanX outputs both streams (streamX, streamY) and the same thing with vlanY. if you get rid of the bridge and change it for a routed setup with igmpproxy (it's in packages), does that do what you're looking for? pf is not 100% percent multicast compat.? see the last couple of paragraphs of my earlier post about that - fine when it's routed, some limitations as a bridge. Thanks, I read and now I understand completely. Btw. test with dvrmpd was without a bridge, but pf filtering on out @ vlans had same results as with bridge. Using a igmpproxy in my setup is not a option because equipments expecting a stream are sometimes far away in network topology and cannot be sure, that igmp-join is always received. Anyway for others who are googling multicast bridge topics: I found a workaround. Use Linux 2.6 kernel + vlan + bridge + ebtables. Net setup will be the same, all what you need to add on your own script is: #!/bin/bash #default policy to drop everything (no matter which protocol). ebtables -P FORWARD DROP #flush existing rules. ebtables -F #now the exceptions ebtables -A FORWARD -i eth0.1100 -o eth1.1101 -p IPv4 --ip-dst 239.16.1.1 -j ACCEPT ebtables -A FORWARD -i eth0.1100 -o eth1.1102 -p IPv4 --ip-dst 239.16.1.2 -j ACCEPT ebtables -A FORWARD -i eth0.1100 -o eth1.1103 -p IPv4 --ip-dst 239.16.1.3 -j ACCEPT /etc/init.d/ebtables save echo ebtables: rules updated! Thats all what you need to do! Machine with two broadcom interfaces (not so good as intel) , 2GHz xeon (dual core) has acceptable performance: load: 0.00, cpu:0%, interrupts:eth0=6800; eth1=4300 90Mbit/s is the traffic on eth1 and pkt/s=8000 * This setup is giving a gaurantee, that no SpanningTree and other messages does not travel between interfaces, and vlans are staying still separated Key
OpenBSD 4.4 pf+vlan+bridge problem
Hello, I have a problem with pf+bridge+vlan (multicast traffic) and I googled a lot, read the manuals and so on - no help. Finally I posted on wrong place :( sorry. Hopefully this time I'm writing to right place. Following setup is made for multicast traffic separation from one lan to multiple vlans. Setup: Two physical interfaces bnx0 bnx1 interfaces bnx0 and bnx1 has vlans: bnx0 vlan1100 bnx1 vlan1101 vlan1102 vlan1103 vlan1104 vlan1105 vlan1106 vlan1107 vlan1108 Bridge setup: bridge0 has all vlans as bridge members (vlan1100, vlan1101 ... vlan1108) PF config: block out on bnx1 all block out on vlan1100 all block out on vlan1101 all block out on vlan1102 all block out on vlan1103 all block out on vlan1104 all block out on vlan1105 all block out on vlan1106 all block out on vlan1107 all block out on vlan1108 all pass out quick on vlan1101 proto udp from any to 239.16.1.1 pass out quick on vlan1102 proto udp from any to 239.16.1.2 pass out quick on vlan1103 proto udp from any to 239.16.1.3 Wishful thinking, what the result should be: All multicast streams are available on vlan1100 and recieved via bnx0/vlan1100. Bridge should stream the multicast packets to what ever vlan - its the place where pf should help. Stream: 239.16.1.1 should be available only on vlan1101, and 239.16.1.2 avialable on vlan1102 and so on. . Real Result: Stream 239.16.1.1 is available on all three vlans: 11101,1102,1103 - same thing happens with other two streams (239.16.1.2, 239.16.1.3) It's really weird what's going on or did I understood something wrong and configuration is not correct? Thank you.
pf visible bridge/router
Hi all!, I've been searching lists with regards to building a Visible Bridge/Router with PF on OpenBSD. But most of the material I see are for invisible bridge configs. I wanted to just to a straight Routing/Bridging on my FW's (without the use of NAT) Any comments or experiences shared will be awesomely appreciated. thanks, -B
Re: pf visible bridge/router
It's the same as an invisible bridge except you have IP's on the if's, that's the only diff. Beavis wrote: Hi all!, I've been searching lists with regards to building a Visible Bridge/Router with PF on OpenBSD. But most of the material I see are for invisible bridge configs. I wanted to just to a straight Routing/Bridging on my FW's (without the use of NAT) Any comments or experiences shared will be awesomely appreciated. thanks, -B
Re: PF/ALTQ/Bridge Question
May i ask why you are using a bridge between ISP and OpenBSD firewall?
why not just implement QoS on the firewall if its OpenBSD anyway?
Have you verified ports for your voip? it looks like you are expecting
your outbound voip connection to be connection control=5060 and
media=1-2, i usually dont see that sort of uniformity on
clients behind nat(assumeing your clients are behind nat)
Hope that helps
On 07/11/2007, Michael Siers [EMAIL PROTECTED] wrote:
Hi,
I have a group of static ips and on one of my static ips I am running
an OpenBSD 4.2 firewall with pf using nat and altq. Behind the OpenBSD
firewall I have an asterisk server.
So in order for me to implement QoS, I have set up a non-transparent
bridge between my ISP router and the OpenBSD firewall. Everything is
working fine except I can not get my outgoing VOIP traffic to be placed
onto the correct queue.
Using pftop, I can see that packets are being passed out using the
rules that specify the queue ovoip. But if I look at the queue view
inside pftop, no data was sent out using the queue. The queue ivoip
is being used for incoming traffic. Below are my pf rules.
WANIF=external bridge interface
PUBIF=internal bridge interface (also has assigned static ip)
PRIVIF=internal private network
VOIP=private ip address for my asterisk server
altq on $WANIF hfsc bandwidth 7168Kb queue {iroot}
queue iroot bandwidth 95% priority 0 hfsc {ivoip, idata}
queue ivoip bandwidth 2% priority 5 hfsc(realtime 112Kb)
queue idata bandwidth 98% priority 2 hfsc(default)
altq on $PUBIF hfsc bandwidth 896Kb queue {oroot}
queue oroot bandwidth 95% priority 0 hfsc {ovoip, odata}
queue ovoip bandwidth 15% priority 6 hfsc(realtime 112Kb)
queue odata bandwidth 85% priority 3 hfsc(default)
nat on $PUBIF from $PRIVIF:network to any - $PUBIF:0
block in all
pass out all
pass in on $WANIF from any to $PUBIF:network
pass in on $PUBIF from $PUBIF:network to any
pass in on $PRIVIF
pass in quick on $PUBIF proto tcp from any to any port {5060} queue ivoip
pass in quick on $PUBIF proto udp from any to any port {5060:5063,
1:2} queue ivoip
pass in quick proto tcp from $VOIP to any port {5060} queue ovoip
pass in quick proto udp from $VOIP to any port {5060:5063,
1:2} queue ovoip
Does anyone have any ideas on how I can get this to work? Any
information or examples of pf/altq rules with a bridge would be
greatly appreciated.
Thanks,
Mike Siers
--
-Lawrence
-Student ID 1028219
PF/ALTQ/Bridge Question
Hi,
I have a group of static ips and on one of my static ips I am running
an OpenBSD 4.2 firewall with pf using nat and altq. Behind the OpenBSD
firewall I have an asterisk server.
So in order for me to implement QoS, I have set up a non-transparent
bridge between my ISP router and the OpenBSD firewall. Everything is
working fine except I can not get my outgoing VOIP traffic to be placed
onto the correct queue.
Using pftop, I can see that packets are being passed out using the
rules that specify the queue ovoip. But if I look at the queue view
inside pftop, no data was sent out using the queue. The queue ivoip
is being used for incoming traffic. Below are my pf rules.
WANIF=external bridge interface
PUBIF=internal bridge interface (also has assigned static ip)
PRIVIF=internal private network
VOIP=private ip address for my asterisk server
altq on $WANIF hfsc bandwidth 7168Kb queue {iroot}
queue iroot bandwidth 95% priority 0 hfsc {ivoip, idata}
queue ivoip bandwidth 2% priority 5 hfsc(realtime 112Kb)
queue idata bandwidth 98% priority 2 hfsc(default)
altq on $PUBIF hfsc bandwidth 896Kb queue {oroot}
queue oroot bandwidth 95% priority 0 hfsc {ovoip, odata}
queue ovoip bandwidth 15% priority 6 hfsc(realtime 112Kb)
queue odata bandwidth 85% priority 3 hfsc(default)
nat on $PUBIF from $PRIVIF:network to any - $PUBIF:0
block in all
pass out all
pass in on $WANIF from any to $PUBIF:network
pass in on $PUBIF from $PUBIF:network to any
pass in on $PRIVIF
pass in quick on $PUBIF proto tcp from any to any port {5060} queue ivoip
pass in quick on $PUBIF proto udp from any to any port {5060:5063,
1:2} queue ivoip
pass in quick proto tcp from $VOIP to any port {5060} queue ovoip
pass in quick proto udp from $VOIP to any port {5060:5063,
1:2} queue ovoip
Does anyone have any ideas on how I can get this to work? Any
information or examples of pf/altq rules with a bridge would be
greatly appreciated.
Thanks,
Mike Siers
pf on bridge
All documentation I have seen about configuring pf on a bridge states
to pass in/out all on one interface and filter in/out on the other.
Why not just 'set skip on { lo, $bridge_int_1 }', then filter on
$bridge_int_0?
Luke
Re: pf on bridge
On 2/25/06, Luke Eckley [EMAIL PROTECTED] wrote:
All documentation I have seen about configuring pf on a bridge states
to pass in/out all on one interface and filter in/out on the other.
Why not just 'set skip on { lo, $bridge_int_1 }', then filter on
$bridge_int_0?
Why not filter inbound on both, and pass all policy-based traffic out
unconditionally? That will keep your rules much cleaner.
Here's a quick example:
# Interface definitions
ext_if = bge0
int_if = bge1
# Server definitions
ssh_server = 172.16.30.30
smtp_server = 172.16.30.31
# Default deny
block drop log
# pass local traffic
pass quick on lo inet
# pass tagged traffic out
pass out quick inet tagged FILTERED modulate state
# filter rules for ext_if - int_if
pass in on $ext_if inet proto tcp to $ssh_server port 22 flags S/SA
modulate state tag FILTERED
pass in on $ext_if inet proto tcp to $smtp_server port 25 flags S/SA
modulate state tag FILTERED
# filter rules for int_if - ext_if
pass in on $int_if inet proto tcp to port {80,443} flags S/SA modulate
state tag FILTERED
pass in on $int_if inet proto {tcp,udp} to port 53 flags S/SA modulate
state tag FILTERED
pass in on $int_if inet proto tcp from $smtp_server to port 25 flags
S/SA modulate state tag FILTERED
Experimentation (in a non-production environment) will serve you well.
