Cisco ASA Pre-8.3 NAT & Post-8.3 NAT

When Cisco made changes to the Cisco ASA software in 8.3, it completely shook the ASA engineering community. Major changes overhauled the operating system in how the Cisco ASA handles Network Address Translation.

Even today, these changes still surprise people when upgrading from 8.2 to 8.3 or later and many people have a hard time understanding these changes. However, these changes are actually a good thing as it gives you more granular control over the NAT function(s) that your Cisco ASA performs.

I have compiled a list of differences as shown below to help you understand the configurational differences between pre-v8.3 and post-v8.3 NAT configurations.

First we will start with STATIC NAT which is translation from one IP Address on the outside interface (203.0.113.20) to an IP Address on the inside interface (10.1.1.6)

Regular Static NAT 8.2 & Earlier

static (inside,outside) 203.0.113.20 10.1.1.6 netmask 255.255.255.255

Regular Static NAT 8.3 & Later

object network obj-10.1.1.6 host 10.1.1.6 nat (inside,outside) static 203.0.113.20

Next up is the Static PAT where we translate port 80 on the outside interface IP Address of 203.0.113.20 to inside IP 10.1.1.15 port 8080.

Regular Static PAT 8.2 & Earlier

static (inside,outside) tcp 203.0.113.20 80 10.1.1.15 8080 netmask 255.255.255.255

Regular Static PAT 8.3 & Later

object network obj-10.1.1.15 host 10.1.1.16 nat (inside,outside) static 203.0.113.20 service tcp 8080 www

Now we’ll take a look at Static Policy NAT where if the host IP Address 10.1.2.3 attempting to get to the subnet 10.75.7.0/27 gets NAT’d to 192.168.100.100 on the outside interface.

Static Policy NAT 8.2 & Earlier

access-list NET1 permit ip host 10.1.2.3 10.75.7.0 255.255.255.224!static (inside,outside) 192.168.100.100 access-list NET1

Static Policy NAT 8.3 & Later

object network obj-10.1.2.3 host 10.1.2.3object network obj-192.168.100.100 host 192.168.100.100object network obj-10.75.7.0 subnet 10.75.7.0 255.255.255.224nat (inside,outside) source static obj-10.1.2.3 obj-192.168.100.100 destination static obj-10.75.7.0 obj-10.75.7.0

اكمل القراءة

• twitter
• share
• plus

Cisco IOS Radius Authentication with Windows Server 2012 NPS

Configuring Cisco devices to authenticate management users via RADIUS is a great way to maintain a centralized user management base. Traditionally this has been done using the Cisco Access Control Server (ACS) which of course is fairly expensive and is typically out of the price range for most small & medium sized businesses.

If you are like most businesses you may already have an Active Directory infrastructure deployed and thus you already have the necessary software and licenses required to setup a basic RADIUS server using Network Policy Server (NPS) which can be used to authenticate network administrators on your Cisco IOS equipment for management purposes. The main benefit you get from RADIUS authentication is a centralized management console for user authentication and the ability to control which users have access to the Cisco CLI. So look at it this way; if your company hires or fires an employee than whatever changes are applied in Active Directory will take affect immediately. Such as disabling a user account in AD would result in failed authentication attempts for that username when attempting to log into a Cisco device. Also if you have a new employee, you can easily give their username access to Cisco network devices just by adding them into a Security Group in active directory.

This blog will discuss and demonstrate the configuration of Network Policy Server which is included with Windows Server 2008 and greater however will blog concentrate on Windows Server 2008 R2.

Active Directory Configuration

First there are a few small task you must complete in Active Directory. You must create two Security Distribution Groups called Network Engineers and Network Support Technicians

Network Engineers will have level 15 privileges and thus have full read/write permissions to the Cisco Command Line interface after successfully authenticating to Cisco routers and Switches.

Network Support Technicians however will only have Read Only privileges.

Next you will need to assign users to these groups. For the purposes of this blog I have created two users, John Doe and John Smith.

