Monday, 18 February 2013

Not So Pointless

Well, despite it all - despite the years of neglect and idle tip-tapping at keyboards - despite the extraordinary unlikeliness of it actually occuring - I have actually signed up to run the Aviemore 1/2 marathon.  Let that information sink in for a while, you are as shocked as I am.


JustGiving - Sponsor me now!

Testing Cisco 802.1X Authentication with VMWare & GNS3

Yet another snappy blog title. I had reason recently to test 802.1X interface authentication using a GNS3 emulated Cisco 3725 and Freeradius, so here it is, delightfully pointless and true to the spirit of Pointless Posts; I did this merely as I wanted to see how it worked. Creating the topology, as ever, is almost as much fun as actually making it work: I have used a VMWare virtual adapter to get the 802.1x compatibility; the virtual Cisco router acts as the authenticator joining the vmware adapter to the physical network. This is NOT very reliable on a wireless adapter, but it proves the point.

First of all I created a VMWare virtual adpater which we were going to use for 802.1X authentication.  See the below screenshots.

VMWare Virtual Adpater Settings

This is connected to a Cisco 3725 running virtually on GNS3. The other interface of this connects to wireless adapater, thus can connect to the radius:



 The Cisco config itself is really easy :
hostname Cisco3725
aaa new-model
aaa authentication dot1x default group radius
!
dot1x system-auth-control
!
##this interface connects to LAN of radius server
interface FastEthernet0/0
 ip address 192.168.1.10 255.255.255.0
 duplex auto
 speed auto
!
##this interface connects to client
interface FastEthernet0/1
 no ip address
 duplex auto
 speed auto
 dot1x pae authenticator
 dot1x port-control auto
!
radius-server host 192.168.1.74 auth-port 1812 acct-port 1813 key testing123
Once the interfaces can see each other it asks for authentication details:

Network Authentication dialogue appears

However there was an initial failure, so followed the debug:
[suffix] No '@' in User-Name = "nicholas", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] EAP packet type response id 3 length 6
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
[files] users: Matched entry nicholas at line 205
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING: Auth-Type already set.  Not setting to PAP
++[pap] returns noop
Found Auth-Type = EAP
# Executing group from file /usr/local/etc/raddb/sites-enabled/default
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP NAK
[eap] NAK asked for unsupported type PEAP
[eap] No common EAP types found.
[eap] Failed in EAP select
++[eap] returns invalid
Failed to authenticate the user.
        expand: Bad! -> Bad!
