Here's a very easy example for site-to-site tunnel using IKEv2 and crypto maps.
In fact it's very easy to "upgrade" your existing L2L tunnel to use IKEv2. You'll notice that the trick is to apply ike version 2 profile to existing crypto map.
Topology:
192.168.1.0/24 - Site1 router --(L2 connection)--- Site2 router - 192.168.2.0/24
Both site1 and site2 routers use 15.1(2)T IOS.
So how does the configuration work.
First of all you define IKEv2 proposals.
----------
crypto ikev2 proposal PROPOSAL_1
encryption aes-cbc-128 3des
integrity sha256 md5
group 5 2
----------
You apply this(or those) proposals to a policy.
-----------
crypto ikev2 policy POLICY_1
proposal PROPOSAL_1
-----------
Define a keyring (this comes from site2 router, site_1's public IP is 10.0.0.1)
-----------
crypto ikev2 keyring KEYRING_1
peer SITE_1
address 10.0.0.1
pre-shared-key cisco
-----------
Following this you define a profile:
-----------
crypto ikev2 profile PROFILE_1
match identity remote address 10.0.0.1 255.255.255.255
authentication local pre-share
authentication remote pre-share
keyring KEYRING_1
-----------
Last thing to do is to apply the profile to you crypto map.
-----------
crypto map MAP 10 ipsec-isakmp
set peer 10.0.0.1
set transform-set TRANSFORM_1
set ikev2-profile PROFILE_1
match address VPN
-------------
Result?
########################################
Site2#deb cry ikev2 event
IKEV2 event debugging is on
Site2#ping 192.168.1.1 sou e0/1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.1
*Jul 26 10:46:07.931: IKEv2:% Getting preshared key from profile keyring KEYRING_1
*Jul 26 10:46:07.931: IKEv2:% Matched peer block 'SITE_1'
*Jul 26 10:46:07.931: IKEv2:Found Policy POLICY_1
*Jul 26 10:46:07.931: IKEv2:(1): Getting configured policies
*Jul 26 10:46:07.931: IKEv2:(1): Setting configured policies
*Jul 26 10:46:07.931: IKEv2:(1): Computing DH public key
*Jul 26 10:46:07.931: IKEv2:(1):
*Jul 26 10:46:07.931: IKEv2:(1): Sending initial message
*Jul 26 10:46:07.931: IKEv2: IKE Proposal: 1, SPI size: 0 (initial negotiation),
Num. transforms: 8
AES-CBC 3DES SHA256 MD5 SHA256 MD596 DH_GROUP_1536_MODP/Group 5 DH_GROUP_1024_MODP/Group 2
*Jul 26 10:46:07.931:
*Jul 26 10:46:07.931: IKEv2:(1): Checking if request will fit in peer window
*Jul 26 10:46:07.931: IKEv2:Tx [L 10.0.0.2:500/R 10.0.0.1:500/VRF i0:f0] m_id: 0x0
*Jul 26 10:46:07.931: IKEv2:HDR[i:8984BC53859B1136 - r: 0000000000000000]
SA KE N NOTIFY(NAT_DETECTION_SOURCE_IP) NOTIFY(NAT_DETECTION_DESTINATION_IP)
*Jul 26 10:46:07.931:
*Jul 26 10:46:07.931: IKEv2:(1): Insert SA
*Jul 26 10:46:08.007: IKEv2:Rx [L 10.0.0.2:500/R 10.0.0.1:500/VRF i0:f0] m_id: 0x0
*Jul 26 10:46:08.007: IKEv2:HDR[i:8984BC53859B1136 - r: 153FE7D81F5F453A]
*Jul 26 10:46:08.007: SA KE N NOTIFY(NAT_DETECTION_SOURCE_IP) NOTIFY(NAT_DETECTION_DESTINATION_IP)
*Jul 26 10:46:08.007:
*Jul 26 10:46:08.007: IKEv2:(1): Processing initial message
*Jul 26 10:46:08.007: IKEv2:(1): Verify SA init message
*Jul 26 10:46:08.007: IKEv2:(1): Processing initial message
*Jul 26 10:46:08.007: IKEv2:(1): Process NAT discovery notify
*Jul 26 10:46:08.007: IKEv2:(1): Check NAT discovery
*Jul 26 10:46:08.007: IKEv2:(1): Computing DH secret key
*Jul 26 10:46:08.019: IKEv2:(1):
*Jul 26 10:46:08.019: IKEv2:(1): Generate skeyid
*Jul 26 10:46:08.019: IKEv2:(1): Complete SA init exchange
*Jul 26 10:46:08.019: IKEv2:(1): Check for EAP exchange
*Jul 26 10:46:08.019: IKEv2:(1): Generate my authentication data
*Jul 26 10:46:08.019: IKEv2:(1): Use preshared key for id 10.0.0.2, key len 5
*Jul 26 10:46:08.019: IKEv2:(1): Get my authentication method
*Jul 26 10:46:08.019: IKEv2:(1): Check for EAP exchange
*Jul 26 10:46:08.019: IKEv2:(1): Sending auth message
*Jul 26 10:46:08.019: IKEv2: ESP Proposal: 1, SPI size: 4 (IPSec negotiation),
Num. transforms: 3
AES-CBC SHA96
*Jul 26 10:46:08.019:
*Jul 26 10:46:08.019: IKEv2:(1): Building packet for encryption; contents are: VID IDi AUTH SA TSi TSr NOTIFY(INITIAL_CONTACT) NOTIFY(SET_WINDOW_SIZE) NOTIFY(ESP_TFC_NO_SUPPORT) NOTIFY(NON_FIRST_FRAGS)
*Jul 26 10:46:08.019:
*Jul 26 10:46:08.019: IKEv2:(1): Checking if request will fit in peer window
*Jul 26 10:46:08.019: IKEv2:Tx [L 10.0.0.2:500/R 10.0.0.1:500/VRF i0:f0] m_id: 0x1
*Jul 26 10:46:08.019: IKEv2:HDR[i:8984BC53859B1136 - r: 153FE7D81F5F453A]
ENCR
*Jul 26 10:46:08.019:
*Jul 26 10:46:08.071: IKEv2:Rx [L 10.0.0.2:500/R 10.0.0.1:500/VRF i0:f0] m_id: 0x1
*Jul 26 10:46:08.071: IKEv2:HDR[i:8984BC53859B1136 - r: 153FE7D81F5F453A]
*Jul 26 10:46:08.071: VID IDr AUTH SA TSi TSr NOTIFY(SET_WINDOW_SIZE) NOTIFY(ESP_TFC_NO_SUPPORT) NOTIFY(NON_FIRST_FRAGS)
*Jul 26 10:46:08.071:
*Jul 26 10:46:08.071: IKEv2:(1): Process auth response notify
*Jul 26 10:46:08.071: IKEv2:(1): Peer is a Cisco device Platform:IOS Capabilities: Granite
*Jul 26 10:46:08.071: IKEv2:(1): Getting configured policies
*Jul 26 10:46:08.071: IKEv2:Found Policy POLICY_1
*Jul 26 10:46:08.071: IKEv2:(1): Verify peer's policy
*Jul 26 10:46:08.071: IKEv2:(1): Get peer authentication method
*Jul 26 10:46:08.071: IKEv2:(1): Get peer's preshared key for 10.0.0.1
*Jul 26 10:46:08.071: IKEv2:(1): Verify authentication data
*Jul 26 10:46:08.071: IKEv2:(1): Use preshared key for id 10.0.0.1, key len 5
*Jul 26 10:46:08.071: IKEv2:(1): Check for EAP exchange
*Jul 26 10:46:08.071: IKEv2:(1): Processing auth message
*Jul 26 10:46:08.071: IKEv2:(1): Closing the PKI session
*Jul 26 10:46:08.071: IKEv2:(1): SA created; inserting SA into database
*Jul 26 10:46:08.071: IKEv2:(1): Load IPSEC key material
*Jul 26 10:46:08.071: IKEv2:(1): Checking for duplicate SA.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 8/12/20 ms
Site2#sh cry ikev2 sa det
Tunnel-id Local Remote fvrf/ivrf Status
1 10.0.0.2/500 10.0.0.1/500 (none)/(none) READY
Encr: AES-CBC, keysize: 128, Hash: SHA256, DH Grp:5, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/163 sec
CE id: 1004, Session-id: 4
Status Description: Negotiation done
Local spi: 8984BC53859B1136 Remote spi: 153FE7D81F5F453A
Local id: 10.0.0.2
Remote id: 10.0.0.1
Local req msg id: 2 Remote req msg id: 0
Local next msg id: 2 Remote next msg id: 0
Local req queued: 2 Remote req queued: 0
Local window: 5 Remote window: 5
DPD configured for 0 seconds, retry 0
NAT-T is not detected
########################################
While on the responder:
########################################
Site1#
*Jul 26 10:46:07.839: IKEv2:Rx [L 10.0.0.1:500/R 10.0.0.2:500/VRF i0:f0] m_id: 0x0
*Jul 26 10:46:07.839: IKEv2:HDR[i:8984BC53859B1136 - r: 0000000000000000]
*Jul 26 10:46:07.839: SA KE N NOTIFY(NAT_DETECTION_SOURCE_IP) NOTIFY(NAT_DETECTION_DESTINATION_IP)
*Jul 26 10:46:07.839:
*Jul 26 10:46:07.839: IKEv2:Verify SA init message
*Jul 26 10:46:07.839: IKEv2:Insert SA
*Jul 26 10:46:07.839: IKEv2:(1): Getting configured policies
*Jul 26 10:46:07.839: IKEv2:Found Policy POLICY_1
*Jul 26 10:46:07.839: IKEv2:(1): Processing initial message
*Jul 26 10:46:07.839: IKEv2:(1): Process NAT discovery notify
*Jul 26 10:46:07.839: IKEv2:(1): Setting configured policies
*Jul 26 10:46:07.839: IKEv2:Failed to retrieve Certificate Issuer list
*Jul 26 10:46:07.839: IKEv2:(1): Computing DH public key
*Jul 26 10:46:07.839: IKEv2:(1):
*Jul 26 10:46:07.839: IKEv2:(1): Computing DH secret key
*Jul 26 10:46:07.907: IKEv2:(1):
*Jul 26 10:46:07.907: IKEv2:(1): Generate skeyid
*Jul 26 10:46:07.907: IKEv2:(1): Sending initial message
*Jul 26 10:46:07.907: IKEv2: IKE Proposal: 1, SPI size: 0 (initial negotiation),
Num. transforms: 4
AES-CBC SHA256 SHA256 DH_GROUP_1536_MODP/Group 5
*Jul 26 10:46:07.907:
*Jul 26 10:46:07.907: IKEv2:Failed to retrieve Certificate Issuer list
*Jul 26 10:46:07.907: IKEv2:Tx [L 10.0.0.1:500/R 10.0.0.2:500/VRF i0:f0] m_id: 0x0
*Jul 26 10:46:07.907: IKEv2:HDR[i:8984BC53859B1136 - r: 153FE7D81F5F453A]
SA KE N NOTIFY(NAT_DETECTION_SOURCE_IP) NOTIFY(NAT_DETECTION_DESTINATION_IP)
*Jul 26 10:46:07.907:
*Jul 26 10:46:07.907: IKEv2:(1): Complete SA init exchange
*Jul 26 10:46:07.907: IKEv2:(1): Starting timer to wait for auth message
*Jul 26 10:46:07.975: IKEv2:Rx [L 10.0.0.1:500/R 10.0.0.2:500/VRF i0:f0] m_id: 0x1
*Jul 26 10:46:07.975: IKEv2:HDR[i:8984BC53859B1136 - r: 153FE7D81F5F453A]
*Jul 26 10:46:07.975: VID IDi AUTH SA TSi TSr NOTIFY(INITIAL_CONTACT) NOTIFY(SET_WINDOW_SIZE) NOTIFY(ESP_TFC_NO_SUPPORT) NOTIFY(NON_FIRST_FRAGS)
*Jul 26 10:46:07.975:
*Jul 26 10:46:07.975: IKEv2:(1): Stopping timer to wait for auth message
*Jul 26 10:46:07.975: IKEv2:(1): Check NAT discovery
*Jul 26 10:46:07.975: IKEv2:(1): Recieved valid parameteres in process id
*Jul 26 10:46:07.975: IKEv2:(1): Peer is a Cisco device Platform:IOS Capabilities: Granite
*Jul 26 10:46:07.975: IKEv2:(1): Getting configured policies
*Jul 26 10:46:07.975: IKEv2:found matching IKEv2 profile 'PROFILE_1'
*Jul 26 10:46:07.975: ISAKMP:(0):: peer matches PROFILE_1 profile
*Jul 26 10:46:07.975: IKEv2:% Getting preshared key from profile keyring KEYRING_1
*Jul 26 10:46:07.975: IKEv2:% Matched peer block 'SITE_2'
*Jul 26 10:46:07.975: IKEv2:Found Policy POLICY_1
*Jul 26 10:46:07.975: IKEv2:(1): Setting configured policies
*Jul 26 10:46:07.975: IKEv2:(1): Verify peer's policy
*Jul 26 10:46:07.975: IKEv2:(1): Get peer authentication method
*Jul 26 10:46:07.975: IKEv2:(1): Get peer's preshared key for 10.0.0.2
*Jul 26 10:46:07.975: IKEv2:(1): Verify authentication data
*Jul 26 10:46:07.975: IKEv2:(1): Use preshared key for id 10.0.0.2, key len 5
*Jul 26 10:46:07.975: IKEv2:(1): Processing initial contact
*Jul 26 10:46:07.975: IKEv2:(1): Processing auth message
*Jul 26 10:46:07.975: IKEv2:(1): Get my authentication method
*Jul 26 10:46:07.975: IKEv2:(1): Get peer's preshared key for 10.0.0.2
*Jul 26 10:46:07.975: IKEv2:(1): Generate my authentication data
*Jul 26 10:46:07.975: IKEv2:(1): Use preshared key for id 10.0.0.1, key len 5
*Jul 26 10:46:07.975: IKEv2:(1): Get my authentication method
*Jul 26 10:46:07.975: IKEv2:(1): Sending auth message
*Jul 26 10:46:07.975: IKEv2: ESP Proposal: 1, SPI size: 4 (IPSec negotiation),
Num. transforms: 3
AES-CBC SHA96
*Jul 26 10:46:07.975:
*Jul 26 10:46:07.975: IKEv2:(1): Building packet for encryption; contents are: VID IDr AUTH SA TSi TSr NOTIFY(SET_WINDOW_SIZE) NOTIFY(ESP_TFC_NO_SUPPORT) NOTIFY(NON_FIRST_FRAGS)
*Jul 26 10:46:07.975:
*Jul 26 10:46:07.975: IKEv2:
Site1#Tx [L 10.0.0.1:500/R 10.0.0.2:500/VRF i0:f0] m_id: 0x1
*Jul 26 10:46:07.975: IKEv2:HDR[i:8984BC53859B1136 - r: 153FE7D81F5F453A]
ENCR
*Jul 26 10:46:07.975:
*Jul 26 10:46:07.975: IKEv2:(1): Closing the PKI session
*Jul 26 10:46:07.975: IKEv2:(1): SA created; inserting SA into database
*Jul 26 10:46:07.975: IKEv2:(1): Load IPSEC key material
*Jul 26 10:46:07.975: IKEv2:(1): Checking for duplicate SA
*Jul 26 10:46:07.975: IKEv2:(1): Starting timer to delete negotiation context
Site1#sh cry ikev2 sa det
Tunnel-id Local Remote fvrf/ivrf Status
1 10.0.0.1/500 10.0.0.2/500 (none)/(none) READY
Encr: AES-CBC, keysize: 128, Hash: SHA256, DH Grp:5, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/132 sec
CE id: 1004, Session-id: 4
Status Description: Negotiation done
Local spi: 153FE7D81F5F453A Remote spi: 8984BC53859B1136
Local id: 10.0.0.1
Remote id: 10.0.0.2
Local req msg id: 0 Remote req msg id: 2
Local next msg id: 0 Remote next msg id: 2
Local req queued: 0 Remote req queued: 2
Local window: 5 Remote window: 5
DPD configured for 0 seconds, retry 0
NAT-T is not detected
########################################
Configuration guide is located here.
http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_cfg_ikev2_ps10592_TSD_Products_Configuration_Guide_Chapter.html
Related RFC:
http://www.ietf.org/rfc/rfc4306.txt
Sunday, July 25, 2010
Wednesday, July 21, 2010
ASA 8.3 part 2 - webvpn
Stuck at the airport - flight delayed. So I might as well write a bit more about my findings on ASA 8.3.
This time I'm going to talk about webvpn.
Frankly speaking webvpn is the only reason why you should consider 8.3.
Here are my highlights:
- Finally! you can smart tunnel your home page (without any hacks and tricks), downside to this - no webvpn toolbar, java needed, only windows and mac support for smart tunnel.
- A very extended OS/Browser support list, check out:
http://www.cisco.com/en/US/docs/security/asa/asa83/asdm63/configuration_guide/vpn_web.html#wp1052888
- Smart tunnel notification (now this might have been there before, but I noticed it just now)
When you enable smart tunneling (on both mac and windows) a notification icon can appear:
http://www.cisco.com/en/US/docs/security/asa/asa83/asdm63/configuration_guide/vpn_web.html#wp1055586
- Auto signon for smart tunnel:
http://www.cisco.com/en/US/docs/security/asa/asa83/asdm63/configuration_guide/vpn_web.html#wp1055462
The functionality is there but please be aware it has very limited scope.
- You'll be also (pleasantly?) surprised by the new way one can customize their webvpn portal.
- A very "important" change in webvpn config guide regarding APCF:
"Cisco TAC may help with APCF to address specific rendering issues if the smart tunneling feature is not working or cannot be used."
Things still to be addressed, from top of my head - webvpn cache "memory leak":
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtb68311
And here's the complete config guide:
http://www.cisco.com/en/US/docs/security/asa/asa83/asdm63/configuration_guide/vpn_web.html
This time I'm going to talk about webvpn.
Frankly speaking webvpn is the only reason why you should consider 8.3.
Here are my highlights:
- Finally! you can smart tunnel your home page (without any hacks and tricks), downside to this - no webvpn toolbar, java needed, only windows and mac support for smart tunnel.
- A very extended OS/Browser support list, check out:
http://www.cisco.com/en/US/docs/security/asa/asa83/asdm63/configuration_guide/vpn_web.html#wp1052888
- Smart tunnel notification (now this might have been there before, but I noticed it just now)
When you enable smart tunneling (on both mac and windows) a notification icon can appear:
http://www.cisco.com/en/US/docs/security/asa/asa83/asdm63/configuration_guide/vpn_web.html#wp1055586
- Auto signon for smart tunnel:
http://www.cisco.com/en/US/docs/security/asa/asa83/asdm63/configuration_guide/vpn_web.html#wp1055462
The functionality is there but please be aware it has very limited scope.
- You'll be also (pleasantly?) surprised by the new way one can customize their webvpn portal.
- A very "important" change in webvpn config guide regarding APCF:
"Cisco TAC may help with APCF to address specific rendering issues if the smart tunneling feature is not working or cannot be used."
Things still to be addressed, from top of my head - webvpn cache "memory leak":
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtb68311
And here's the complete config guide:
http://www.cisco.com/en/US/docs/security/asa/asa83/asdm63/configuration_guide/vpn_web.html
ASA 8.3 part 1 - NAT
edit:
In the meantime Cisco published ASA 8.3 migration guide:
http://www.cisco.com/en/US/docs/security/asa/asa83/upgrading/migrating.html
Please refer to it for all NAT migration questions, otherwise do go on, there's some info compiled below :-)
Recently I found quite a few discussion on supportforums regarding ASA 8.3 and related changes.
While majority of changes are good and much anticipated (ACL, webvpn - which I will try to give highlights at some other day) some changes are confusing at best especially for people who already knew NAT that came from PIX - or everything on ASA prior to 8.3.1 release.
In this post I do not intend to re-write configuration guide, it's there and it has ALL the information you might need, I intend to show how you CAN (and believe me there are multiple ways) how one can translate old PIX/ASA NAT CLI to ASA 8.3. That being said don't take my words for granted and have a look at configuration guide:
http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/nat_overview.html
Let's take a look at changes having in mind old order of NAT operation.
1) Nat exemption (this is NOT the only way to do it, but one that will give you least trouble)
Regarding this one ... you might be careful to check CSCth72642 and some other bugs.
You might need to add reverse rule!
ie. nat (out,in) sour sta REMOTE REMOTE dest sta LOCAL LOCAL
Old Syntax:
access-list NAT0 permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
nat (inside_interface) 0 access-list NAT0
New syntax:
object network MY_NETWORK
subnet 192.168.1.0 255.255.255.0
object network FOREIGN_NETWORK
subnet 192.168.2.0 255.255.255.0
nat (inside_interface,any) source static MY_NETWORK MY_NETWORK destination static FOREIGN_NETWORK FOREIGN_NETWORK
Another example, we're assuming:
- "inside" is the inside interface
- 192.168.0.0/24 is local subnet
- 172.16.0.0/24 is subnet for our remote location (or remote access VPN clients - SSL/IPsec ..)
Old syntax:
access-list NAT0 permit ip 192.168.0.0 255.255.255.0 172.16.0.0 255.255.255.0
nat (inside) 0 access-l NAT0
New syntac:
object network HOME
subnet 192.168.0.0 255.255.0.0
object network REMOTE
subnet 172.16.0.0 255.255.0.0
nat (inside,outside) source static HOME HOME destination static REMOTE REMOTE
It's not exempting anything from NAT but it's making sure there's a static translation when HOME is going REMOTE , for both HOME and REMOTE.
2) Static
- NAT
Old syntax
static (inside_interface,outside_interface) 192.0.2.1 192.168.1.2 netmask 255.255.255.255
New syntax:
object network INTERNAL_IP1
host 192.168.1.2
nat (inside_interface,outside_interface) static 192.0.2.1
- PAT
Old syntax:
static (inside_interface,outside_interface) udp 192.0.2.3 1611 192.168.1.3 161 netmask 255.255.255.255
New syntax:
object network INTERNAL_IP2
host 192.168.1.3
nat (inside_interface,outside_interface) static 192.0.2.3 service udp 161 1611
3. NAT
Old syntax:
nat (inside_interface) 1 192.168.1.0 255.255.255.0
global (outside_interface) 1 192.0.2.254
New syntax: object network MY_SUBNET
subnet 192.168.1.0 255.255.255.0
nat (inside_interface,outside_interface) dynamic 192.0.2.254
However consider, instead, adding a rule similar to this:
nat (any,outside) after-auto source dynamic any interface
Translate everything ELSE to interface via PAT.
Here's order of operation for NAT on 8.3
http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/nat_overview.html#wp1118157
if you check it's NOT that much different comparing to older ones.
So what's the big benefit of 8.3 NAT:
- "any" keyword in NAT (any source, any interface )
- A few new thing are available now man-to-few translations ... possibly nothing ground breaking.
Disadvantages:
- not readable via CLI - everything is an object. ASDM oriented. ("show nat" command DOES help A LOT)
- expanded ("exploding") configuration listing.
- lack of ACL support in NAT rules.
- no additional option on NAT rules (norandom, maximum connection count for example), need to use MPF.
There's of course more to NAT on ASA 8.3 in comparison - and I can post more examples if someone is interested.
Disclaimer:
The above worked on my ASA connected to the lab without REQUIRED memory upgrade.
edit:
18th Aug 2010 - Added some ASA 8.3 NAT bugs and link to Cisco's ASA migration.
In the meantime Cisco published ASA 8.3 migration guide:
http://www.cisco.com/en/US/docs/security/asa/asa83/upgrading/migrating.html
Please refer to it for all NAT migration questions, otherwise do go on, there's some info compiled below :-)
Please be aware of following bugs (once I stumbled upon):
- NAT RPF failure in ASA 8.3
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCth72642
- Access-list migration based on NAT config.
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtf57830
- "Unidirectional" keyword added:
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCti36048
If any of the above links doesn't work go to bugtoolkit directly:
http://www.cisco.com/cgi-bin/Support/Bugtool/launch_bugtool.pl
If any of the above links doesn't work go to bugtoolkit directly:
http://www.cisco.com/cgi-bin/Support/Bugtool/launch_bugtool.pl
Recently I found quite a few discussion on supportforums regarding ASA 8.3 and related changes.
While majority of changes are good and much anticipated (ACL, webvpn - which I will try to give highlights at some other day) some changes are confusing at best especially for people who already knew NAT that came from PIX - or everything on ASA prior to 8.3.1 release.
In this post I do not intend to re-write configuration guide, it's there and it has ALL the information you might need, I intend to show how you CAN (and believe me there are multiple ways) how one can translate old PIX/ASA NAT CLI to ASA 8.3. That being said don't take my words for granted and have a look at configuration guide:
http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/nat_overview.html
Let's take a look at changes having in mind old order of NAT operation.
1) Nat exemption (this is NOT the only way to do it, but one that will give you least trouble)
Regarding this one ... you might be careful to check CSCth72642 and some other bugs.
You might need to add reverse rule!
ie. nat (out,in) sour sta REMOTE REMOTE dest sta LOCAL LOCAL
Old Syntax:
access-list NAT0 permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
nat (inside_interface) 0 access-list NAT0
New syntax:
object network MY_NETWORK
subnet 192.168.1.0 255.255.255.0
object network FOREIGN_NETWORK
subnet 192.168.2.0 255.255.255.0
nat (inside_interface,any) source static MY_NETWORK MY_NETWORK destination static FOREIGN_NETWORK FOREIGN_NETWORK
Another example, we're assuming:
- "inside" is the inside interface
- 192.168.0.0/24 is local subnet
- 172.16.0.0/24 is subnet for our remote location (or remote access VPN clients - SSL/IPsec ..)
Old syntax:
access-list NAT0 permit ip 192.168.0.0 255.255.255.0 172.16.0.0 255.255.255.0
nat (inside) 0 access-l NAT0
New syntac:
object network HOME
subnet 192.168.0.0 255.255.0.0
object network REMOTE
subnet 172.16.0.0 255.255.0.0
nat (inside,outside) source static HOME HOME destination static REMOTE REMOTE
It's not exempting anything from NAT but it's making sure there's a static translation when HOME is going REMOTE , for both HOME and REMOTE.
2) Static
- NAT
Old syntax
static (inside_interface,outside_interface) 192.0.2.1 192.168.1.2 netmask 255.255.255.255
New syntax:
object network INTERNAL_IP1
host 192.168.1.2
nat (inside_interface,outside_interface) static 192.0.2.1
- PAT
Old syntax:
static (inside_interface,outside_interface) udp 192.0.2.3 1611 192.168.1.3 161 netmask 255.255.255.255
New syntax:
object network INTERNAL_IP2
host 192.168.1.3
nat (inside_interface,outside_interface) static 192.0.2.3 service udp 161 1611
3. NAT
Old syntax:
nat (inside_interface) 1 192.168.1.0 255.255.255.0
global (outside_interface) 1 192.0.2.254
New syntax: object network MY_SUBNET
subnet 192.168.1.0 255.255.255.0
nat (inside_interface,outside_interface) dynamic 192.0.2.254
However consider, instead, adding a rule similar to this:
nat (any,outside) after-auto source dynamic any interface
Translate everything ELSE to interface via PAT.
Here's order of operation for NAT on 8.3
http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/nat_overview.html#wp1118157
if you check it's NOT that much different comparing to older ones.
So what's the big benefit of 8.3 NAT:
- "any" keyword in NAT (any source, any interface )
- A few new thing are available now man-to-few translations ... possibly nothing ground breaking.
Disadvantages:
- not readable via CLI - everything is an object. ASDM oriented. ("show nat" command DOES help A LOT)
- expanded ("exploding") configuration listing.
- lack of ACL support in NAT rules.
- no additional option on NAT rules (norandom, maximum connection count for example), need to use MPF.
There's of course more to NAT on ASA 8.3 in comparison - and I can post more examples if someone is interested.
Disclaimer:
The above worked on my ASA connected to the lab without REQUIRED memory upgrade.
edit:
18th Aug 2010 - Added some ASA 8.3 NAT bugs and link to Cisco's ASA migration.
Saturday, June 05, 2010
PPPoE - config example.
Thanks to Oliver P. from Cisco TAC for this one.
Yet another configuration I keep to quickly test PPPoE or particular features over PPPoE on Cisco routers.
Server
Yet another configuration I keep to quickly test PPPoE or particular features over PPPoE on Cisco routers.
Server
----------- aaa new-model ! aaa authentication ppp default local ! virtual-template 1 pre-clone 20 ! user cisco password cisco ! bba-group pppoe global virtual-template 1 ! interface faX/Y pppoe enable ! interface Loopback0 ip address 6.6.66.66 255.255.255.255 ! interface Virtual-Template1 ip unnumbered Loopback0 peer default ip address pool mypool no keepalive ppp authentication pap ! ip local pool mypool 66.66.66.66 66.66.66.166
-----------Client
-----------
bba-group pppoe global int faX/Y description PPPOE interface no ip address duplex auto speed auto pppoe enable group global pppoe-client dial-pool-number 1 ! ! interface Dialer1 mtu 1454 ip address negotiated no ip redirects no ip unreachables no ip proxy-arp encapsulation ppp dialer pool 1 dialer-group 1 no keepalive ppp authentication pap callin ppp pap sent-username cisco password 0 cisco ppp ipcp dns request accept ! ! dialer-list 1 protocol ip permit !
ip route 0.0.0.0 0.0.0.0 dialer1
-----------
L2tp over IPsec - testing configuration.
This is a configuration based on an actual customer's setup.
I keep it whenever I need to implement L2tp over IPsec on Cisco routers.
Spoke config
--------------
--------------
I keep it whenever I need to implement L2tp over IPsec on Cisco routers.
Spoke config
--------------
l2tp-class l2tpclass1 ! pseudowire-class pwclass1 encapsulation l2tpv2 ip local interface FastEthernet0/0 ! interface Virtual-PPP10 ip address negotiated no peer neighbor-route no cdp enable ppp authentication pap callin ppp pap sent-username cisco password 0 cisco pseudowire 1.1.1.1 31 pw-class pwclass1 ! dialer-list 31 protocol ip permit ip route 10.0.0.0 255.0.0.0 Virtual-PPP10
--------------
HUB config
--------------
vpdn enable vpdn tunnel accounting network default vpdn session accounting network default ! vpdn-group DailIn-L2TP/IPsec ! Default L2TP VPDN group accept-dialin protocol l2tp virtual-template 100 lcp renegotiation on-mismatch no l2tp tunnel authentication l2tp tunnel timeout setup 60 ip pmtu ! ! username cisco privilege 15 password cisco ! crypto keyring RING pre-shared-key address 0.0.0.0 0.0.0.0 key cisco ! crypto isakmp policy 10 encr aes 256 authentication pre-share group 5 crypto isakmp key cisco address 0.0.0.0 0.0.0.0 no-xauth crypto isakmp keepalive 30 5 crypto isakmp aggressive-mode disable crypto isakmp profile L2TP description L2TP/IPsec HW CLients Profile keyring RING match identity address 0.0.0.0 ! ! crypto ipsec transform-set ICW esp-aes 256 esp-sha-hmac mode transport
crypto dynamic-map CryDynMapICW 10 set nat demux set security-association lifetime kilobytes 3145728 set transform-set ICW set pfs group5 set isakmp-profile L2TP reverse-route ! ! crypto map CryMapICW local-address Ethernet0/0 crypto map CryMapICW 10 ipsec-isakmp dynamic CryDynMapICW ! ! interface Loopback100 description L2TP Address ip address 10.255.0.1 255.255.255.255 ! interface Ethernet0/0 ip address 1.1.1.1 255.255.255.0 crypto map CryMapICW ! interface Virtual-Template100 ip unnumbered Loopback100 peer default ip address pool L2TPOOL ppp chap hostname cisco ppp chap password 0 cisco ! ip local pool L2TPOOL 5.5.5.1 5.5.5.254
------------------
Wednesday, June 02, 2010
Troubleshooting VoIP issues over ASA/PIX/FWSM appliances.
Recently I've been again put in a situation where I had to troubleshoot voice over IP issues via firewall appliances by Cisco.
Here's a brief summary of types of issues:
- No Voice (including one way voice)
- Delay
- No communication
- Features not working (MoH etc).
Now I will be the first to admit - I am voice-over-IP-agnostic, I've touched CCM or CME once or twice in my life. I'm aware that h323, sip and skinny exist.
From my perspective only two things exist in voice over IP.
- signaling
- actual payload (RTP).
So what you should know about how ASA/FWSM interacts with voice traffic.
0. Before going into voice troubleshooting check routing. In many cases a few pings can save a few hours of "missing voice" or "broken signaling"
1. First of all you most likely want to inspect your signaling traffic to/from the internet
a) Be aware that some implementations do not use default ports:
Prime example - SIP - default udp/5060 but known also to use tcp/5060 and udp/5061 (yes for signaling)
b) Be aware that if you're running voice traffic over VPN tunnel you most likely do not need to inspect traffic (everything normally should be permitted). Inspecting over VPN is waste of time (delay) and can account for some one way voice issues.
2. What does the actual inspection do:
a) Dynamically opens pinholes in your security policy to allow incoming traffic (or outgoing if relevant)
b) Pre-allocates connections and translations for traffic.
Thing to take into account here
!!!!!!
If a given IP/phone is not mentioned in signaling the traffic will NOT be allowed in. This comes over and over with music on hold from secondary CCMs. Since none of the parties actually mentions that this particular CCM will be sending MoH the traffic is neatly being dropped because of security policy.
!!!!!!!
3. ASA/FWSM inspects AND changes payload of signaling packets - and that's a good thing.
Firewalls will change internal IP address to public ones according to translation rules in place.
Be mindful when changing inspection or translation rules. "clear xlate ..." or "clear conn ..." has a big chance of recovering if something went wrong after reconfiguration either in inspection rules or NAT.
4. RSVP packets. They usually contain IP options. ASA 8.0 will drop them. Check out ip-option inspection in ASA 8.2.
5. Signaling works but voice does not go properly (dead silence and one way voice issues).
This is most likely caused by a problem with inspection or some additional policies.
Ie. Firewall should automatically open pin holes in security policy for both way RTP traffic.
Check
------
show conn detail add x.x.x.x
show x det | i x.x.x.x
------
Where x.x.x.x is the source or destination of either signaling or voice.
You should have also enabled logging on informational level and monitor logs for entries mentioning IP address of either source of destination.
Check also those (pick ones interesting)
h323
--------
SCCP
-----
show skinny
------
I would not advise to get debugs at first - better leave those for interaction with TAC.
FYI - If it comes to TAC intervention, TAC will request "inside" and "outside" interfaces capture and debugs taken AT THE SAME TIME.
What goes without saying - !gathering packet capture helps!
If traffic is NATed and you see inside IP addresses in outside captures ... something went wrong. Maybe something similar to 4.?
Do you see packets coming into the appliance? Do you see them leaving? What has been changed.
FWSM note: Remember that inspected traffic goes straight to CPU!
Good luck.
Here's a brief summary of types of issues:
- No Voice (including one way voice)
- Delay
- No communication
- Features not working (MoH etc).
Now I will be the first to admit - I am voice-over-IP-agnostic, I've touched CCM or CME once or twice in my life. I'm aware that h323, sip and skinny exist.
From my perspective only two things exist in voice over IP.
- signaling
- actual payload (RTP).
So what you should know about how ASA/FWSM interacts with voice traffic.
0. Before going into voice troubleshooting check routing. In many cases a few pings can save a few hours of "missing voice" or "broken signaling"
1. First of all you most likely want to inspect your signaling traffic to/from the internet
a) Be aware that some implementations do not use default ports:
Prime example - SIP - default udp/5060 but known also to use tcp/5060 and udp/5061 (yes for signaling)
b) Be aware that if you're running voice traffic over VPN tunnel you most likely do not need to inspect traffic (everything normally should be permitted). Inspecting over VPN is waste of time (delay) and can account for some one way voice issues.
2. What does the actual inspection do:
a) Dynamically opens pinholes in your security policy to allow incoming traffic (or outgoing if relevant)
b) Pre-allocates connections and translations for traffic.
Thing to take into account here
!!!!!!
If a given IP/phone is not mentioned in signaling the traffic will NOT be allowed in. This comes over and over with music on hold from secondary CCMs. Since none of the parties actually mentions that this particular CCM will be sending MoH the traffic is neatly being dropped because of security policy.
!!!!!!!
3. ASA/FWSM inspects AND changes payload of signaling packets - and that's a good thing.
Firewalls will change internal IP address to public ones according to translation rules in place.
Be mindful when changing inspection or translation rules. "clear xlate ..." or "clear conn ..." has a big chance of recovering if something went wrong after reconfiguration either in inspection rules or NAT.
4. RSVP packets. They usually contain IP options. ASA 8.0 will drop them. Check out ip-option inspection in ASA 8.2.
5. Signaling works but voice does not go properly (dead silence and one way voice issues).
This is most likely caused by a problem with inspection or some additional policies.
Ie. Firewall should automatically open pin holes in security policy for both way RTP traffic.
Check
------
show conn detail add x.x.x.x
show x det | i x.x.x.x
------
Where x.x.x.x is the source or destination of either signaling or voice.
You should have also enabled logging on informational level and monitor logs for entries mentioning IP address of either source of destination.
Check also those (pick ones interesting)
h323
--------
----------
SIP
------SCCP
-----
show skinny
------
I would not advise to get debugs at first - better leave those for interaction with TAC.
FYI - If it comes to TAC intervention, TAC will request "inside" and "outside" interfaces capture and debugs taken AT THE SAME TIME.
What goes without saying - !gathering packet capture helps!
If traffic is NATed and you see inside IP addresses in outside captures ... something went wrong. Maybe something similar to 4.?
Do you see packets coming into the appliance? Do you see them leaving? What has been changed.
FWSM note: Remember that inspected traffic goes straight to CPU!
Good luck.
Friday, April 16, 2010
DVTI, SVTI and routing protocols
edit:
Apparently dynamic routing will be supported with DVTI Cisco is in process of changing documentation to reflect this.
After several days of bugging Cisco SEs and TAC I finally got a clear answer on several questions I had regarding DVTI,SVTI and routing protocols.
It is true that you CAN run routing protocols over DVTI tunnels - however that is NOT recommended OR supported - because it was not tested.
Also according to Cisco SVTI and terminate on DVTI, but again routing protocols is not supported in this case, static routing should be fine though.
I'd like to stress out we're talking about Cisco support for those techs, it still might work but good luck getting support from TAC/SEs.
To quote rfc 1925, section 2 point 3:
"
Apparently dynamic routing will be supported with DVTI Cisco is in process of changing documentation to reflect this.
After several days of bugging Cisco SEs and TAC I finally got a clear answer on several questions I had regarding DVTI,SVTI and routing protocols.
It is true that you CAN run routing protocols over DVTI tunnels - however that is NOT recommended OR supported - because it was not tested.
Also according to Cisco SVTI and terminate on DVTI, but again routing protocols is not supported in this case, static routing should be fine though.
I'd like to stress out we're talking about Cisco support for those techs, it still might work but good luck getting support from TAC/SEs.
To quote rfc 1925, section 2 point 3:
"
(3) With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead "
Read more: http://www.faqs.org/rfcs/rfc1925.html
Subscribe to:
Posts (Atom)