John Doe (Username: jdoe) is a Network Engineer and John Smith (Username: jsmith) is a Network Support Technician. These users will be used to verify the configuration and operational status of NPS.

Once you have completed the basic Active Directory configuration you can move on to the NPS config. Please note that the Security Groups can be named whatever you like.

Windows Network Policy Server Configuration

Prior to configuring NPS it must first be installed and authorized in Active Directory. To install NPS add the “Network Policy and Access Services” role to your server.

After you have authorized NPS in Active Directory you’re ready to add the first RADIUS Client. To add the client you must expan the RADIUS Clients and Servers line and right click on RADIUS Clients and click “NEW”.

You’ll be prompted to enter the Friendly Name and Address, IP address and Shared Secret. Enter this information as required. For this blog we’re using R1 which had the IP address of 172.16.22.215 and the secret of CISCO as shown below;

Note that ND_ is used as a prefix to the device friendly name, this will be used later in the configuration of the NPS Policy which can identify network devices.

Next, click the Advanced Tab across the type and select “Cisco” as the vendor name from the drop down list and click ok;

If you added the client correctly you should see the client friendly name, IP address and other information listed in the RADIUS Clients section;

Now you’re ready to configure the network policy which will authenticate users in the specific active directory groups and grant them access.

to create a new policy you need to expand the Policies item in the left list and right click on “Network Policies” and click NEW.

You must enter a name for the policy, in this case we’re going to use “Network Engineers (Cisco LEVEL 15)”

After you have provided a policy name you must than configure the conditions which are required to match in order to successfully authenticate. You will need to create two conditions;

Configure a User Group to match the Network Engineers security group and the Client Friendly Name to match “ND_?” which denotes the device authenticating has a friendly name starting with ND_

Once you’ve successfully added these conditions you should see the following;

Click next and you’ll be prompted to specify the access permission, leave this as the default “Access Granted” and click next.

Cisco only supports the “Unencrypted authentication (PAP, SPAP) methods. Uncheck everything and check “Unencrypted authentication (PAP, SPAP) as shown below and click next;

After configuring the Authentication Methods you will be prompted to configure the Constraits, you can skip this section and just click next.

When prompted to configure settings, remove the Framed-Protocol and edit the Service-Type and set it to “Login” which is under “Others” as shown below;

Next you will need to add a Vendor Specific Attribute by clicking on “Vendor Specific” under the left side settings and clicking the Add… button

Scroll down the list and select “Cisco-AV-Pair” and click add. You will be prompted to add the Attribute Information, here you will click Add… and set the attribute value as shell:priv-lvl=15

This specifies which privilege level is returned to the authenticating user/device after successful authentication. For Network Engineers this would be shell:priv-lvl=15 and the Network Support Technicians would use shell:priv-lvl=1

When added successfully you should see the following;

After you click next you will be presented a summary of the new network policy that you just created as shown below;

Click finish and you’re ready co configure the Cisco Routers and Switches to authenticate to the NPS Radius Server. Please note that you will need to create another policy for the Network Support Technicians and any other privilege levels you wish to use.

Cisco IOS AAA Configuration

The very first thing we need to do prior to configuring AAA is to setup a local user account so that when the RADIUS server has failed, you have the ability to still log into the device. This is done using the username command as demonstrated below;

R1 con0 is now availablePress RETURN to get started.R1>enableR1#config terminalEnter configuration commands, one per line. End with CNTL/Z.R1(config)#username NORAD priv 15 secret R@du3F@1ledR1(config)#

Now we can enable AAA new model and configure the radius server group and default authentication list as demonstrated below;

R1(config)#username NORAD priv 15 secret R@du3F@1ledR1(config)#aaa group server radius NPS_RADIUS_SERVERSR1(config-sg-radius)#server-private 172.16.22.228 auth-port 1812 acct-port 1812 key CISCOR1(config)#aaa authentication login default group NPS_RADIUS_SERVERS localR1(config)#aaa authorization exec default group NPS_RADIUS_SERVERS local if-authenticatedR1(config)#aaa authorization console

