Juniper SRX ADSL setup

This is the first post on WAN connection setups. I’ll be using and SRX110 was it has a built in ADSL/VDSL port. I’ll be connecting to a dynamic IP ADSL service based in the UK. The service is a BT type configuration. The SRX has been loaded with the factory default config prior to this exercise.

Step 1: Disable the pt interface
We are using the ‘at’ interface for the ADSL so the ‘dual personality’ port needs setting up.

root# deactivate interfaces pt-1/0/0 

Step 2: Set up the ‘at’ interface

root# set interfaces at-1/0/0 encapsulation atm-pvc
root# set interfaces at-1/0/0 atm-options vpi 0
root# set interfaces at-1/0/0 dsl-options operating-mode auto
root# set interfaces at-1/0/0 unit 0 encapsulation atm-ppp-vc-mux
root# set interfaces at-1/0/0 unit 0 vci 0.38
root# set interfaces at-1/0/0 unit 0 ppp-options chap default-chap-secret "your_password"
root# set interfaces at-1/0/0 unit 0 ppp-options chap local-name "your_username"
root# set interfaces at-1/0/0 unit 0 ppp-options chap passive
root# set interfaces at-1/0/0 unit 0 family inet negotiate-address

Step 3: Correct the interfaces in the zones
We need to swap the pt interface for the at interface in the default security setup.

root# delete security zones security-zone untrust interfaces pt-1/0/0.0
root# set security zones security-zone untrust interfaces at-1/0/0.0

Step 4: Add the default route

root# set routing-options static route 0.0.0.0/0 next-hop at-1/0/0.0
Posted in Juniper | Tagged , , , | Comments Off on Juniper SRX ADSL setup

Netapp Replace a failed drive : 7-Mode

Here at work we are dedicated Netapp zealots, so are fully bought into to Ontap. That said there are occasions when we need to replace a drive in a 7Mode appliance which give us all the shivers was we left this behind long ago. So here is a quick how to on what to do. For the uninitiated, simply replacing the failed drive is not enough in most cases as we have auto assign turned off. If the drive is not manually assigned to a controller, it will sit in the ‘un-owned’ state and will not be a spare for any aggregate.

Step1: Swap the drive
Complete the mechanics of the swap.

Step 2: Check the drive is seen. Do this on the controller you want the drive to belong to.

CONTROLLER1> disk show -n
  DISK       OWNER                    POOL   SERIAL NUMBER         HOME                    DR HOME
------------ -------------            -----  -------------         -------------           -------------
0b.01.9      Not Owned                  NONE   KZBMBNDR

Step 3: Assign to the controller, note I want it on CONTROLLER1

CONTROLLER1> disk assign 0b.01.9

Note that there are no reassuring ‘OK’ messages!

Step 4: Check there are no unowned drives

CONTROLLER1> disk show -n
disk show: No unassigned disks

Step 5: check it has become a spare (output clipped for brevity)

CONTROLLER1> vol status -s

Pool1 spare disks (empty)

Pool0 spare disks

RAID Disk       Device          HA  SHELF BAY CHAN Pool Type  RPM  Used (MB/blks)    Phys (MB/blks)
---------       ------          ------------- ---- ---- ---- ----- --------------    --------------
Spare disks for block checksum
spare           0b.01.9         0b    1   9   SA:B   0   SAS 10000 857000/1755136000 858483/1758174768

All looks good!

Posted in Netapp | Tagged , , , , | Comments Off on Netapp Replace a failed drive : 7-Mode

Cisco Dynamic L2L VPN setup

Todays challenge is to set up an L2L VPN tunnel between an Cisco ASA running IKEv1 and Cisco 927 with a dynamic IP address. The 927 is behind a NAT firewall so needs to be managed through the tunnel so the tunnel has to come up without intervention and it also needs to work without any LAN ports connected.

Stage 1 – ASA Setup for the head end.
The ASA needs to be st up using the dynamic map configuration described I a earlier post

