Posts from ‘Firewalls’
This is going to be a quick guide on how to setup VPN access on your Cisco router (in my case a Cisco 887 router with VDSL) for remote clients to access into your network and get access to the local resources. There’s a few different ways of doing this however we’re going to use IPSec, mainly because it’s more secure than the alternatives and doesn’t require any third party clients to get it working most of the time.
The guide will assume you’ve already got your LAN (VLAN1) and WAN (PPPoE/A on Dialer1) setup and working, also it assumes you have some Cisco knowledge to actually get the commands applied in the right places as I wont be covering the basics.
So the first part is to enable authentication on the router so that we can create users and have the VPN authenticate against these, you could also use an external radius server however if you’ve only got a few users this is going to be simpler to manage
aaa new-model aaa session-id common aaa authentication login default local aaa authentication login vpn_xauth_ml_1 local aaa authentication login sslvpn local aaa authorization network vpn_group_ml_1 local username vpn_username password 0 vpn_password
Next we need to create an IP pool that we’ll use to give the VPN clients unique IP addresses that appear to be on the LAN (VLAN1), the second step is to ensure that we don’t hand out these same IP’s as part of the normal DHCP process.
ip local pool vpn_client_pool 192.168.0.100 192.168.0.109 ip dhcp excluded-address 192.168.0.100 192.168.0.109
Now normally when a client to connects to our VPN we want it to send all traffic to us for the LAN, there’s usually no point in sending internet or DNS traffic to us if they already have an internet connection, we do that with an access list.
Basically the below is saying ‘any’ of the clients have access to ‘192.168.0.0/24’, you should be able to modify to your specific requirements.
ip access-list extended vpn_resources permit ip 192.168.0.0 0.0.0.255 any !
IPsec uses two different phases for user authentication and traffic encryption, therefore we need to create two different policies. There are more secure settings than what I’m using in the policy below, however you’re realistically going to have more compatibility problems as you tune up these, and the below are still very secure for most installs.
crypto isakmp policy 1 encr 3des authentication pre-share group 2 ! crypto isakmp policy 2 encr 3des hash md5 authentication pre-share group 2 !
Now we need to define the group, the group name and group key that you pick here will need to be also entered on all of the clients that are using the VPN (laptops/iphones etc…), so you want to pick something secure but something that you also don’t mind disclosing to people with VPN access.
In the below configuration my group is ‘oracle’ and we’re using a shared password of ‘qwerty’, you should also notice this is where we’re referencing the ip address pool that these clients will be given, and the access list that defines where they’re allowed to go within our network ‘vpn_resources’
(If you want to redirect the client’s DNS queries you could also do that here with the ‘dns’ setting, however theres usually not much point in that unless you have some kind of intranet.)
crypto isakmp client configuration group oracle key qwerty pool vpn_client_pool acl vpn_resources max-users 10 !
So the above configuration was mostly for Phase 1 (ISAKMP) of the tunnel, really this is concerned with securely authenticating the users and defining how were going to configure them on the network once they’re connected.
Naturally that brings us onto Phase 2 (IPSec), which is how the already authenticated users are going to securely encrypt there traffic between the router and client. First we’ll setup a transform set and bind that to an IPSec profile
crypto ipsec transform-set vpn_transform esp-3des esp-sha-hmac ! crypto ipsec profile vpn_profile set transform-set vpn_transform !
Now we need somewhere on the router that clients can actually bind there internal IP to, for example the ip route and ARP table on the router needs to know where to send that traffic, this is a ‘virtual-template’. The configuration is simply saying our virtual-template2 is part of the IPSec profile we just created and is on the VLAN1 internal network.
interface Virtual-Template2 type tunnel ip unnumbered Vlan1 tunnel mode ipsec ipv4 tunnel protection ipsec profile vpn_profile !
Now the last part should be to glue our VPN group, how we want to authenticate users and virtual template configuration together using the ISAKMP profile.
crypto isakmp profile vpn_ike_profile match identity group oracle client authentication list vpn_xauth_ml_1 isakmp authorization list vpn_group_ml_1 client configuration address respond virtual-template 2 !
The final step is to go over to one of your clients and actually try the VPN connection, below are the five bits of information that these clients will require a minimum, most will dynamically pick up the rest of the required information.
Clients like an iPhone (shown at the right) have a built in client, however if yours doesn’t go over to the cisco website and download the ‘Cisco VPN Client’, it’s currently available for most operating systems like Windows, Linux, OSX and Solaris.
- Public IP or DNS Name – vDSL Dialer1 Public IP
- Group Name – oracle
- Group Pass – qwerty
- User – vpn_username
- Pass – vpn_password
Just under a year ago my employer started off a network refresh program on one of our internal core networks, we’re a type of ISP and this network was our main management core, so all the fairly important traffic goes over here like billing stats, element management traffic (Telnet, SSH and RDP), alarms (Syslog, Corba, SNMP), plus the management traffic from NMS systems communicating with their respective network elements for user service provisioning.
As we’re a service provider the management core is actually very dynamic, because we’re constantly upgrading the network capacity, hardware and features while also normally decommissioning the legacy equipment. As someone working on these projects you often find yourself troubleshooting the core management connectivity more than customer services, good for the customers, but a pain when you real troubleshooting equipment isn’t targeted for this network and is invested in the revenue generating networks.
The original design
The topology was fairly simple about a year ago, each site generally had a multiple of two switches (Cisco Layer 2) to provide local element access into the network with resiliency, then two core firewalls also operating in layer 2 mode, finally there were two Core MPLS routers which connected all sites together via a VPRN/VRF Layer 3 routed service, and these were the Layer 3 gateway for all the element’s/VLAN’s at that site.
Our future plan
As goes with most network upgrades we all sat down and decided over a cup (or two) of coffee what we wanted to get out of this network refresh, management set aside a decent budget for the work, but there wasn’t going to be any drastic changes or upgrades.
Access – The access layer is fairly simple and that’s the way we wanted it to stay, the older switches got replaced to make all the site’s capable of gigabit access, and all the configuration went through an intensive cleanup exercise to get rid of redundant configuration, plus a tighten up of access security and a general sanity check (such as ensuring all the switches are running the same version of spanning tree! no names to be mentioned).
Firewalls – When looking at firewalls there was a general decision to push these up the OSI stack to layer 3, mainly because the MPLS core configuration was getting quite busy with sub interfaces, with this change we also wanted some kind of routing protocol into the core to keep everything fairly dynamic, please no more static routes!
Vendor selection started off tricky but there was a clear winner in the end; historically we were always using Cisco PIX/ASA’s however this time we looked at Palo Alto mainly for the added security features, a lot of the elements on this network run proprietary operating systems where you can’t install any third party software, so having a firewall that could perform anti virus and spot threats on the network (like brute force detection) was very desirable, and when the costing/performance turned out to be within ~4% of the Cisco alternative we couldn’t really say no.
Core – As already mentioned the main change here was removing all of the access interfaces from the configuration, and setting up a routing adjacency (OSPF) with the firewall which was now hosting all of the local gateway addresses for each VLAN. There we’re no changes to the hardware/vendor at this layer as there were no real requirements.
The unexpected benefit
The original plan was fairly simple, to keep the network in support by means of hardware upgrades and cleanup the design slightly by moving routing down one step to the firewalls, at the vendor selection phase we also realised that our security could be greatly improved by going with the Palo Alto firewalls.
However the biggest advantage by far has been the logs that these firewalls create and push back to their management server (Panorama).
By design the firewall will create a start and end log for every session that passes through the firewall, with this you get all of the basic information like IP addresses, timestamps, ports. However you also get more information like URL logging, accurate application identification, packet and byte counts for both Rx and Tx. Plus unlike pushing your logs to a syslog server the management server has really good reporting and searching functionality built in.
The network engineers have fallen in-love with these firewalls purely because of the logs; for example say you have a server (10.1.1.1) at Site A that’s having problems communicating with a server (192.168.2.2) at Site B, in our design we know this traffic flow will pass a minimum of two firewalls (one at the edge of each site). So you simply log onto the firewall management server and search for related sessions “ip.addr in 10.1.1.1 and ip.addr 192.168.2.2”, then as quick as a google search (we’ll may be a few seconds slower) you get a detailed list of all the traffic flows between them two addresses.
In the above example it was fairly simple to see that traffic made it all the way through our core network to the other side, then back into the MPLS core however it never hit the next firewall in the path (proven by a lack of Rx traffic on that first firewall), a quick look at the MPLS core found some old static routes that needed to be fixed, and 3 minuets later we’re back in action, no need for pings, trace routes, packet captures etc…!
Security that works
As mentioned a big initial driver for using these Palo Alto firewalls was the extra security, fortunately when we turned them on we didn’t find a raft of security threats already in the network, in-fact the only threats we really see are people (from the internet and normally in China) trying to breach our DMZ where one of these firewall pair’s sits.
We did once get a SSH brute force alarm from the internal network which the firewalls instantly managed to filter out, however a quick search found that it was from one of our employee laptops (VPN Client), a phone call found out that he was playing around with a python script that logged into one of our core routers to process the configuration for a up and coming network migration, however the wrong credentials in the script and some not so great coding (causing a login loop) triggered a brute force alarm on the firewalls.
It changed us!
We’re finding network engineers are actually preferring to put in firewalls now instead of “simple routers” because of the extra visibility that you can leverage from the network logs, and the security capabilities are blowing our customers minds when you can track security breaches down in a matter of seconds.
As always, comments are welcomed and appreciated!