INFO: Users will ONLY authenticate to the RADIUS servers if the RADIUS server is alive when defining the default aaa authentication list using group NPS_RADIUS_SERVERS followed by local. If you are attempting to log into the device using a local account and the Radius servers are accessable than it will reject the authentication unless the local account used to log in also exist in Active Directory and are member(s) of the Network Engineers or Network Support Technicians security group.

And that’s it for the basic Cisco IOS AAA config. You can however get into some more advanced configurations by using AAA list and applying a radius authentication list to the VTY lines and local authentication only to the console line.

Verification

Now for the fun part, verification. If you completed all the steps correctly you should be able to log in using the jdoe username and be automatically placed into privilged mode as demonstrated below;

And also if you configured the second policy for Network Support Technicians, you should be able to authenticate as jsmith and be placed into user mode as shown below;

If you have any questions or suggestions please comment

اكمل القراءة

• twitter
• share
• plus

Private Internet Access via L2TP IPSEC Cisco IOS Client

So with the NSA, the CIA and the FBI sucking up every bit they possibly can on the internet at countless locations around the world you wonder how could you possibly become anonymous on the interwebz? Of course it’s not just the United States Government that feels the need that you as an individual should sacrifice your liberty for security, this practice is becoming quite common all around the globe from the United Kingdom all the way down under in the land of the happy kangaroos (Australia of course). Just for the record I’m sure the kangaroo’s don’t give a shit because they don’t feel their privacy is violated.

As the world awakens to the vast over reach of Government around the globe people are looking for new and innovative ways to retain and/or regain their privacy. As a network engineer I wanted to share one of many methods I use to remain anonymous on the internet.

So first lets ask a big question. Why would you want to remain anonymous on the internet? Think about that for a minute.

As a network engineer or an individual aspiring to become a network engineer you will quickly realize or learn that you can easily be singled out on the internet with just an IP address. Your IP Address can be used to locate you geographically speaking.

For example lets say your computer is infected with a virus and you become an unwilling participate in a hack that is orchestrated by individuals attempting to gain access into classified computer networks to gather information. You personally would be held responsible, after all it is your IP Address that is doing the hacking. Your IP address along with the date and time included in subpoena sent to your ISP could easily identify you and the home address related to the service. Next thing you know you have the SWAT team busting your door down while you’re watching reality TV of SWAT teams busting peoples door down. How is that for irony?

So how do you solve this problem? Through the use of VPN technology. There are several VPN providers on the internet who’s sole purpose is to provide anonymity online. You pay for the service and they provide you with the credentials to connect to a VPN. After you’ve connected all your internet traffic traverses their network and any internet request that are made are made through the VPN. So now your public IP Address is not the IP Address provided to you by your ISP which can be used to identify you but rather the public IP address used by the anonymous VPN service.

While using Anonymous VPN services can be used to commit illegal crimes such as downloading and distributing copyrighted material or perhaps even other nefarious actions, Free CCNA Workbook does not promote or endorse any of these actions. With that being said anything you do on anonymous vpn services is at your own risk.

Beyond the Basics

Traditionally anonymous VPN services are typically used via Dialer interfaces on common operating systems such as Windows and Linux. While this configuration works, it only works for a single PC unless you want to configure a Windows Server with connection sharing which of course is a huge pain in the @$$.

Using a Cisco IOS router you can than allow multiple PC’s to use the VPN service by changing the default gateway on the PC(s) to the inside interface of the VPN Client. You can even go a step further by setting up a separate SSID on your wireless access point(s) so that you have a dedicated wireless SSID which only uses the anonymous VPN service as its connection to the internet.

There are tons of Anonymous VPN Providers out there however this blog is going to demonstrate the configuration of an L2TP IPSEC using Private Internet Access

So enough with all the jibble jabble lets dive in to the config shall we?

The L2TP IPSEC Tunnel Configuration

Well I’m not going to explain every single line of configuration however if you are experienced enough in Cisco IOS and VPN technologies this should all make sense. If you have questions you can post a comment with your question.