Login incorrect: [nicholas/] (from client 192.168.1.10 port 0 cli 0050.56c0.0001) Bad!
Using Post-Auth-Type Reject
No common EAP type seemed to be the issue. This was caused by not compiling Freeradius with OpenSSL libraries so PEAP/TLS requirements were actually ignored in eap.conf. PEAP needs TLS needs OpenSSL. It was required then to install Openssl then recompile Freeradius from source. This was done and when run as root a certificate generated – if its not then there is your alarm bell – make sure to get the right key in eap.conf to match the “whatever” in server.crt (I did not first time…!) Eap.conf needs a few minor changes to make it work:
Eap {
default_eap_type = peap
}
Check TLS configuration too:
       tls {
                        #
                        #  These is used to simplify later configurations.
                        #
                        certdir = /etc/raddb/certs
                        cadir = /etc/raddb/certs

                        private_key_password = whatever
                        private_key_file = /etc/raddb/certs/server.pem
Finally it all works, the windows adaptor authenticates using mschapv2 through PEAP on the radius through the Cisco:

Successful authentication,

Sunday, 17 February 2013

How to Configure PPP Sessions for MPLS VPNs

Sometimes you have a problem which is relatively complicated however you don't have the scope or time to solve it. This is just such a problem which has been bugging me for a long time, simmering away since a job almost a year old: how do you get PPP sessions such as DSL subscribers into a private MPLS VPN? As it was never in the remit at the time I never solved it, despite that it stayed in the back of my mind. One rainy day I decided to get rid of it and solve the problem with a pleasant GNS3 lab, happy in the knowledge it was fairly pointless to do so. The solution, as ever, was satisfyingly simple: radius attributes. [And when I say, "solution", I mean, "my solution" - I am certain there are other methods which I would love to hear of.]

In this topology I've created an MPLS framework with one Customer VPN. A radius server was implemented using a VMWare running Freeradius connected via a dedicated VMware virtual network. An LNS router has been configured to terminate PPP sessions by using the Radius server for authentication, and a Cisco 2600 is used as the PPP client. It goes without saying none of the below is of production quality, it is rough-and-ready lab to prove the point.


Ok so the PPP client is relatively straight-forward. The router PPPoEClient is desired to be in a VPN with CustA1 router. Both these routers have default routes for simplicity with BGP distributing VPN routes at the PE.
interface Dialer1
ip address negotiated
ip mtu 1492
ip nat outside
encapsulation ppp
no ip mroute-cache
dialer pool 1
ppp authentication chap pap callin
ppp chap hostname nicholas
ppp chap password 0 nicholas
ppp pap sent-username nicholas password 0 nicholas
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
pppoe enable
pppoe-client dial-pool-number 1
So far so good. Next in the chain is the LNS router. Well, ahem, you might expect it be called an LNS in a production environment, however we're not actually terminating L2TP tunnels in this lab. I mean, come on. I am having a bit of brain-freeze as to what this should actually be called, if I remember I will come back to it.

Anyway, lets look at the problem. In the project environment all PPP subscribers will be terminating their PPP sessions in a common VRF due to whatever the virtual-template has decided for them. In my lab environment it doesn't really matter if the PPP subscribers mix with the global routing table, so to save time I haven't given the virtual-template any VRF context:
interface FastEthernet0/1
no ip address
duplex auto
speed auto
pppoe enable group global
!
interface Virtual-Template2
mtu 1472
ip unnumbered Loopback0
no ip redirects
ip tcp adjust-mss 1452
no peer default ip address
ppp authentication pap chap
ppp direction callin
But this particular subscriber has paid for an MPLS VPN so we require them to authenticate their session on the Radius and for routing appear in a private VRF, which I have cryptically called, "vpn1". Here is a selection of MPLS configuration for the lab:
ip vrf vpn1
rd 65001:1
vpn id 1:1
route-target export 1:1
route-target import 1:1
!
router bgp 65000
no synchronization
bgp log-neighbor-changes
redistribute connected 
neighbor mpls peer-group
neighbor mpls remote-as 65000
neighbor mpls update-source Loopback0
neighbor 10.0.0.1 peer-group mpls
neighbor 10.0.0.2 peer-group mpls
neighbor 10.0.0.3 peer-group mpls
neighbor 10.0.0.4 peer-group mpls
no auto-summary
!
address-family vpnv4
neighbor mpls send-community both
neighbor 10.0.0.1 activate
neighbor 10.0.0.2 activate
neighbor 10.0.0.3 activate
neighbor 10.0.0.4 activate
exit-address-family
!
address-family ipv4 vrf vpn1
redistribute connected
no synchronization
network 172.16.0.0
network 172.30.3.0 mask 255.255.255.0
exit-address-family
The LNS also has a loopback in the private VRF, but why, what is it for?
interface Loopback5
ip vrf forwarding vpn1
ip address 172.16.6.1 255.255.255.255
We will find out soon. So all this config is great, but it doesn't work, the customer will appear in the global routing table. The answer to my pondering was happily simple: radius. So first it might be nice just to see the users file in Freeradius, thats the kind of useful stuff people come to blogs for:
nicholas Cleartext-Password := "nicholas"
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 172.16.3.33,
Framed-IP-Netmask = 255.255.255.255,
Framed-Routing = Broadcast-Listen,
Framed-Compression = Van-Jacobsen-TCP-IP,
Cisco-AVPair="lcp:interface-config#1=ip vrf forwarding vpn1",
Cisco-AVPair+="lcp:interface-config#2=ip unnumbered loopback 5"
The spoiler is the Cisco-AVPair config. You can probably leave now. No, really, you want to stay? Wow. Ok. For those staying, the LNS radius config looks like this (Please note the 192.168.1.0/24 subnet connecting the radius and LNS is not to be confused with the VPN 192.168.1.0/30 subnet - which I dont think you know about anyway, well, its between CustA1 and MPLS1, so you know now):
aaa new-model
!
aaa authentication ppp default group radius
aaa authorization network default group radius local 
aaa accounting exec default
 action-type start-stop
 group radius
!
ip radius source-interface FastEthernet0/0 
!
radius-server host 192.168.1.74 auth-port 1645 acct-port 1646 non-standard key nicholas
And so to the solution. I am using Freeradius, it is familiar and easy to manage. The server itself is fairly simple to set-up. Using a wireless adapter to bridge the radius and LNS is a frustrating process, you can use a loopback and layer3 bridge however if you actually dont need to see the network on your LAN - which we all have to admit is kind of fun - then just connect both the vmware and GNS to a vmware host-only network.



And now let us behold the successful PPP negotiation (takes a wee while to debug so it does):


Now we can see the VPN routes on one of the MPLS switches:


With the critical AV-Pairs passing the virtual-template the required details the virtual-access interface is the right VRF. On the working model it is interesting to see how IOS builds the configuration with your radius values.  "Derived configuration", that is a nice touch rarely seen I would suspect :-)


Ok enough, finally can one side ping the other?


Great, so finally I solved my simple problem.  I hope this has been informative and I'd like to thank you for reading.  [Dear CBT, that's not trademarked is it??]