crypto dynamic-map DYNOMAP 10 set ikev1 transform-set MY_TRANSFORMSET
crypto dynamic-map DYNOMAP 10 set reverse-route
crypto map VPN 999 ipsec-isakmp dynamic DYNOMAP
crypto map VPN interface OUTSIDE

And the special tunnel group for the dynamic L2L

tunnel-group DefaultL2LGroup ipsec-attributes
 ikev1 pre-shared-key *****

Stage 2 – C927 set for IPsec VPN
Normally we would use a tunnel interface but in this case the ASA does not support that setup so we are doing. tunnel-less version:

crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 2

crypto isakmp key my_secret_key! address W.X.Y.Z   

crypto ipsec transform-set MY_TRANSFORM_SET esp-aes esp-sha-hmac 
 mode tunnel

crypto map GC_MAP 10 ipsec-isakmp 
 set peer W.X.Y.Z
 set transform-set MY_TRANSFORM_SET 
 match address TRAFFIC

ip access-list extended TRAFFIC
 permit ip 192.168.5.0 0.0.0.255 192.168.6.0 0.0.0.255

Then apply this to the WAN port

interface GigabitEthernet4
 description *** WAN ***
 ip address a.b.c.d 255.255.255.252
 crypto map GC_MAP

Assuming you have the NAT setup correctly we can assume that works fine.

Stage 3 – Keeping the tunnel alive.
I have used an SLA object to ping a server on the other side ever 5 seconds to trigger the tunnel. This allows us to log into the router via the tunnel.

ip sla 1
 icmp-echo 192.168.6.10 source-interface Vlan1
 frequency 5
ip sla schedule 1 life forever start-time now

Stage 4 – About these LAN cables
The SLA will not work if the VLAN1 interface is down. To make the VLAN1 interface come up there needs to be a live cable on a switch port of the router. Cisco has a sneaky command to sort this issue out:

interface Vlan1
 description *** LAN ***
 no autostate

So that’s about it!

Posted in Cisco | Tagged , , , , | Comments Off on Cisco Dynamic L2L VPN setup

Juniper VRRP setup

I know Cisco support VRRP and GRRP but I’ve always used HSRP as my redundant gateway of choice. In the scope of the JN0-348 the only redundant gateway is VRRP (Virtual Router Redundancy Protocol). Its similar to HSRP so should not pose much of a config challenge. Let’s run over a few facts:

Router Roles:
VRRP Router – any router participating in the VRRP process.
Master Router – the router doing the forwarding.
Backup Router – the router that will take the forwarding role on in the event of a failure
Virtual Router – the IP address which is the ‘dummy’

Communication:
All the VRRP routers must connect via a common LAN segment and uses multicast IP 224.0.0.18 with a TTL of 255. default timer is 1 second

Master Election:
By configurable priority with 100 being the default. Higher is better. The other option is to assign the Virtual IP to the physical interface of the box you want to be the master. Preemption is off by default and tuneable.

State:
Init – the router is still initialising. Matster, Backup and Transition (between master and backup etc).

Configuration:
The config is a subset of the ip address of the interface. The VRRP Group number must be consistent across all VRRP routers sharing the VIP.
On SRX1

root# set interfaces ge-0/0/5 unit 0 family inet address 172.16.55.251/24 vrrp-group 55 virtual-address 172.16.55.1
root# set interfaces ge-0/0/5 unit 0 family inet address 172.16.55.251/24 vrrp-group 55 priority 120
root# set interfaces ge-0/0/5 unit 0 family inet address 172.16.55.251/24 vrrp-group 55 preempt

On SRX2

root@SRX2# set interfaces fe-0/0/1 unit 0 family inet address 172.16.55.252/24 vrrp-group 55 virtual-address 172.16.55.1

Verification SRX1:

root> show vrrp summary  
Interface     State       Group   VR state       VR Mode    Type   Address 
ge-0/0/5.0    up             55   master          Active    lcl    172.16.55.251      
                                                            vip    172.16.55.1   

