WOW !! WHAT a service & Support 1000 WISP POINTS for you DAN
2014-11-20 1:22 GMT+01:00 Josh Luthman via Af <[email protected]>: > +100 WISP points Dan. Thanks a ton!!! > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Nov 19, 2014 7:09 PM, "Dan Sullivan via Af" <[email protected]> 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]] 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. >> >> >> >> >> >>
