shmoocon (4) labs (2?)

Besides my photos, there’ll probably be photos from pals like Alex, Andy, Ken and Luiz. Good times were had, I’ve been out drinking to celebrate being home, but a few quick notes.

If you use broadcast/multicast storm protection on cisco switches, make sure the other network gear supports it or make sure you don’t use it on trunk links. ick.

Don’t use any cisco protocols that run over LLDP (CDP, VTP, DTP, etc). Enno and Daniel in their learning of fuzzing found that these protocols generally have crappy implementations. Love live the germans btw.

Bring a router/firewall with wireless preconfigured, otherwise you delay the non-network groups from making progress while you configure the network.

Check last years configuration for monitor ports.

Aruba gear used as a switch is not ideal, like it only supports one span/monitor port.

Monowall sucks for not having a shell.

Pfsense doesn’t support vlan tagging on some soekris gear (5501) and thus sucks.

When you have security vendors doing vulnerability scanning, make sure your firewall has a huge ( > 50,000) state table.

Due to hardware/cabling issues, having multiple dns/dhcp servers is ideal.

A /24 is far too small of an address space for a security conference. Especially if someone configures it to only serve 100 address via DHCP.

Don’t use vlans over 1000, especially on cisco gear. it’s confusing and not necessary. if you do, don’t use 1000-1004 or so, and pay a keen attention to spanning tree (‘show int trunk’ and the likes).

Sometimes gear has to have a vlan configured before it will trunk it (see above command)

4 thoughts on “shmoocon (4) labs (2?)

  1. Chris Buechler

    VLAN tagging support for vr(4) was added to pfSense a few months back. If you’re using RC4 it should definitely work.

    I don’t have any Soekris 5501 hardware, but it works for PC Engines ALIX boards which have the same vr(4) chipset.

    Feel free to email me ( with what you were seeing, I’m curious why it wasn’t working for you.


  2. Steve

    Or, in lieu of allowing for a massive state table, see if the security scanner supports VLANs, and bypass the firewall entirely by connecting the box to a trunk port.

    It’s really funny that it took until Sunday morning to work that one out.

  3. KC


    The vlan tagging support for vr worked flawlessly. What didn’t work was frames that exceeded an MTU of 1500 bytes. Instead of being fragmented they were dropped entirely. This was confirmed through multiple tests, and also kernel messages from the driver.

  4. btm


    Yeah, but we should have to customize the network for the security gear. The funny part is that gear that’s supposed to detect vulnerabilities was causing one.

    It’s pretty interesting that there were so many stacked problems, thus making it difficult to work out. Worth thinking about some more.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.