Verification SRX2:

root@SRX2> show vrrp summary    
Interface     State       Group   VR state       VR Mode    Type   Address 
fe-0/0/1.0    up             55   backup          Active    lcl    172.16.55.252      
                                                            vip    172.16.55.1     

Saving that 3rd IP address!
We now we can assign the ‘hot’ IP to an actual interface, so here is how it looks from SRX2 point of veiw:

root@SRX2# show interfaces fe-0/0/1          
description "*** LAN PORT ***";
unit 0 {
    family inet {
        address 172.16.55.1/24 {
            vrrp-group 55 {
                virtual-address 172.16.55.1;
                priority 255;
            }
        }
    }
}

Note that when I changed the IP on the fe-0/0/1 interface it ripped out all the VRRP config as its all ‘downstream’ of the IP address. The verification now looks like:

root@SRX2> show vrrp summary 
Interface     State       Group   VR state       VR Mode    Type   Address 
fe-0/0/1.0    up             55   master          Active    lcl    172.16.55.1        
                                                            vip    172.16.55.1     

and the SRX1 which was formerly the master looks like:

root> show vrrp summary 
Interface     State       Group   VR state       VR Mode    Type   Address 
ge-0/0/5.0    up             55   backup          Active    lcl    172.16.55.251      
                                                            vip    172.16.55.1        

So the final test was to pull the cable out of the master (SRX2) and check it fails over nicely. Here is the extract from the log file:

Sep 23 15:37:02   vrrpd[1972]: VRRPD_NEW_MASTER: Interface ge-0/0/5.0 (local address 172.16.55.251) became VRRP master for group 55 with master reason masterNoResponse
Posted in Juniper | Tagged , , , | Comments Off on Juniper VRRP setup

Juniper SRX – I just want a router!

Working on the JN0-348 exam prep requires a router or two for BGP, IS-IS and other stuff that is not supported on an EX switch. Step forward the SRX 320 firewall which does all the good stuff and has a firewall built in as well! The one issue is that for study purposes the firewall just gets in the way so this posts the instructions to convert the system into as close to a router as possible. I also use some SRX110 appliances but they don’t have the required software revision on them for the current exam, but its not far off. The config is slightly different on the SRX110 as the interfaces are 100mbps.

Stage 1 – Bin the security settings

root# delete security

Stage 2 – Remove DHCP

root# delete system services dhcp-local-server
root# delete access 

Stage 3 – Remove the Autoinstallation

root# delete system autoinstallation

Stage 4 – Sort out the VLANs

root# delete vlans vlan-trust
root# delete interfaces ge-0/0/1.0 family ethernet-switching vlan members vlan-trust 
root# delete interfaces ge-0/0/2.0 family ethernet-switching vlan members vlan-trust 
root# delete interfaces ge-0/0/3.0 family ethernet-switching vlan members vlan-trust 
root# delete interfaces ge-0/0/4.0 family ethernet-switching vlan members vlan-trust 
root# delete interfaces ge-0/0/5.0 family ethernet-switching vlan members vlan-trust 
root# delete interfaces ge-0/0/6.0 family ethernet-switching vlan members vlan-trust 
root# set vlans default vlan-id 1 l3-interface irb.0
root# set interfaces ge-0/0/1.0 family ethernet-switching vlan members default
root# set interfaces ge-0/0/2.0 family ethernet-switching vlan members default
root# set interfaces ge-0/0/3.0 family ethernet-switching vlan members default
root# et interfaces ge-0/0/4.0 family ethernet-switching vlan members default
root# set interfaces ge-0/0/5.0 family ethernet-switching vlan members default
root# set interfaces ge-0/0/6.0 family ethernet-switching vlan members default

Stage 5 – Remove the inspection engine from the packet path

root# set security forwarding-options family inet6 mode packet-based
root# set security forwarding-options family mpls mode packet-based
root# set security forwarding-options family iso mode packet-based