Before you get started you’re going to need the credentials for your VPN Authentication. The credentials you got in your email when you signed up with Private Internet Access is NOT the credentials you’ll be using to connect to the VPN. You must log into the Client Support Page and generate new vpn credentials which will be used. Once you have the credentials you’ll need the peer IP address which you’ll be connecting to.

You can obtain this by pinging the DNS name of the VPN gateway you wish to connect to. In this case we’re going to use East US Gateway “us-east.privateinternetaccess.com” At the time of this blog this name resolves to 108.61.152.251. This of course will probably change by the time you read this.

Once you have all this information you’re ready to start configuration. Go ahead and configure hostname, ssh, credentials, IP addresses, etc…

You’re also going to need a PUBLIC IP address for this configuration, for this blog we’re using 73.41.232.21 on FastEthernet0/0

First up we need to configure Phase 1 of the IPSEC Tunnel by defining the ISKMP policies and peer pre-shared key.

!crypto isakmp policy 10 encr aes 256 authentication pre-share group 5!crypto isakmp key mysafety address 108.61.152.251!

Now lets define the first sequence in the crypto map which will be used to build the security association;

!crypto map PIA_VPN 10 ipsec-isakmp set peer 108.61.152.251 set transform-set ESP-AES256-SHA1 match address PIA_EAST_US!

You’re going to need to build out the transform set referenced in the crypto map “ESP-AES256-SHA1″;

!crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac mode transport!

Now you need to configure the ACL referenced in the crypto map “PIA_EAST_US”. In this case the source and destination UDP port is going to be 1701. You’ll also need to use the public IP address which should be static as the source IP Address int he ACL. In this case 73.41.232.21 is the IP address assigned to the outside interface FastEthernet0/0 whereas 108.61.152.251 is the VPN Gateway IP Address.

!ip access-list extended PIA_EAST_US permit udp host 73.41.232.21 eq 1701 host 108.61.152.251 eq 1701!

Once the IPSEC Configuration has been completed you’ll need to assign the crypto map to the public facing IP Address, in this case FastEthernet0/0;

!interface FastEthernet0/0 crypto map PIA_VPN!

Before we can configure the L2TP virtual tunnel interface we first need to define the pseudowire class configuration. The encapsulation will be set to l2tpv2 and the local interface should be defined as the public facing interface;

!pseudowire-class PIA_L2TP encapsulation l2tpv2 ip local interface FastEthernet0/0!

Now we can define the virtual tunnel interface, in this case its going to be a Virtual-PPP Interface;

interface Virtual-PPP1 description Tunnel to PIA EAST US ip address negotiated ip nat outside ip virtual-reassembly ppp eap refuse ppp chap hostname x4108222 ppp chap password 0 8Mz1wHgZDJ ppp ipcp address accept no cdp enable pseudowire 108.61.152.251 1 pw-class PIA_L2TP

And thats it for the L2TP IPSEC Tunnel configuration. You should now be able to verify that Phase I and Phase II have established successfully as shown below;

PIA-GATEWAY#show crypto isakmp saIPv4 Crypto ISAKMP SAdst src state conn-id status108.61.152.251 73.41.232.21 QM_IDLE 1001 ACTIVEIPv6 Crypto ISAKMP SAPIA-GATEWAY#PIA-GATEWAY#show crypto ipsec sainterface: FastEthernet0/0 Crypto map tag: PIA_VPN, local addr 73.41.232.21 protected vrf: (none) local ident (addr/mask/prot/port): (73.41.232.21/255.255.255.255/17/1701) remote ident (addr/mask/prot/port): (108.61.152.251/255.255.255.255/17/1701) current_peer 108.61.152.251 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 305, #pkts encrypt: 305, #pkts digest: 305 #pkts decaps: 294, #pkts decrypt: 294, #pkts verify: 294 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 1, #recv errors 0 local crypto endpt.: 73.41.232.21, remote crypto endpt.: 108.61.152.251 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0 current outbound spi: 0xC4E6F422(3303470114) PFS (Y/N): N, DH group: none inbound esp sas: spi: 0x97AF5057(2544848983) transform: esp-256-aes esp-sha-hmac , in use settings ={Transport, } conn id: 2001, flow_id: NETGX:1, sibling_flags 80000006, crypto map: PIA_VPN sa timing: remaining key lifetime (k/sec): (4580055/1730) IV size: 16 bytes replay detection support: Y Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xC4E6F422(3303470114) transform: esp-256-aes esp-sha-hmac , in use settings ={Transport, } conn id: 2002, flow_id: NETGX:2, sibling_flags 80000006, crypto map: PIA_VPN sa timing: remaining key lifetime (k/sec): (4580054/1730) IV size: 16 bytes replay detection support: Y Status: ACTIVE outbound ah sas: outbound pcp sas:PIA-GATEWAY#

