I proposed auto fill rules to carry over that but I like having a powerful firewall...
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Nov 20, 2014 5:54 PM, "Gino Villarini via Af" <[email protected]> wrote: > Why not use the checkboxes as in PMP ? > > Gino A. Villarini > @gvillarini > > > > On Nov 20, 2014, at 6:37 PM, Dan Sullivan via Af <[email protected]> wrote: > > I received some additional SMB port information from Aaron Schneider of > the Canopy team. > > > > SMB: Protocol TCP with ports 137, 138, 139, 445, 2869, 5357, 5358. > Protocol UDP with ports 137, 138, 139, 445, 3702, 1900. > > > > George, > > > > Yes, filtering at the SM is a good idea. My examples were assuming DL > traffic to protect the RF bandwidth. > > > > You can do the same thing at the SM as I showed at the AP as long as the > SM is running in bridge mode. For DL traffic remember to specify WLAN > instead of LAN (i.e. AP LAN is for DL and WLAN is for UL, SM WLAN is for DL > and LAN is for UL). > > > > I agree with you on the AP performance observation. Reducing the load on > the AP as opposed to the SM makes sense. > > > > If your multicast is DL, then you may want to filter at the AP so that it > does not consume your RF. But, if your multicast is UL like you indicate, > this makes much more sense. > > > > Good news. We have Broadcast rate limiting both in the UL and the DL. It > was added in release 2.2. Go to Configuration -> Network -> > Broadcast/Multicast Shaping. Set Broadcast Traffic Limit to “Enabled”. > Then you set Broadcast Packet Rate which is in PPS (Packets Per Second). > The valid range is 100 – 16000. > > > > Dan > > > > > > *From:* Af [mailto:[email protected] <[email protected]>] *On > Behalf Of *George Skorup (Cyber Broadcasting) via Af > *Sent:* Thursday, November 20, 2014 10:04 AM > *To:* [email protected] > *Subject:* Re: [AFMUG] epmp 1000 only PPPOE Filter > > > > 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:[email protected] <[email protected]>] *On > Behalf Of *George Skorup (Cyber Broadcasting) via Af > *Sent:* Wednesday, November 19, 2014 11:15 AM > *To:* [email protected] > *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 > <[email protected]> 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. > > > > > > > > > >