Stage 6 – Reboot

Everybody loves a reboot.

So here it is in a single copy passable block:

delete security
delete system services dhcp-local-server
delete access
delete system autoinstallation
delete interfaces ge-0/0/1.0 family ethernet-switching vlan members vlan-trust 
delete interfaces ge-0/0/2.0 family ethernet-switching vlan members vlan-trust 
delete interfaces ge-0/0/3.0 family ethernet-switching vlan members vlan-trust 
delete interfaces ge-0/0/4.0 family ethernet-switching vlan members vlan-trust 
delete interfaces ge-0/0/5.0 family ethernet-switching vlan members vlan-trust 
delete interfaces ge-0/0/6.0 family ethernet-switching vlan members vlan-trust 
delete vlans vlan-trust
set vlans default vlan-id 1 l3-interface irb.0
set interfaces ge-0/0/1.0 family ethernet-switching vlan members default
set interfaces ge-0/0/2.0 family ethernet-switching vlan members default
set interfaces ge-0/0/3.0 family ethernet-switching vlan members default
set interfaces ge-0/0/4.0 family ethernet-switching vlan members default
set interfaces ge-0/0/5.0 family ethernet-switching vlan members default
set interfaces ge-0/0/6.0 family ethernet-switching vlan members default
set security forwarding-options family inet6 mode packet-based
set security forwarding-options family mpls mode packet-based
set security forwarding-options family iso mode packet-based
Posted in Juniper | Tagged , , , | Comments Off on Juniper SRX – I just want a router!

Juniper Switch Security pt 1 – DHCP Snooping

Full disclosure I’m on the ELS platform so the old fashioned ‘easy way’ is not available here. The task is to secure the switch using DHCP Snooping to protect ourselves against rogue DHCP servers popping up. When the feature is enabled, all access ports are ‘untrusted’ and all trunks are ‘trusted. My DHCP server is an SRX plugged into port ge-0/0/0 of the switch. Turning on the feature is not quite as straightforward as I hoped it would be.

Stage 1 – Activate DHCP Snooping
Actually you can’t just switch it on any more, you have to enable a feature in the DHCP-Security tree. I’ll use DAI (Dynamic Arp Inspection), but more on what that is later. The snooping is per VLAN so you need a VLAN in place ahead of time, or if you are lazy, just use the default.

set vlans default forwarding-options dhcp-security arp-inspection

Stage 2 – Create a Group
Bear in mind the DHCP server is in an access port and it is port 0/0/0 so will be blocking any DHCP goodness. So tp start the process of allowing a DHCP server to exist on an access port, we need to create a group and assign a port to the group.

set vlans default forwarding-options dhcp-security group MYDHCPSERVERS interface ge-0/0/0.0

Stage 3 – Set the Group to override the default behaviour
This stage actually makes the previously created group override the normal behaviour.

set vlans default forwarding-options dhcp-security group MYDHCPSERVERS overrides trusted

Stage 4 – Verify
In the ELS the verification is to look at the snooping database as below:

root> show dhcp-security binding 
IP address        MAC address         Vlan     Expires State   Interface
192.168.1.2       c8:2a:14:0a:1d:a6   default  85549   BOUND   ge-0/0/6.0          

The interface shown above (ge-0/0/6) is the port the test laptop is plugged into.

Posted in Juniper | Tagged , , , , , | Comments Off on Juniper Switch Security pt 1 – DHCP Snooping

Juniper Redundant Trunk Groups

After the success of the LAG configuration comes the RTG or Redundant Trunk Group. This seems to be similar to using a Cisco backup interface. On a stacked switch setup like a c3850 or c3750 you would definitely used a LAG onto the different stack members. On planet Nexus a VPC would be the way to go. Juniper has this to say on the feature:

“In a typical enterprise network composed of distribution and access layers, a redundant trunk link provides a simple solution for network recovery when a trunk port on a switch goes down. In that case, traffic is routed to another trunk port, keeping network convergence time to a minimum.”

