I filter everything at the SM, not the AP. The less work the AP has to
do the better. And the other reason is, like I mentioned with multicast,
if I need to run OSPF over an SM link (which is rare), just disable the
multicast filter at the SM. Stop everything I don't want at the SM so it
doesn't even have to go over the RF link just to be dropped by the AP.
Just a thought, but if you filtered traffic from exiting the AP's
ethernet, then I would assume that inter-SM traffic could still happen.
Yet another reason to stop it upon ingress at the SM's ethernet port.
Could you drop it upon Rx at the AP's RF interface, sure, but why have
the SM send unwanted traffic and waste air time.
Also, the broadcast/multicast uplink rate limiting on the Canopy SM is a
godsend. I don't know if that exists on ePMP since I haven't used any yet.
On 11/19/2014 6:09 PM, Dan Sullivan via Af wrote:
Hi,
Thanks to everyone on the forum for their input.
It was good feedback with regard to the Canopy filter rules, how much
you like them, could these rules be added to ePMP, could specifics be
obtained on the rules, and the use cases around filtering.
First, people were interested in the following Canopy filters and what
their contents were. I have a first pass that may not be exactly
right as this is being researched by the Canopy team. When this is
ready it will be posted somewhere on the Cambium forum. For the
purposes of the issue, let’s assume what I have for the moment is
correct to answer people’s questions:
PPPoE: EtherType 8863 and EtherType 8864.
Bootp Server: Protocol UDP with Port 67 and Protocol UDP with Port 68.
SMB: Protocol TCP with Port 445, Protocol TCP+UDP with Port 137,
Protocol UDP with Port 138, and Protocol TCP with Port 139.
SNMP: Protocol UDP with Port 161 and Protocol TCP+UDP with Port 162.
Multicast: Dest MAC 01:00:5E:00:00:00 with Dest Mask FF:FF:FF:80:00:00
– OR -- Dest IP 224.0.0.0 with Dest Mask 224.0.0.0.
But, people also wanted to block all traffic except for one intended
type. So I will provide the other two filters to enable this:
Bootp Client: Protocol UDP with Port 68.
ARP: EtherType 0806.
Many people asked about having pre-existing rules like Canopy has be
implemented on ePMP. Glad to hear that people like this Canopy
feature. We can add in pre-existing rules, too. I have added this to
our future features database. Right now, I do not have a date for
anyone, but we are aware of your desire for this.
George Skorup also asked for filtering statistics similar to what
exists on Canopy. I have added this to our future features database.
Right now, I do not have a date for anyone, but we are aware of your
desire for this.
You can use the information on the Canopy filters above to set up
equivalent functionality on ePMP as for example I describe in the next
paragraph.
Daniel Gerlach asked about limiting traffic to only PPPoE. Later on
Steve indicated that this should pertain to the WAN. My suggestion
would be to go to the AP, enable Layer 2 Firewall, and allow EtherType
8863 on the LAN as the first rule, allow EtherType 8864 on the LAN as
the second rule, and deny on the LAN as the third rule. This would
allow filtering to be done on the AP preventing non-PPPoE packets from
going over the WLAN and reaching the SM.
*** Please note that I have not specifically tried this out myself to
verify it. ***
Here are some notes on the ePMP firewall logic:
1.Firewall rules are executed in the order that they are listed.
Therefore, if a packet matches more than one rule, it will match first
on the earlier rule and never execute the latter rules.
2.Define your allow rules first to make sure that intended packets
make it through the firewall. Defining an overall deny rule first will
cause bad things to happen.
3.Define your overall deny rule last to make sure that after your
intended allow packets make it through, the remaining unintended
packets do not make it through.
Josh Luthman asked about several filters:
1.Block bootp: On the AP enable Layer 3 Firewall and deny Protocol UDP
with Port 67 on the LAN as the first rule and deny Protocol UDP with
Port 68 on the LAN as the second rule.
2.Block PPPoE: On the AP enable Layer 2 Firewall and deny EtherType
8863 on the LAN as the first rule and deny EtherType 8864 on the LAN
as the second rule.
3.Block SMB: On the AP enable Layer 3 Firewall and deny Protocol TCP
with Port 445 on the LAN as the first rule, deny Protocol TCP+UDP with
Port 137 on the LAN as the second rule, deny Protocol UDP with Port
138 on the LAN as the third rule, and deny Protocol TCP with Port 139
on the LAN as the fourth rule.
*** Please note that I have not specifically tried this out myself to
verify it. ***
George Skorup asked about four filters:
1.Block Bootp: See Josh Luthman filter 1.
2.Block SNMP: On the AP enable Layer 3 Firewall and deny Protocol UDP
with Port 161 on the LAN as the first rule and deny Protocol TCP+UDP
with Port 162 on the LAN as the second rule.
3.Block SMB: See Josh Luthman filter 3.
4.A. Block Multicast: On the AP enable Layer 2 Firewall and deny Dest
MAC 01:00:5E:00:00:00 with Dest Mask FF:FF:FF:80:00:00 on the LAN as
the first rule –OR-- on the AP enable Layer 3 Firewall and deny Dest
IP 224.0.0.0 with Dest Mask 224.0.0.0 on the LAN as the first rule.
*** Please note that I have not specifically tried this out myself to
verify it. ***
Dan
*From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of *George Skorup
(Cyber Broadcasting) via Af
*Sent:* Wednesday, November 19, 2014 11:15 AM
*To:* af@afmug.com
*Subject:* Re: [AFMUG] epmp 1000 only PPPOE Filter
Downside, none. Unless you're doing something with multicast over an
SM link, like maybe OSPF.
A few years ago, we had a bunch of customer routers (might have been
Linksys or Netgear) that were spewing out multicast. And a large L2
segment of the network (which is now broken up) slowed to a crawl. I
think it was IGMP. And SM isolation wouldn't have solved the problem
for the entire network. Multicast filter on all of the Canopy SMs
reduced the violence. But I think this was around the same time we had
some Trango 5580's go stupid. They appeared to be looping traffic, but
not all types, just broadcast and multicast. It was really weird. But
now all that Trango stuff is gone, every last one.
On 11/19/2014 10:09 AM, Ty Featherling via Af wrote:
Is there any downside to dropping all multicast from the
customers? My brain says no but my other end says don't try it
without confirming.
-Ty
On Tue, Nov 18, 2014 at 5:36 PM, George Skorup (Cyber
Broadcasting) via Af <af@afmug.com <mailto:af@afmug.com>> wrote:
We do only bridge mode and DHCP to the customer's equipment. But I
do check the PPPoE filter because it lets me easily see when a
customer's router is configured for PPPoE (Stats > Filter). I also
use the filters for BootP server, SNMP, SMB and multicast. This is
some of the best stuff about Canopy. So I would prefer the ePMP to
work like Canopy, for the most part anyway.
On 11/18/2014 3:13 PM, Matt via Af wrote:
I am Dan Sullivan and I am the software manager for ePMP at
Cambium.
Why do you want to filter PPPoE? Can you explain the use case
more for me.
When our SM is set up as a PPPoE client and is talking to a
PPPoE server, it will only accept traffic from the PPPoE
server over the wireless interface. With this in mind, why do
you need a PPPoE filter for the wireless interface?
One other item, when NAT mode is enabled we can set up a L2
filter for a source MAC and EtherType as indicated below, but
only the source MAC filter will work. There is a warning
message that indicates this when in NAT mode.
I think the desired affect is the same as:
On Canopy 450 SM
"Config / Protocol Filtering"
"Packet Filter Configuration"
Packet Direction: Filter Direction Upstream Checked
Packet Filter Types: Check Everything BUT "PPPoE"
This way the customer router/PC they plug into the ethernet port on
the SM can only successfully send PPPoE traffic onto our network.
