Ethernet filtering fun in hexa with D-Link DES-3250

Most network admins in education know that the source of the most evil is the dormitory. Mostly ignorance with just a touch of malice for the flavor. Rogue DHCP servers, IPv6 router advertisements, IP collisions and the occasional ARP spoofing.

The D-Link DES-3250 series is our choice of switch for our dormitory, as it's cheap and fairly reliable. It can't perform proper DHCP snooping, dymanic-ARP-inspection or even the ARP protection the DES-3526 can, but it can do some filtering, based on IP, MAC or raw ethernet packets.

Credits for the first two go to Gavin McCullagh, not me.

You can filter DHCP replies easily:


create access_profile ip udp src_port_mask 0xFFFF port 1-48 profile_id 1 
config access_profile profile_id 1 add access_id 1 ip udp src_port 67 deny 

Now this one is a thing of beauty: filtering IPv6 Router advertisements:


create access_profile packet_content_mask offset_0-15  0x0  0x0  0x0  0xFFFF0000 offset_16-31  0x0  0xFF000000  0x0  0x0 offset_48-63  0x0  0xFF00  0x0  0x0 port 1-48 profile_id 2 
config access_profile profile_id 2 add access_id 1 packet_content offset_0-15  0x0  0x0  0x0  0x86DD0000 offset_16-31  0x0  0x3A000000  0x0  0x0 offset_48-63  0x0  0x8600  0x0  0x0 deny 

IPv6 uses ethertype 0x86dd, and the type for RA in ICMPv6 is 0x86

Yesterday I had 4 TP-Link APs configured as 192.168.1.254. This wouldn't be a big issue normally, but these ones were dead-set on sending gratuitous ARPs against each other at speeds of 10Mpps...
The DES-3250 has broadcast control, which was set at 8pps, but something went wrong, as the switches still forwarded around 4kpps of ARPs on all ports.
So next up is IPv4 ARP filtering for anything with the source 192.168.0.0/16:


create access_profile packet_content_mask offset_0-15  0x0  0x0  0x0  0xFFFF0000 offset_16-31  0x0  0x0  0x0  0xFFFF0000 port 1-48 profile_id 3 
config access_profile profile_id 3 add access_id 1 packet_content offset_0-15  0x0  0x0  0x0  0x08060000 offset_16-31  0x0  0x0  0x0  0xC0A80000 deny 

The ethertype for ARP is 0x8060, and 192.168 is 0xc0a8.

ARP spoofing of the gateway is not that popular on this subnet, but next time it happens, I'll do an entry with that.

Edit: 19/02/2013 - fixed ethertype value in ARP filter

3Com 4050 and D-Link DGS-3324SR spanning tree native vlan

My new place uses a 3Com 4050 as a layer2 core/distribution switch. It's linked to DES-3526, DGS-3324SR and DGS-3100 switches. Protocol of choice is RSTP. Without native/untagged vlan on the links, the following happens:

• 3Com 4050 - DES-3526 - RSTP works okay
• 3Com 4050 - DGS-3100 - RSTP breaks, needs vlan1 untagged
• 3Com 4050 - DGS-3224SR - RSTP breaks, needs vlan1 untagged
• 3Com 4050 - DES-3052P - RSTP breaks, needs vlan1 untagged
• DGS-3224SR - DES3250 - RSTP works okay
• DES-3526 - DES-3052P - RSTP breaks, needs vlan1 untagged
• DGS-3324SR - 3Com 4400 - RSTP works okay

Bottom line: you've gotta love standard implementations of STP...

Alive N Kickin'

In case anybody wonders, I'm still active.
In the past 6 months I changed employment and countries, so it was a bit hectic.

My new place primarily uses Fortigate, Vyatta, D-Link and old 3Com gear, so expect less Cisco for a while. HP will be on the plate as I'm going for the ASE and MASE.
On a related note, I'm Brocade BCNE and BCNP since July, thanks to the BNCE/P 2012 beta program.

So for the time being, stay tuned for D-Link and 3Com stuff.

HP Procurve LLDP-MED and voice vlan configuration FAQ

These are quotations from the Software release notes and config guides, but maybe they'll make your life easier.

ProCurve does not recommend configuring a voice VLAN to accept jumbo packets. Voice VLAN packets are typically small, and allowing a voice VLAN to accept jumbo packet traffic can degrade the voice transmission performance.

Beginning with Release H.08.89, LLDP-MED is supported on ProCurve Series 2600 switches.

VLAN Operating Rules

These rules affect advertisements of VLANs in network policy TLVs:

• The VLAN ID TLV subelement applies only to a VLAN configured for voice operation: vlan < vid > voice
• If there are multiple voice VLANs configured on a port, LLDP-MED advertises the voice VLAN having the lowest VID.
• The voice VLAN port membership configured on the switch can be tagged or untagged. However, if the LLDP-MED endpoint expects a tagged membership when the switch port is configured for untagged, or the reverse, then a configuration mismatch results. (Typically, the endpoint expects the switch port to have a tagged voice VLAN membership.)
• If a given port does not belong to a voice VLAN, then the switch does not advertise the VLAN ID TLV through this port.

The QoS and voice VLAN policy elements can be statically configured with the following CLI

commands:

vlan < vid > voice

vlan < vid > < tagged | untagged > < port-list >

int < port-list > qos priority < 0 - 7 >

vlan < vid > qos dscp < codepoint >

Minimum software versions for LLDP-MED.

Source: HP ProCurve LAN products software feature matrix

LLDP-MED (Media Endpoint Discovery) H.08.89 R.11.04 R.11.04 T.11.xx W.14.03 L.10.02  K.14.xx K.11.1x K.14.xx E.10.02 H.07.57 K.14.03 K.14.xx K.12.31

Bridged OpenVPN server on VMware ESXi host

After migrating our virtual firewall from a XenSource to an ESXi server, our bridged OpenVPN server stopped working: users could ping the server, but nothing else.
Since we were talking about Vista clients, we started with the usual suspects: reboot, reinstall TAP driver, reboot. No joy, so I had to start to actually think.

Turns out ESXi vSwitches are not in promiscuous mode by default. You can turn it on like this:
http://petermolnar.eu/linux-tech-coding/vmware-esxi-and-promiscuous-mode/