I’ve loaded the factory default config prior to the start and will be connecting a new EX2300 to another EX2300 and an SRX300. We will just be concentrating on the access-layer EX2300

Just a quick note, our kit here is Junos: 18.1R3.3 which use the ELS style configuration.

Stage 1 – Disable RSTP on the interfaces

root# disable protocol rstp interface ge0/0/0
root# disable protocol rstp interface ge0/0/1

Stage 2 – Make the interfaces into trunk ports – and you need to add clam meters to the trunk, even if its just the default VLAN.

root# set interfaces ge-0/0/0 unit 0 family ethernet-switching interface-mode trunk
root# set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members default

root# set interfaces ge-0/0/1 unit 0 family ethernet-switching interface-mode trunk
root# set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members default

Stage 3 – Create the RTG (Redundant Trunk Grup) and set the failover parameters. Note the name of the RTG can only be rtg0, rtg1, rtg3, etc

root# set switch-options redundant-trunk-group group rtg0 interface ge-0/0/0.0 primary
root# set switch-options redundant-trunk-group group rtg0 interface ge-0/0/1.0
root# set switch-options redundant-trunk-group group rtg0 preempt-cutover-timer 30

So I’ve used ge-0/0/0 as the primary port which willfailover to ge-0/0/1 in much faster time that RSTP would make it happen. The preemption timer controls the ge-0/0/0 take-back once it has re-established. The default preemption timer is 1 second which may be a bit quick to avoid flapping.

Stage 4 – Verification.

Check its running ok with a basic verification:

root> show redundant-trunk-group    
Group      Interface   State       Time of last flap                      Flap 
name                                                                      count

rtg0       ge-0/0/0.0  Up/Pri/Act  Never                                      0
           ge-0/0/1.0  Up          Never                                      0
Posted in Juniper | Tagged , , | Comments Off on Juniper Redundant Trunk Groups

Juniper LAG (Etherchannel)

Coming from a Cisco background its seems unnecessarily difficult and complicated to set up a couple of ports into an ether channel configuration on my pair of test Juniper EX2300s. That said the test for the JNCIS-ENT is looming so writing this down should help the process.

Stage 1
Lets reset the configuration to factory default and restart the switch.

root> configure 
Entering configuration mode

{master:0}[edit]
root# load factory-default 
warning: activating factory configuration

{master:0}[edit]
root# set system root-authentication plain-text-password 
New password:
Retype new password:

{master:0}[edit]
root# commit and-quit 
configuration check succeeds
commit complete
Exiting configuration mode

{master:0}
root> request system reboot
Reboot the system ? [yes,no] (no) yes

Stage 2
Now we have a fresh install to work with, we have to tell the Junos device that we want to use an aggregated service at the chassis level. Note the device count is the number of LAG instances in this case. The statement will create the

ae0

interface which is a aggregated ethernet interface.

root# set chassis aggregated-devices ethernet device-count 1

When done you can see the config looks like:

root# show chassis 
aggregated-devices {
    ethernet {
        device-count 1;
    }
}

{master:0}[edit]

Stage 3
Was does not seem to be documented is that the LAG interfaces do not like RSTP enabled on them and neither do they enjoy having a Unit 0 configured on them either. I’m using the first two ports for my LAG and the ‘out of the box config looks like this:

root# show interfaces 
ge-0/0/0 {
    unit 0 {
        family ethernet-switching {
            storm-control default;
        }
    }
}
ge-0/0/1 {
    unit 0 {
        family ethernet-switching {
            storm-control default;
        }
    }
}
root# show protocols rstp              
interface ge-0/0/0;
interface ge-0/0/1;
interface ge-0/0/2;
interface ge-0/0/3;
interface ge-0/0/4;
...

Let’s get rid of the config we don’t want:

root# delete protocols rstp interface ge-0/0/0 
root# delete protocols rstp interface ge-0/0/1
root# delete interfaces ge-0/0/0 unit 0 
root# delete interfaces ge-0/0/1 unit 0

