Normally our customer radios are set up in router mode, do PPPoE and NAT/DHCP to the customer. However we have one situation were we need to bridge the radio and the PPPoE client will be on a device the customer controls.
So, is it possible on ePMP to set the radio in bridge mode and bock any/all data from the customer interface that isn't PPPoE ?
yes,
Assuming the Sub. unit is in Bridge Mode
Goto Security Tab
Enable L2 Firewalls
Add three rules, & note the order of the rules. The Deny rule MUST BE LAST.
Rule 1
Name: Any name I use PPPOE1
Action: Accept
Interface: LAN
EtherType: 8863
Rule 2
Name: Any name I use PPPOE2
Action: Accept
Interface: LAN
EtherType: 8864
Rule 3
Name: Any Name I use DENY
Action: Deny
Interface: LAN
Notes:- The DENY filter must be last, ie after the Rules 1 & 2 . The interface is LAN
regrds
Anthony
It definitely is, though it's sliiiiightly annoying. You can use the L2 firewall feature of the device, through a template like this one;
{
"template_props": {
"templateName": "ePMP SM Firewall Lite",
"templateDescription": "Just adds the firewall rules",
"device_type": "",
"version": "3.3"
},
"device_props": {
"l2FirewallEnable": "1",
"l2FirewallTable": [
{
"l2FirewallEntryName": "WLAN ARP",
"l2FirewallEntryAction": "1",
"l2FirewallEntryInterface": "1",
"l2FirewallEntryEtherType": "2054"
},
{
"l2FirewallEntryName": "LAN ARP",
"l2FirewallEntryAction": "1",
"l2FirewallEntryInterface": "2",
"l2FirewallEntryEtherType": "2054"
},
{
"l2FirewallEntryName": "PPPoE Discovery",
"l2FirewallEntryAction": "1",
"l2FirewallEntryInterface": "1",
"l2FirewallEntryEtherType": "34915"
},
{
"l2FirewallEntryName": "PPPoE Session",
"l2FirewallEntryAction": "1",
"l2FirewallEntryInterface": "1",
"l2FirewallEntryEtherType": "34916"
},
{
"l2FirewallEntryName": "WLAN DST MGMT",
"l2FirewallEntryAction": "1",
"l2FirewallEntryInterface": "1",
"l2FirewallEntryDstMAC": "${wlan-mac=00:00:00:00:00:00}"
},
{
"l2FirewallEntryName": "WLAN SRC MGMT",
"l2FirewallEntryAction": "1",
"l2FirewallEntryInterface": "1",
"l2FirewallEntrySrcMAC": "${wlan-mac=00:00:00:00:00:00}"
},
{
"l2FirewallEntryName": "LAN DST MGMT",
"l2FirewallEntryAction": "1",
"l2FirewallEntryInterface": "2",
"l2FirewallEntryDstMAC": "${wlan-mac=00:00:00:00:00:00}"
},
{
"l2FirewallEntryName": "LAN SRC MGMT",
"l2FirewallEntryAction": "1",
"l2FirewallEntryInterface": "2",
"l2FirewallEntrySrcMAC": "${wlan-mac=00:00:00:00:00:00}"
},
{
"l2FirewallEntryName": "Deny all other from WLAN",
"l2FirewallEntryAction": "0",
"l2FirewallEntryInterface": "1"
},
{
"l2FirewallEntryName": "Deny all other from LAN",
"l2FirewallEntryAction": "0",
"l2FirewallEntryInterface": "2"
}
]
}
}
This lets you fill in the WLAN MAC (used for management traffic) of the SM to allow you to still access the SM's configuration, while passing ARP and PPPoE traffic. I'm not 100% certain the MAC address based rules are actually required, but in our brief testing without them we lost access to the SM's management. You can pull the LAN MAC from cnMaestro, and typically the WLAN MAC is the LAN MAC incremented by 1 (this is different on Elevate SMs)
It would definitely be nice to just have a switch in options to pass only PPPoE traffic and traffic to/from the management address of the SM, or a cnMaestro macro to pull both the LAN/WLAN MAC addresses.
{%esn} is supposed to pull the LAN MAC, but when I dropped that into the firewall rules it threw an error and wouldn't apply; perhaps a formatting issue, as it's not entirely clear what format the macro returns the MAC in, and there's no similar macro for the WLAN MAC (yet?) anyway, so it's of limited use.. I've taken to dynamically generating .json config files with a script that pulls these variables over SNMP, then pushing the config back over SNMP.
The template above is somewhat draconian as it explicitly blocks any/all traffic on all interfaces that isn't ARP, PPPoE, or traffic headed to/from the SM's management MAC address, but we've found this to be useful for reducing spurious broadcast/multicast traffic.
That appears to be exactly what I needed !
Thanks!