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 !
OSX Cisco VPN Client
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 !
iPhone Example Confiig
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
I’ve recently been setting up a new customer network and they had some fairly strange requirements, where most of our customers are fairly adverse to any kind of downtime this customer required a weekly reboot of their equipment out of hours, even on the Core networking equipment.
For the Cisco routers this was fairly easy to setup, first you need to create a kron (basically like a Linux Cron) job, this just defines what you want to do, the when is configured later on.
So we’re going to create a policy called ‘reloadrouter’ and it’s going to run the ‘cli’ based command ‘reload’, nice and simple:
Auto Reload/Reboot
kron policy-list reloadrouter cli reload !
Now that we have a policy we need to set this to run, basically we define an occurrence for the policy, then a time and how often we want this to reoccur in the future.
kron occurrence reloadrouter at 4:00 recurring policy-list reloadrouter !
You can do a load of other cool things with kron for example here are some other policies.
Auto Save Config
Forgetting to save the configuration, save an embarrassing reload!
kron policy-list daily-save-config cli write ! kron occurrence daily-save-config at 4:00 recurring policy-list daily-save-config !
Remove debug
People keep leaving debug running on the routers, auto turn it off!
kron policy-list daily-un-debug cli undeb all ! kron occurrence daily-un-debug at 1:00 recurring policy-list daily-un-debug !
TFTP Backup
Want to do a quick backup of the startup configuration to a TFTP server?
kron policy-list config-backup cli show startup-config | redirect tftp://10.1.1.1/bkup.cfg ! kron occurrence config-backup at 1:00 recurring policy-list config-backup !
One thing; please don’t forget the command is only as good as your time keeping, so NTP is always wise with this kind of automation 
After spending quite a bit of time getting my Cisco VDSL router working with PPPoE I though others might benefit from an example configuration, please read through and tune the configuration to match your requirements.
Basically this will setup the vDSL connection and obtain an IP address from your ISP using PPPoE CHAP authentication, the 192.168.0.0/24 range will be used on the inside network and DHCP will handout IP’s within the range 192.168.0.6-99/24, the router will take the address 192.168.0.1 and perform PAT based NAT on any outbound traffic.
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
service internal
!
hostname HOME-GW-1
!
boot-start-marker
boot-end-marker
!
!
logging buffered 4096
enable secret {PASSWORD-GOES-HERE}
enable password {PASSWORD-GOES-HERE}
!
aaa new-model
!
!
aaa authentication login default local
!
!
!
!
!
aaa session-id common
memory-size iomem 10
clock timezone gmt 0 0
clock summer-time BST recurring last Sun Mar 2:00 last Sun Oct 3:00
crypto pki token default removal timeout 0
!
!
no ip source-route
!
!
!
ip dhcp excluded-address 192.168.0.0 192.168.0.5
ip dhcp excluded-address 192.168.0.100 192.168.0.255
!
ip dhcp pool 10
import all
network 192.168.0.0 255.255.255.0
! Change to your ISP DNS
dns-server 8.8.8.8 4.2.2.2
default-router 192.168.0.1
!
!
ip cef
! Change to your ISP DNS
ip name-server 8.8.8.8
ip name-server 4.2.2.2
ip inspect WAAS flush-timeout 10
ipv6 cef
!
!
!
archive
log config
logging enable
logging size 500
hidekeys
username {username} secret {password}
!
!
!
!
controller VDSL 0
operating mode vdsl2
modem customUKAnnexM
modem customUKAnnexA
modem UKfeature
!
ip ssh version 2
!
!
!
!
!
!
bba-group pppoe global
!
!
interface Ethernet0
no ip address
pppoe-client dial-pool-number 1
!
interface ATM0
no ip address
shutdown
no atm ilmi-keepalive
!
interface FastEthernet0
description Link-to-Dist-Switch
no ip address
duplex full
speed 100
!
interface FastEthernet1
no ip address
!
interface FastEthernet2
no ip address
!
interface FastEthernet3
no ip address
!
interface Vlan1
ip address 192.168.0.1 255.255.255.0
ip nat inside
no ip virtual-reassembly in
ip tcp adjust-mss 1452
!
interface Dialer1
description vDSL
mtu 1492
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
no ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer idle-timeout 0
dialer-group 1
ppp authentication chap pap callin
ppp chap hostname {ISP-USERNAME-HERE}
ppp chap password 0 {ISP-PASSWORD-HERE}
ppp pap sent-username {ISP-USERNAME-HERE} password 0 {ISP-PASSWORD-HERE}
ppp ipcp dns request accept
ppp ipcp route default
ppp ipcp address accept
no cdp enable
!
no ip forward-protocol nd
no ip http server
no ip http secure-server
!
ip dns server
ip nat inside source list 10 interface Dialer1 overload
!
access-list 10 permit 192.168.0.0 0.0.0.255
access-list 10 remark nat-pool
access-list 23 permit 192.168.0.0 0.0.0.255
access-list 23 remark vty
access-list 23 deny any log
dialer-list 1 protocol ip permit
!
!
!
!
!
!
!
ipv6 access-list ipv6_deny
deny ipv6 any any
!
ipv6 access-list V6-FILTER
permit icmp any any
deny ipv6 any any log
banner login ^CC
THIS IS A PRIVATE SYSTEM. UNAUTHORISED ACCESS IS NOT
PERMITTED AND OFFENDERS ARE LIABLE TO PROSECUTION.
YOUR IP HAS BEEN LOGGED AND AN ALERT GENERATED
^C
!
line con 0
logging synchronous
line aux 0
line vty 0 4
access-class 23 in
ipv6 access-class ipv6_deny in
transport input telnet
escape-character 3
!
scheduler max-task-time 5000
ntp server {YOUR-NTP-Server}
end
Unless you’ve been under a rock for the last few days you’ve probably heard about the new Bash exploit (CVE-2014-6
Here’s a few simple commands to get your CentOS servers patched, please for your sake do this ASAP.
# Check if vulnerable
env x='() { :;}; echo Vulnerable system' bash -c "echo Testing..."
Vulnerable system
Testing...
#
# If you need to access the web via a proxy, add that here. nano ~/.bash_profile export http_proxy=http://192.168.1.123:3128
# Apply the patch yum update bash -y
# Remove proxy (if used nano ~/.bash_profile # export http_proxy=http://192.168.1.123:3128
# Check if vulnerable
env x='() { :;}; echo Vulnerable system' bash -c "echo Testing..."
Testing...
#
Any problems or questions, please leave a comment.
The Problem
After the bash exploit ‘shellshock’ was released a few days ago I’ve been going around my servers and applying the required patches, however after doing a ‘apt-get update’ on one of the web servers PHP based requests were no longer working.
Having a look in the Nginx error logs I found that the issue appeared to be at the PHP-FPM layer of the server (which I kind of expected), as it did have an update included in the bulk install and it was PHP that seemed to be broken, heres an example log:
2014/09/26 05:24:28 [crit] 26963#0: *19 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 46.226.191.96, server: subnet.im, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "subnet.im" 2014/09/26 05:24:29 [crit] 26963#0: *19 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 123.226.191.96, server: subnet.im, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "subnet.im" 2014/09/26 05:24:30 [crit] 26963#0: *19 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 123.226.191.96, server: subnet.im, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "subnet.im" 2014/09/26 05:24:32 [crit] 26964#0: *28 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 123.226.191.96, server: subnet.im, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "subnet.im" 2014/09/26 05:24:38 [crit] 26964#0: *37 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 123.226.191.96, server: subnet.im, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "subnet.im"
After some digging around I found that this was caused by a PHP bug fix #67060 (linky here), the bug was basically providing possible privilege escalation on the web server which they’ve fixed, however this changes some of the permissions stopping Nginx connecting to the required stocket used for PHP processing.
The Fix
Fortunately the fix is fairly simple, edit the PFP-FPM configuration.
nano /etc/php5/fpm/pool.d/www.conf
Add in these three lines, they are probably already there and just need the comment marks removing.
listen.owner = www-data listen.group = www-data listen.mode = 0660
Finally re-start the PHP-FPM service and you should be back in business.
sudo service php5-fpm restart