Stage 4

Finally we can add the ports to the LAG group:

root# set interfaces ge-0/0/0 ether-options 802.3ad ae0
root# set interfaces ge-0/0/1 ether-options 802.3ad ae0

… And then configure the trunk port

set interfaces ae0 aggregated-ether-options lacp active 
set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk vlan members default

Whilst we are here we had better enable RSTP on the new LAG port

root# set protocols rstp interface ae0

So that should be about it. I have a trunk port with just one VLAN traversing it! Note that this is a modern-ish software release and the default VLAN is tagged out of the box. Assuming the other end is configured the same we can run some tests.

root> show interfaces terse ge-0/0/0.0    
Interface               Admin Link Proto    Local                 Remote
ge-0/0/0.0              up    up   aenet    --> ae0.0

{master:0}
root> show interfaces terse ge-0/0/1.0    
Interface               Admin Link Proto    Local                 Remote
ge-0/0/1.0              up    up   aenet    --> ae0.0

root> show lacp interfaces ae0           
Aggregated interface: ae0
    LACP state:       Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
      ge-0/0/0       Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/0     Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/1       Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/1     Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
    LACP protocol:        Receive State  Transmit State          Mux State 
      ge-0/0/0                  Current   Fast periodic Collecting distributing
      ge-0/0/1                  Current   Fast periodic Collecting distributing

{master:0}

So that’s about it for this exercise.

Posted in Juniper | Tagged , , , , | Comments Off on Juniper LAG (Etherchannel)

Cisco ASA Site to Site VPN with dynamic IP addresses

Today’s problem is a new customer office opening ahead of their scheduled MPLS installation. We need to connect them back into their VPN via their existing hosted Cisco ASA. The internet connection at the new office is at this point unknown, could be a 4G dongle, could be a satellite or even a DSL connection – or a combination of the three! We have a spare ASA and we are going to create a site to site VPN, despite the fact that the new office IP is unknown or possibly dynamic.

Cisco provide a special kind of crypto map for this challenge called a dynamic crypto map and a special tunnel-group called ‘DefaultL2LGroup’ which catches L2L runnels where the peer IP address cannot be matched. There are ways of ‘steering’ dynamic L2L peers into different tunnel-groups but we only need to use the basics here.

The configuration on the ‘spoke’ end (the one with the dynamic/unknown IP address) is just a standard L2L IPSec tunnel, so we just need the Hub (Fixed IP) end:

Step 1 – Define the interesting traffic (for the NAT Exemption)

object network LOCAL_LAN
 subnet <local LAN ip range>

object network REMOTE_LAN
 subnet <remote LAN ip range>

Step 2 – Configure the NAT exemption

nat (INSIDE,OUTSIDE) source static LOCAL_LAN LOCAL_LAN destination static REMOTE_LAN REMOTE_LAN

Step 3 – Configure the phase 1 setup

crypto ikev1 enable outside
crypto ikev1 policy 10
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 86400

Step 4 – Configure the phase 2 setup

crypto ipsec ikev1 transform-set MY-SET esp-aes esp-sha-hmac

Step 5 – Configure the tunnel-group

tunnel-group DefaultL2LGroup ipsec-attributes
 ikev1 pre-shared-key <secret_key>

Step 6 – Configure the Crypto maps

crypto dynamic-map DYNOVPN 10 set ikev1 transform-set MY-SET
crypto dynamic-map DYNOVPN 10 set reverse-route

crypto map VPNMAP 999 ipsec-isakmp dynamic DYNOVPN
crypto map VPNMAP interface outside
Posted in Cisco | Tagged , , , | Comments Off on Cisco ASA Site to Site VPN with dynamic IP addresses

Basic WebVPN setup on the Cisco ASA 9.x

