L2TP Quirk

I've been looking forward to arriving at one of the items on my test agenda for a couple of weeks now. The customer would like to see some evidence that enabling LAC functionality in one VRF doesn't inadvertently open up L2TP connectivity in other VRFs. Pretty unlikely, everyone agrees. Two immediate thoughts on this:

1 - I would say it's impossible to *prove* that there are *no* side effects, but we should rule out any obvious clangers such as L2TP connectivity appearing in VRFs where you don't want it.
2 - How could I even prove there's no LAC running? L2TP is UDP based and UDP protocols are a pain like this. If you run a standard, dumb, UDP port scan it will often miss that SNMP running on a device because most security policy templates disable ICMP unreachables, so seeing "no response" to a sent UDP datagram can either mean the port is open or it is closed but no ICMP port unreachable is generated.

You will only prove a UDP port is open if you can solicit a response from the protocol listening behind, which generally means you have to send it something legal in that protocol.

But what could I send, unsolicited, to a LAC and expect it to respond? We all know that LACs connect out to LNS nodes when they have an incoming call to terminate, right?

Well, reading through RFC 2661 (what can I say, I'm a real party boy!) I noticed that section 5.1 about connection establishment shows that either side, LAC or LNS, can initiate the connection by sending an SCCRQ to the other. I suppose in the days of ISDN and modem racks it made sense for outgoing calls but for someone who has only ever used it in the context of DSL that's easily missed.

An SCCRQ is easily built or replayed, and I found that, sure enough, firing one at my LAC solicited a response. OK, the response was a StopCCN (L2TP for "go away") but enough to confirm there is a LAC or an LNS listening.

As expected, trying it against a different VRF where L2TP was not configured didn't solicit any response at all.

I was hoping it would have taken a bit more hacking than that. Maybe I'll try a few other things out, too, but I think this pretty much covers it.

I'd put the code for generating the SCCRQ on here, but it's part of a python script I'm working on to complete the whole handshake and allow sessions to come up. It'll be a while before I get that functionality working but I'll upload the code when it does.

Topics for Future Posts

I have a few things I'd like to post about but not much free time so here's a list of topics I'd like to post about. I can bump things up the list if anyone has an interest in something specific, but I can't promise to do anything quickly.

Here are the "interesting" things I've been doing lately:

• Using scapy to emulate a broken LNS
• Using scapy to emulate a PPPoE subscriber (to prove that IP packets sent before IPCP completes are discarded)
• Using one FreeRADIUS server to authenticate for both the LAC and LNS
• Using FreeRADIUS realms and DEFAULTs to minimise config for a wholesale ISP model
• Creating a bunch of scripts for automating RADIUS CoA randomly throughout a given user base
• Using expect scripts to take router health snapshots & statistics throughout a multi-day stability test
• Configuring a very quick-and-dirty LNS using Cisco hardware
• Configuring Ubuntu as a PPPoE client
• Using scripts to keep a pair of redundant RADIUS servers in sync using SCP
• Using byte references to build Wireshark capture filters for MPLS / PPP encapsulated or 802.1Q tagged frames

OK it hardly makes for good light reading material but it may save a few hours if you need to repeat any of the tasks I've been working on.

I will say, though - I am not a programmer so my code will be scruffy and certainly not written with security in mind. I'm definitely not saying my methods are the best way to achieve anything, but they might get you out of a hole when time is short. In short, anything I suggest on here is for lab use only, and should not be considered suitable for live environments!

What's this all about?

I work for a large networking equipment vendor and at the moment I'm working on a project where I'm responsible for getting a lot of testing completed on broadband technologies. We must be testing some pretty good stuff because for a lot of the cases, the tools required either:

a) don't exist
b) don't work
c) pretend to work but are really doing some other, rubbish, thing
d) don't scale

I'm finally getting to the end of some of the toughest challenges in my working life to date and I thought it would be worth starting a blog to document and share some of the tricks and tools I've used. Most of these are just quick tricks I've used in well known products like FreeRADIUS or Wireshark but many have been absolutely instrumental.

I'm not an expert on most of this stuff, so a lot of what I think is great will be old hat to many. I had to search a while to find most of it, though, so hopefully posting on here will save someone else some time and effort.