If you are having problems with Phase I or Phase II you can use the debug crypto isakmp and debug crypto ipsec command(s) to help you better understand why. Google any errors you may receive

If your configuration is correct thus far the Virtual-PPP1 interface should be up/up with an IP Address as shown below;

PIA-GATEWAY#show interface virtual-ppp1Virtual-PPP1 is up, line protocol is up Hardware is Virtual PPP interface Description: Tunnel to PIA EAST US Internet address is 10.10.1.3/32 MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, LCP Open Open: IPCP, loopback not set Keepalive set (10 sec) DTR is pulsed for 1 seconds on reset Last input 00:05:43, output never, output hang never Last clearing of "show interface" counters 00:50:30 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 417 packets input, 5892 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 339 packets output, 6217 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out 0 carrier transitionsPIA-GATEWAY#

If your Virtual-PPP1 interface is failing to obtain an IP Address and shows UP/DOWN than you can use the debug ppp authentication command to ensure that your credentials are correct.

Routing and NAT Configuration

Before the clients on the inside can access the internet via the L2TP IPSEC VPN you need to setup two static routes and NAT.

The first static route you’ll need is a route to the VPN Gateway via your ISP default gateway. In this case 108.61.152.251 needs to be routed to 73.41.232.1

!ip route 108.61.152.251 255.255.255.255 73.41.232.1!

Next is going to be the default route for all traffic to reach the internet, send it through the tunnel;

!ip route 0.0.0.0 0.0.0.0 Virtual-PPP1!

Next up you need to define the inside and outside NAT zones;

!interface FastEthernet0/1 ip nat inside!interface Virtual-PPP1 ip nat outside!

Once NAT zones have been defined you’ll need to define an ACL which will be used by NAT overload to translate multiple inside machines to the IP address of the virtual-ppp interface. In this case our inside network is 192.168.0.0/24

!ip access-list standard NAT permit 192.168.0.0 0.0.255.255!

Finally we need to define the source NAT statement so that inside hosts referenced by the named acl “NAT” will be overloaded to the Virtual-PPP1 interface.

!ip nat inside source list NAT interface Virtual-PPP1 overload!

Now you’re golden. To test your NAT configuration you can do a traceroute sourced from your inside interface, in this case FastEthernet0/1 to 4.2.2.2 as demonstrated below;

PIA-GATEWAY#traceroute 4.2.2.2 source FastEthernet0/1 probe 1 numericType escape sequence to abort.Tracing the route to 4.2.2.2 1 10.10.1.1 48 msec 2 * 3 184.75.211.129 64 msec 4 38.88.240.133 88 msec 5 69.31.143.24 60 msec 6 154.54.3.93 76 msec 7 4.69.155.208 128 msec 8 4.2.2.2 112 msecPIA-GATEWAY#

As you can see from the traceroute provided above the next hop IP address is going to be 10.10.1.1 which is the IP address of the VPN gateway.

To allow machines on your network to access the internet via this newly build L2TP IPSEC VPN Gateway you just need to change the default gateway on your machines to the inside interface of the newly configured vpn gateway router.

After which you can test your public facing IP address using IP Chicken!

Download the final Configuration!

Click the button below to download the final configuration!

VPN-GATEWAY Final Configuration

If you have any questions or comments please post a comment below! Enjoy….

اكمل القراءة

• twitter
• share
• plus