We have resisted the change for a long time, bit its time to finally move some of our customers over to the SSL VPN who were previously using the IPSec Remote Access VPN. Windows 10 does not support the IPSec client any more, Cisco have stopped developing it and its only saving grace is that Mac seem to have no problem with the built in VPN connector.

We are moving some clients to the ASAv which I will document the installation of another time, but the software version I am using is 9.6(1).

Requirements:

1. Most users will be standard, tunnel-all users
2. A few users will require local LAN access for IP printers etc. These will be kept to a minimum as they pose a security risk
3. The Anyconnect software should be deployed from the ASA.
4. The users will all be stored in the ASA local database.

Stage 1 – Get a 3rd party certificate

I have a previous post on this which is still valid. I used a RapidSSL from Geotrust. The latest client has a ‘checked’ check box to disable non trusted certificates by default and could cause a lot of pain for the support guys – so do this first! make sure the time is set as per the article.

Stage 2 – Create an IP pool for the remote users

I favour using a completely separate IP range, not used anywhere else on the internal network. This saves a lot of faff with adding routes later.

ip local pool VPN-POOL 10.11.11.1-10.11.11.50

Stage 3 – Sort the NAT out

I ran into a world of pain when i did this first as the ASA started responding to ARP requests from anything on its OUTSIDE subnet. The take-home message is that avoid using ‘any’ in your NAT setup. So we want to define the POOL as an object and use that to get the NAT exemption for data leaving our ‘INSIDE’ network to the ‘OUTSIDE’ network via the VPN tunnel. Also we want traffic coming back from the client, not destined for the INSIDE network to be NATted to the internet.

object network VPN-IP-POOL
subnet 10.11.11.0 255.255.255.0
nat (OUTSIDE,OUTSIDE) dynamic interface dns

Now the NAT exemption for the INSIDE to OUTSIDE traffic. I assume there is already a LAN object defined.

nat (INSIDE,OUTSIDE) source static LAN LAN destination static VPN-IP-POOL VPN-IP-POOL

Also we’ll need to allow the OUTSIDE traffic to hairpin on the interface.

same-security-traffic permit intra-interface

Stage 4 – Add the webvpn config

Here we need to upload the pkg files which can be downloaded from cisco.com into the flash of the ASA. they are then referenced in the config.

webvpn
enable OUTSIDE
anyconnect image disk0:/anyconnect-win-4.2.05015-k9.pkg 1
anyconnect image disk0:/anyconnect-macosx-i386-4.2.05015-k9.pkg 2
anyconnect image disk0:/anyconnect-linux-64-4.2.05015-k9.pkg 3
anyconnect enable
tunnel-group-list enable

Note the pkg references have an index number to permit multiple files to be uploaded.

Stage 5 – Group Policy

We’ll create a Group Policy to set the parameters for the users. Its best to create a new policy rather than edit the default. This is our ‘tunnel-all’ policy which will be referenced by the tunnel group as the default policy.

group-policy CUSTOMER-POLICY internal
group-policy CUSTOMER-POLICY attributes
dns-server value 8.8.8.8
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelall

Stage 6 – The Tunnel Group

Here a tunnel group is created which pulls it all together

tunnel-group CUSTOMER type remote-access
tunnel-group CUSTOMER general-attributes
address-pool VPN-POOL
default-group-policy CUSTOMER-POLICY
tunnel-group CUSTOMER webvpn-attributes
group-alias CUSTOMER-LOGIN enable

The group aliases appear in the dropdown when the user logs in.

Stage 7 – The Users

The users are all using the default group policy of ‘CUSTOMER-POLICY’ unless we specify differently.

username user_name password pass_word
username user_name attributes
vpn-group-policy MY-DIFFERENT-GROUP-POLICY
group-lock value CUSTOMER
service-type remote-access

I’ve also locked the user into the correct group to be secure.

This is enough to get up and running – there is loads more to do with customisation, additional security and the like, but for now the customer needs to get online.

Posted in Cisco | Tagged , , , | Comments Off on Basic WebVPN setup on the Cisco ASA 9.x