Think Netsec

ASA Route Based VPN (Using BGP)

John Finnegan — Sat, 15 Dec 2018 01:37:40 +0000

ASA Route Based VPN (BGP)

In the previous ASA Route Based VPN article, we only covered the basics of using a VTI and getting a tunnel to pass traffic using static routes. A lot of clients will be wanting to use a dynamic routing protocol, like BGP, to share the networks between peers. If your VPN is not currently a Route Based VPN (VTI) then I would recommend looking at the previous article before looking at this one with BGP.

Understanding your requirements

Figure out which networks in the local network should be advertised to the remote peer and learn what networks they may be advertising to the local environment. The configuration below will be using route-maps with specifically narrow prefix-lists to limit what the local ASA will learn. This will make sure that if the remote side accidentally advertises networks that overlap with the local environment, or with another peer on our ASA, that traffic flow does not get interrupted causing any accidental downtime or issues. There may be times where the remote side is fully trusted so BGP can be the source of truth. This means that you will not need to update the ASA's prefix-lists when new networks are added to the remote side if a more open prefix-list is used. The issue with using a more open prefix-list is that it could allow for issues if wrong networks are advertised by the remote side.

VPN Configuration

Below is a sample existing VPN configuration on the ASA that we will be using for this configuration. At the moment, the tunnel may build but nothing is currently communicating over the tunnel as we have no routes using this VTI. As per the previous article, I am using an APIPA IP as the remote address of the VTI. The difference with this example is that the Remote side will NEED to have an IP in this IP range. BGP peering will not function if these IPs are not in the same network.

!Local Network: 192.168.100.0/24
!Remote Tunnel Address: 169.254.224.254

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

tunnel-group 50.56.228.50 type ipsec-l2l
tunnel-group 50.56.228.50 ipsec-attributes
ikev1 pre-shared-key Th1nkN3t$Ec

crypto ipsec ikev1 transform-set ESP-AES128-SHA esp-aes esp-sha-hmac

crypto ipsec profile ROUTE-BASED-PROFILE
  set ikev1 transform-set ESP-AES128-SHA
  set security-association lifetime seconds 28800
  set pfs group5

interface Tunnel0
   nameif ROUTE-BASED
   ip address 169.254.224.253 255.255.255.252
   tunnel source interface OUTSIDE
   tunnel destination 50.56.228.50
   tunnel mode ipsec ipv4
   tunnel protection ipsec profile ROUTE-BASED-PROFILE

BGP Configuration

Before we can begin configuring BGP, we should find an available AS number that can be used. 64512 - 65534 is reserved for Private use so these can be used if you do not have one already in mind. In this example, we will configure the local AS as 64512.

The remote end of the VPN has informed us that their internal network is 192.168.150.0/24 and that their AS number is 64513. With this information, we have enough to configure the local side of the BGP configuration. Since we do not want the Remote side to advertise anything more then just their 192.168.150.0/24, we will create the Inbound prefix-list with just the 192.168.150.0/24. The local prefix-list will only use the 192.168.100.0/24 as this is the only network we wish to share with the remote end of the VPN tunnel. These prefix-lists will be bound to route-maps which is how we will bind these prefix-lists to the BGP configuration.

prefix-list ThinkNetsec-IN seq 5 permit 192.168.150.0/24
prefix-list ThinkNetsec-OUT seq 5 permit 192.168.100.0/24

route-map ThinkNetsec-ROUTEMAP-IN permit 10
 match ip address prefix-list ThinkNetsec-IN
route-map ThinkNetsec-ROUTEMAP-OUT permit 10
 match ip address prefix-list ThinkNetsec-OUT

Now that the route-maps have been defined, we will create the BGP configuration which will reference these. Below is the configuration of BGP on our loca ASA. This was configured knowing that our local AS is 64512, remote AS is 65413 and that our neighbor is 169.254.224.254.

router bgp 64512
 bgp log-neighbor-changes
 address-family ipv4 unicast
  neighbor 169.254.224.254 remote-as 64513
  neighbor 169.254.224.254 timers 10 30 30
  neighbor 169.254.224.254 activate
  neighbor 169.254.224.254 route-map LAB1-LAB2-ROUTEMAP-IN in
  neighbor 169.254.224.254 route-map LAB1-LAB2-ROUTEMAP-OUT out
  redistribute connected
  redistribute static
  no auto-summary
  no synchronization
 exit-address-family

BGP Configuration Explained

Some of the above configuration is default configuration but I will break down what it is that we configured. First, we configure our local router BGP AS 65412 which drops the configuration into the router configuration. We specify that we are using the address-family of ipv4, which then drops us down again. In this sub configuration, we can define the neighbors and what we should be sending/learning from the neighbors.

I configured our remote neighbor as 169.254.224.254, our peers address over the tunnel, which is using the AS number of 65413. Route-maps are added to the neighbor followed by either in/out. The final variable of in/out tells the BGP configuration that the ASA will either be allowed to send the networks in the route-map (out) or learn networks that match the route-map (in).

The redistribute connected/static is what tells BGP to send all known static and directly connected networks to the neighbors configured in BGP. This is what makes BGP send our local 192.168.100.0/24 network to the Remote peers (neighbor). The outbound route-map applied to the neighbor is what filters these networks to what is just defined in the route-map. A route-map can also be placed in the redistribute commands. This will also limit what is shared from the connected/static networks but this will limit to all neighbors.

Validation

If everything goes well, you will see the following when issuing 'show bgp' and 'show route'

ASA-LAB1# show bgp

BGP table version is 11, local router ID is 192.168.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 50.57.228.144/28 0.0.0.0 0 32768 ?
*> 169.254.224.252/30
0.0.0.0 0 32768 ?
*> 192.168.100.0 0.0.0.0 0 32768 ?
*> 192.168.150.0 169.254.224.254 0 0 64513 ?

ASA-LAB1# show route

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, V - VPN
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is 50.57.228.145 to network 0.0.0.0

S* 0.0.0.0 0.0.0.0 [1/0] via 50.57.228.145, OUTSIDE
C 50.57.228.144 255.255.255.240 is directly connected, OUTSIDE
L 50.57.228.150 255.255.255.255 is directly connected, OUTSIDE
C 169.254.224.252 255.255.255.252 is directly connected, ROUTE-BASED
L 169.254.224.253 255.255.255.255 is directly connected, ROUTE-BASED
C 192.168.100.0 255.255.255.0 is directly connected, INSIDE
L 192.168.100.1 255.255.255.255 is directly connected, INSIDE
B 192.168.150.0 255.255.255.0 [20/0] via 169.254.224.254, 00:48:50

I may append more information to this article so follow back up for possible updates. Please comment below if you see any issues or if you would like more clarification. Feel free to contact me directly if you wish to reach out to me for help or if you have any questions.

The post ASA Route Based VPN (Using BGP) appeared first on Think Netsec.

ISAKMP (IKE Phase 1) Status Messages MM_WAIT_MSG

John Finnegan — Mon, 27 Aug 2018 16:07:32 +0000

ISAKMP (IKE Phase 1) Status Messages MM_WAIT_MSG

To establish Phase 1 of a IKE VPN, 6 messages need to be sent between the 2 peers before it can complete. Sometimes when you try to establish a VPN, you will see that the VPN gets stuck at one of these MM_WAIT_MSGs. I will break down each message below and what it may signify if the VPN is stuck at one of these messages.

You can see the status of Phase by looking at the 'show isakmp sa' output. If you have several tunnels then you may want to start the output at your Peer IP 'show isakmp sa | begin X.X.X.X' where X.X.X.X is the Peer IP you are trying to troubleshoot.

ASA-LAB1# show isakmp 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: 50.56.229.98
    Type    : L2L             Role    : initiator 
    Rekey   : no              State   : MM_ACTIVE

ASA-LAB1# show isakmp sa | begin 50.56.229.98
1   IKE Peer: 50.56.229.98
    Type    : L2L             Role    : initiator 
    Rekey   : no              State   : MM_ACTIVE

MM_WAIT_MSG2 (Initiator)

The initiating peer will send message one and will be in a MM_WAIT_MSG2 state. In the initial message, it is sending its Encryption, Hash, DH Group and Lifetime Policy details to the Remote Peer. If you see that you are stuck at this message then this means that the other side is not responding to your requests. This could be that Remote Peer is blocking UDP port 500, they are not configured to listen for IKE traffic or you are not able to reach the peer due to routing issues.

Checking with the Remote side to see if they are getting your message 1 is a good first step. If they state they see MM_WAIT_MSG3, then refer to MM_WAIT_MSG3 below.

ASA-LAB1#   show isakmp 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: 50.56.229.98
    Type    : user            Role    : initiator 
    Rekey   : no              State   : MM_WAIT_MSG2

MM_WAIT_MSG3 (Responder)

The Responding peer has responded with message two and will be stuck in a MM_WAIT_MSG3 state. This should rarely happen because if Message 2 was sent back to the peer, then the initiating peer should be able to respond with Message 3. This can happen for a few reasons but the most common is ISP issues. This can be the route back to the initiating peer or UDP 500 could be blocked from the Responding Peer to the Initiating Peer on their edge. Have the Peer with this message check that UDP 500 is allowed from their environment and that they are not having any routing issues back to the Initiating peer.

ASA-LAB2(config)# show isakmp 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: 50.57.228.150
    Type    : user            Role    : responder 
    Rekey   : no              State   : MM_WAIT_MSG3

MM_WAIT_MSG4 (Initiator)

At this point, the Initiating and Responding Peers have agreed on the IKE Policy (Encryption, Hash, DH Group) and are beginning the process of checking if they trust the Peers IP address. The initiator here has sent Message 3 which will begin the process of trusting eachothers peer IPs. There is more that goes on here but all you really need to know is that the tunnel-groups need to exist for this phase to complete. If the VPN is at this message, then the other side most likely does not have the Initiators IP configured as a tunnel-group and is dropping the request. The best thing to do here is confirm that the Remote Peer has the right Peer IP configured in the tunnel-group settings.

ASA-LAB1# show isakmp 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: 50.56.229.98
    Type    : user            Role    : initiator 
    Rekey   : no              State   : MM_WAIT_MSG4

MM_WAIT_MSG5 (Responder)

At this phase, Message 4 was sent back to the Initiator and the Responder is waiting for Message 5. This means that the Ike Policies match and both Sides have their Peer IPs set correctly as tunnel-groups. If this message is present then the Pre-shared keys between the 2 peers do not match or that the Initiator does not have a pre-shared key defined at all. All settings are valid except for Pre-shared keys at this point. You will want to validate that the keys match between both peers and possibly look at special characters or spaces as these can be problematic for some termination devices.

ASA-LAB2# show isakmp 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: 50.57.228.150
    Type    : L2L             Role    : responder 
    Rekey   : no              State   : MM_WAIT_MSG5

MM_WAIT_MSG6 (Initiator)

This message indicates that the Pre-shared keys do not match between the peers. The initiator has sent message 5 to the Remote Peer and the Remote peer was not able to validate the Pre-shared key and doesn't respond. The best thing to do here is work with the Remote side to confirm the Pre-shared keys. When validating the Pre-shared keys, look at special characters or spaces as these can be problematic for some termination devices.

ASA-LAB1# show isakmp 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: 50.56.229.98
    Type    : user            Role    : initiator 
    Rekey   : no              State   : MM_WAIT_MSG6

For more references for troubleshooting VPNs please check out my VPN Troubleshoot Article or my No Proposal Chosen Article.

If you would like to know more or see more articles on VPNs, please let me know. You can contact me and I will do what I can to help.

The post ISAKMP (IKE Phase 1) Status Messages MM_WAIT_MSG appeared first on Think Netsec.

VPN Troubleshoot (IKEv1 Site to Site)

John Finnegan — Mon, 20 Aug 2018 20:25:26 +0000

VPN Troubleshoot (IKEv1 Site to Site)

When troubleshooting VPNs, the easiest way to figure out what is wrong with the VPN is to have the other side send traffic. This will allow you to narrow down their settings, assuming that the remote side has their side configured correctly and has routing correct.

What I will cover here is building a VPN strictly from debug output alone. The only thing that is not able to be learned via debugs is the pre-shared key so make sure that this is accurate. Most of this article will be assuming that no other VPNs are configured on the ASA currently. If you wish to see more about Site to Site VPN Configuration, check out my Site to Site Article.

What is needed to begin

Check to see if your Firewall already has IKEv1 VPNs configured and, if not, enable IKEv1. The quickest way to verify is to run the following:

show run crypto | include enable

This will show you which interfaces are enabled for IKEv1 (or IKEv2).

If nothing is enabled, then you will need to enable IKEv1 on the appropriate interface. In this case, it is the OUTSIDE interface.

crypto isakmp enable OUTSIDE (Pre 8.3)
crypto ikev1 enable OUTSIDE (Post 8.3)

– Verify

ASA-LAB1(config)# show run crypto | include enable
crypto ikev1 enable OUTSIDE

After you have enabled IKEv1, make sure that you have the Pre-shared key noted somewhere as this will be needed to configure the VPN.

Using Debugs to determine the Peer IP

Sometimes the Remote location may provide the wrong Peer IP. In this case, we are assuming the Peer IP provided is incorrect but the Remote side states they are trying to build the VPN currently. By enabling debugs for crypto messages, you can determine the possible peer IP.

There are several different debug types and varying degrees on the verbosity of the debugs but for this portion, we only need debugs for ISAKMP messages.

To enable this, we need the following

debug crypto isakmp 2 (Pre 8.3)
debug crypto ikev1 2 (Post 8.3)

If the other side is trying to build the tunnel, you should see a message like the following. (Note: If you have other VPNs already configured, you will also see messages from these tunnels. Try to ignore any existing peers messages and find the IP the presents a similar message below. The one referenced is specifically showing that no map is applied to the interface at all to match against. This could state anything such as no proposal chosen or does not match an existing map)

ASA-LAB1# debug cry ikev1 2
ASA-LAB1# Aug 20 15:55:14 [IKEv1]IP = 50.56.229.98, No crypto map bound to interface... dropping pkt
Aug 20 15:55:22 [IKEv1]IP = 50.56.229.98, No crypto map bound to interface... dropping pkt

Assuming that this peer IP is the Clients Peer IP, we can now try to add some of the configuration for this peer. To turn off debugs, run the following command

undebug all

If you are not seeing any debugs then make sure there are no control plane ACLs applied to the interface. You can confirm this by performing the following. If you see something appear like there is below then you will need to make sure that UDP port 500 is permitted along with the ESP protocol in the applied ACL.

ASA-LAB1(config)# show run access-group | i control-plane
access-group 100 in interface OUTSIDE control-plane

Configure Tunnel Group and add a Crypto Map

By creating the Tunnel group, the ASA can try to build Phase 1 of the VPN tunnel. In this case, the Pre-shared key is Th1nkN3tSec.

tunnel-group 50.56.229.98 type ipsec-l2l
tunnel-group 50.56.229.98 ipsec-attributes
    ikev1 pre-shared-key Th1nkN3tSec

Verify there is not a map currently being used for the OUTSIDE interface.

show run crypto | include interface OUTSIDE

If nothing comes up, then create a new MAP. If one exists, then add to the existing MAP later.

In this case, no MAP has been created yet so we will use a new one called VPNMAP.

crypto map VPNMAP interface OUTSIDE

Debugging Phase 1

Assuming that 50.56.229.98 is our peer, the debugs now should be limited to just this peer so that all other existing VPNs do not appear in the output. The following debug command will limit all crypto debugs to just this peer.

debug crypto condition peer 50.56.229.98

To see the encryption, hash etc that the peer is requesting for Phase 1, the debugs will need to be set to max verbosity.

debug crypto isamkp 255 (Pre 8.3)
debug crypto ikev1 255 (Post 8.3)

A lot of text should be coming across the terminal so performing ‘undebug all’ may be necessary to stop to read it. There should be some output similar to the output below.

IKEv1 Recv RAW packet dump
2d 52 d8 dc 44 74 d9 e5 00 00 00 00 00 00 00 00 | -R..Dt..........
01 10 02 00 00 00 00 00 00 00 00 ac 0d 00 00 3c | ...............!
00 00 00 01 00 00 00 01 00 00 00 30 01 01 00 01 | ...........0....
00 00 00 28 01 01 00 00 80 04 00 05 80 01 00 07 | ...(............
80 0e 00 c0 80 02 00 02 80 03 00 01 80 0b 00 01 | ................
00 0c 00 04 00 01 51 80 0d 00 00 14 90 cb 80 91 | ......Q.........
3e bb 69 6e 08 63 81 b5 ec 42 7b 1f 0d 00 00 14 | !.in.c...B{.....
7d 94 19 a6 53 10 ca 6f 2c 17 9d 92 15 52 9d 56 | }...S..o,....R.V
0d 00 00 14 4a 13 1c 81 07 03 58 45 5c 57 28 f2 | ....J.....XE\W(.
0e 95 45 2f 00 00 00 18 40 48 b7 d5 6e bc e8 85 | ..E/....@H..n...
25 e7 de 7f 00 d6 c2 d3 c0 00 00 00 | %..........

RECV PACKET from 50.56.229.98
ISAKMP Header
Initiator COOKIE: 2d 52 d8 dc 44 74 d9 e5
Responder COOKIE: 00 00 00 00 00 00 00 00
Next Payload: Security Association
Version: 1.0
Exchange Type: Identity Protection (Main Mode)
Flags: (none)
MessageID: 00000000
Length: 2885681152
Payload Security Association
Next Payload: Vendor ID
Reserved: 00
Payload Length: 60
DOI: IPsec
Situation:(SIT_IDENTITY_ONLY)
Payload Proposal
Next Payload: None
Reserved: 00
Payload Length: 48
Proposal #: 1
Protocol-Id: PROTO_ISAKMP
SPI Size: 0
# of transforms: 1
Payload Transform
Next Payload: None
Reserved: 00
Payload Length: 40
Transform #: 1
Transform-Id: KEY_IKE
Reserved2: 0000
Group Description: Group 5
Encryption Algorithm: AES-CBC
Key Length: 192
Hash Algorithm: SHA1
Authentication Method: Preshared key
Life Type: seconds
Life Duration (Hex): 00 01 51 80
Payload Vendor ID
Next Payload: Vendor ID
Reserved: 00
Payload Length: 20
Data (In Hex):
90 cb 80 91 3e bb 69 6e 08 63 81 b5 ec 42 7b 1f
Payload Vendor ID
Next Payload: Vendor ID
Reserved: 00
Payload Length: 20
Data (In Hex):
7d 94 19 a6 53 10 ca 6f 2c 17 9d 92 15 52 9d 56
Payload Vendor ID
Next Payload: Vendor ID
Reserved: 00
Payload Length: 20
Data (In Hex):
4a 13 1c 81 07 03 58 45 5c 57 28 f2 0e 95 45 2f
Payload Vendor ID
Next Payload: None
Reserved: 00
Payload Length: 24
Data (In Hex):
40 48 b7 d5 6e bc e8 85 25 e7 de 7f 00 d6 c2 d3
c0 00 00 00
Aug 20 16:27:45 [IKEv1]IP = 50.56.229.98, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 172

With this message, we can see what the Remote side is proposing. In this case, the following is what is being sent for Phase 1.

Encryption: AES-192
Hash: SHA1
DH Group: 5
Lifetime: 86400

Debug Output explained

To elaborate, this is how to read the debug output to determine these settings.

Encryption is found by looking at Encryption Algorithm and Key Length. In this case, Encryption Algorithm is AES-CBC with a Key Length of 192. This means that peer has chosen AES-192. If Key length was 128, for example, then this would have been AES-128 or just AES on the ASA as the default AES is 128 bits.

Hash is found by what is in the Hash Algorithm data. In this case was SHA1.

Diffie-Hellman (DH) group is found in the Group Description data. In this request it showed Group 5.

Lifetime for Phase 1 is always seconds but this is stated in the Life Type portion for verification. The Lifetime is found in the Life Duration data which is presented in HEX. This will need to be converted into DEC (decimal) which can be done via a Programming calculator or on the web. In this case, the conversion of 00 01 51 80 to DEC is 86400

Configuring Phase 1

With this information from the Payload, we can configure Phase 1 of the VPN.

If IKEv1 (ISAMKP) Policies already exist then be sure to not overwrite an existing one. In this case, one does not exist so this will be configured as policy 100.

crypto isakmp policy 100 (Pre 8.3)
authentication pre-share
encryption aes-192
hash sha
group 5
lifetime 86400

crypto ikev1 policy 100 (Post 8.3)
authentication pre-share
encryption aes-192
hash sha
group 5
lifetime 86400

Once this is configured, Phase 1 should be able to complete. If debugs are currently disabled (undebug all was ran), then re-enable the debugs with the following to verify Phase 1 is completing

debug crypto condition peer 50.56.229.98

debug crypto isamkp 2 (Pre 8.3)
debug crypto ikev1 2 (Post 8.3)

A message like the following should appear:

Aug 20 17:07:30 [IKEv1]Group = 50.56.229.98, IP = 50.56.229.98, PHASE 1 COMPLETED

If you are not seeing this message then you may be seeing one of th MM_WAIT messages. If you see MSG6, the the Pre Shared key is incorrect so be sure to validate this again. If you are seeing any other MSG number then be sure to look at the debug messages prior and confirm you have configured them the same. Each of the Messages (1-6) correspond to a portion of Phase 1 but I go over this in more detail in my MM_WAIT_MSG article if you are having issues.

Debugging Phase 2

If debugs are currently disabled (undebug all was ran), then re-enable the debugs with the following commands:

debug crypto condition peer 50.56.229.98

debug crypto isamkp 255 (Pre 8.3)
debug crypto ikev1 255 (Post 8.3)

Note that this will most likely cause a lot of text to scroll by so run ‘undebug all’ if you need to stop it and read. If you already have Phase 2 configured, and are the initiator, then you may see some No Proposal Messages. I have these explained in another article here for clarification.

If the Client is initiating, then there should be a similar output to the following:

AFTER DECRYPTION
ISAKMP Header
Initiator COOKIE: 21 5b 94 0d ad e6 69 9b
Responder COOKIE: 73 85 9d f0 23 d1 99 de
Next Payload: Hash
Version: 1.0
Exchange Type: Quick Mode
Flags: (Encryption)
MessageID: F758707B
Length: 348
Payload Hash
Next Payload: Security Association
Reserved: 00
Payload Length: 24
Data:
d5 53 1a f4 b0 1f 2d d5 14 10 12 49 f7 4b c9 d2
16 23 33 6f
Payload Security Association
Next Payload: Nonce
Reserved: 00
Payload Length: 68
DOI: IPsec
Situation:(SIT_IDENTITY_ONLY)
Payload Proposal
Next Payload: None
Reserved: 00
Payload Length: 56
Proposal #: 1
Protocol-Id: PROTO_IPSEC_ESP
SPI Size: 4
# of transforms: 1
SPI: c1 67 0a 68
Payload Transform
Next Payload: None
Reserved: 00
Payload Length: 44
Transform #: 1
Transform-Id: ESP_AES
Reserved2: 0000
Life Type: Seconds
Life Duration (Hex): 70 80
Life Type: Kilobytes
Life Duration (Hex): 00 46 50 00
Encapsulation Mode: Tunnel
Authentication Algorithm: MD5
Group Description: Group 2
Key Length: 256
Payload Nonce
Next Payload: Key Exchange
Reserved: 00
Payload Length: 24
Data:
7c 9e 9b e0 66 f5 8d e8 72 77 ce a6 10 cc 20 42
20 35 85 d2
Payload Key Exchange
Next Payload: Identification
Reserved: 00
Payload Length: 132
Data:
e2 c4 8d ac 4b 25 25 80 ac a2 42 61 e0 51 96 75
86 cb ca c7 3c df 37 9f cf 7c fc fd 5f b8 bf 66
92 34 a4 8f 2d 57 c9 d1 2d fb 9d a9 e9 37 41 27
60 ee e1 a9 ae ba 7b 82 35 6e 3a cc 79 4a bd d2
62 65 81 fb a0 fe 6a f2 27 98 39 1d fa 0f d0 ce
a7 f6 9e a2 b8 f2 72 4d bc 89 7f a2 05 01 ec a4
69 84 fe d2 70 45 5a b5 14 b3 a6 4c 8c 7b 80 e8
86 a0 64 03 79 bb 00 f7 6f 53 02 c1 1e c6 00 77
Payload Identification
Next Payload: Identification
Reserved: 00
Payload Length: 16
ID Type: IPv4 Subnet (4)
Protocol ID (UDP/TCP, etc...): 0
Port: 0
ID Data: 192.168.200.0/255.255.255.0
Payload Identification
Next Payload: Notification
Reserved: 00
Payload Length: 16
ID Type: IPv4 Subnet (4)
Protocol ID (UDP/TCP, etc...): 0
Port: 0
ID Data: 192.168.100.0/255.255.255.0
Payload Notification
Next Payload: None
Reserved: 00
Payload Length: 28
DOI: IPsec
Protocol-ID: PROTO_ISAKMP
Spi Size: 16
Notify Type: STATUS_INITIAL_CONTACT
SPI:
21 5b 94 0d ad e6 69 9b 73 85 9d f0 23 d1 99 de
Aug 20 16:59:36 [IKEv1]IP = 50.56.229.98, IKE_DECODE RECEIVED Message (msgid=f758707b) with payloads : HDR + HASH (8) + SA (1) + NONCE (10) + KE (4) + ID (5) + ID (5) + NOTIFY (11) + NONE (0) total length : 336

With this output, we can determine the Phase 2 settings and the Encryption domain that they are sending. The local network of the local ASA is 192.168.100.0/24 in this case but we can also confirm this with the Remotes request.

With this output, we can see that our settings should be the following:

Encryption: AES-256
Hash: MD5
PFS (DH Group): Is enabled as Group 2
Lifetime (Seconds): 28800
Lifetime (KB): 4608000

Remote Network: 192.168.200.0/24
Local Network: 192.168.100.0/24

Debug Output explained

Encryption is found by looking at 2 different data points. First being the Transform-Id which shows as ESP-AES and the other being the Key Length of 256.

Hash is determined by looking at the Authentication Algorithm which in this case is MD5.

If PFS is enabled, the data point Group Description will be present with a value, which in this case is Group 2. Note, group2 is the default group when PFS is enabled on the ASA with no group specified.

Lifetime, in this case, is presented twice. One type being Seconds and the other being Kilobytes. This is determined by looking the the Life Type and looking for its corresponding Life Duration that follows it. As with Phase 1, the Lifetimes are presented in HEX so these will need to be converted. The values of 28800 Seconds and 4608000 Kilobytes are actually the default values set by the ASA but we will configure these values manually so that you can see how to set them.

The encryption domain is also present in this output. These are found under the Payload Identification portions of the output. The first reference is the Remotes Encryption domain and the second reference the Local Encryption domain. The 2 ID Types the ASA understands are Subnet and Host. In this case, the ID Type is IPv4 Subnet for both. Protocol ID is also important but this is usually 0 which means the IP type. This encompasses TCP, UDP and ICMP which is why Port is also 0 as we are not referring to a specific TCP/UDP port. The ID Data is where the network is defined. In this case, the first reference is 192.168.200.0/24 and the second reference is 192.168.100.0/24.

Configuring Phase 2

With this information, the VPN should be able to be completed.

First we need to create the Transform Set. This is where Encryption and Hash are specified. The ESP-AES256-MD5 is just the name of the transform set.

crypto ipsec ikev1 transform-set ESP-AES256-MD5 esp-aes-256 esp-md5-hmac

Next we need to create an ACL for the VPN to reference for the encryption domain. Since I will be creating MAP 200, assuming no other MAP exists in VPNMAP, I will create the ACL as 200 for an easier reference. We will also use object-groups so that adding networks in the future will be cleaner and allow for ease of configuration.

object-group network VPN-LOCAL-200
  network-object 192.168.100.0 255.255.255.0
 
object-group network VPN-REMOTE-200
  network-object 192.168.200.0 255.255.255.0
 
access-list 200 permit ip object-group VPN-LOCAL-200 object-group VPN-REMOTE-200

Next we will need to create the new MAP entry.

crypto map VPNMAP 200 match address 200 <- This binds ACL 200 to this MAP.
crypto map VPNMAP 200 set peer 50.56.229.98
crypto map VPNMAP 200 set pfs group2
crypto map VPNMAP 200 set ikev1 transform-set ESP-AES256-MD5
crypto map VPNMAP 200 set security-association lifetime seconds 28800
crypto map VPNMAP 200 set security-association lifetime kilobytes 4608000

With all of this set, we should see both Phase 1 and Phase 2 complete.

Phase 1

ASA-LAB1(config)# show isakmp sa | b 50.56.229.98
1 IKE Peer: 50.56.229.98
Type : L2L Role : responder
Rekey : no State : MM_ACTIVE

Phase 2

ASA-LAB1(config)# show ipsec sa peer 50.56.229.98
peer address: 50.56.229.98
Crypto map tag: VPNMAP, seq num: 200, local addr: 50.57.228.150

access-list 200 extended permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.100.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.200.0/255.255.255.0/0/0)
current_peer: 50.56.229.98

#pkts encaps: 1129, #pkts encrypt: 1129, #pkts digest: 1129
#pkts decaps: 1224, #pkts decrypt: 1224, #pkts verify: 1224

If you are having some issues with Phase 2, I have another article here that covers some of the messages you may see when troubleshooting phase 2.

Configuring Identity NAT

In most cases, the Local Encryption Domain will have NATs associated with them on the ASA. This means they will try to NAT to their corresponding Public IPs or as an Outbound PAT and not use their Local Private IPs over the VPN. In this case, we want them to use their Private IPs so we should create an Identity NAT to ensure that NAT does not take place. I do not have any NATs on my ASA but to prevent any issues in the future, it is best to always have one in place. We can use the objects created earlier to create this NAT. This is where using the groups comes in handy for when you need to add more networks in the future, it will update both the Encryption Domain and the Identity NAT.

nat (any,OUTSIDE) source static VPN-LOCAL-200 VPN-LOCAL-200 destination static VPN-REMOTE-200 VPN-REMOTE-200 no-proxy-arp route-lookup

Notice I set the source interface as any. This is useful if your Encryption Domain uses multiple networks from different interfaces. This means it can all be done with one NAT and not multiple. The route-lookup at the end allows the ASA to pick the correct interface to route the Private IP internally.

For more references for NAT, please check out either my NAT article here or visit my friends NAT article here which covers Identity NAT in greater detail.

If you would like to know more or see more articles on VPNs, please let me know. You can contact me and I will do what I can to help.

The post VPN Troubleshoot (IKEv1 Site to Site) appeared first on Think Netsec.

ASA IPSec VPN – No Proposal Chosen

John Finnegan — Wed, 21 Feb 2018 23:28:15 +0000

ASA IPSec IKEv1

When creating an ASA IPsec VPN, there will be times when Phase 2 does not match between the peers. When the VPN is initiated from the ASA, and debugs are enabled, you will see that the ASA receives a No Proposal Chosen message. There are two specific types of No Proposal Chosen messages that the ASA will see which are No proposal chosen (14) and Invalid ID (18). The 14 and 18 specify which portion of Phase 2 that is mismatching.

IPSec Phase 2

Phase 2 consists of Encryption, Hash, Perfect Forward Secrecy (PFS), Lifetime and Encryption Domain. The numbers 14 and 18 in the non-routine Notify response correlate to these settings.

Invalid ID info (18)

is the easiest to identify. This message is stating that the Encryption Domains do not match on both sides of the VPN. If the ASA has received this message, this means all other settings are valid for Phase 2, just the Access-List for the VPN needs to be updated on either the ASA or Remote Peer.

Error Example:
Oct 05 23:18:54 [IKEv1]Group = 1.2.3.4, IP = 1.2.3.4, Received non-routine Notify message: Invalid ID info (18)

No Proposal Chosen (14)

is a little tougher to troubleshoot which piece of the Phase 2 configuration is mismatched. 14 represents the Encryption, Hash, PFS and Lifetime. Usually this issue is not related to lifetime as this will auto negotiate to the lowest value between the ASA and the Remote peer. There are times when the Remote peer may not negotiate the lifetime which will present this message but this is rare.

This leaves Encryption, Hash and PFS. PFS tends to be the largest culprit of the issues with Phase 2. Some other VPN vendors will have PFS on by default, so the Remote side may believe that PFS is disabled as this was not configured by them. The easiest way to troubleshoot error 14 is to enable pfs as group2. This is the usual default PFS setting for other VPN endpoints and is the default PFS used by the ASA when enabled.

If the issue persists after testing PFS, then it is best to reach out to the other side and compare the settings for Encryption, Hash, PFS and Lifetime to make sure everything matches.

When changing these settings, be careful to watch if the No proposal message has changed from 14 to 18 (Invalid ID info). That would mean that Encryption, Hash, PFS and Lifetime are now correct. Message 18 is only presented if the tunnel has made it past message 14.

Error Example:
Oct 05 23:10:43 [IKEv1]Group = 1.2.3.4, IP = 1.2.3.4, Received non-routine Notify message: No proposal chosen (14)

IPSec Phase 2 Configuration Table

Invalid ID info (18)
access-list 200 permit ip 10.10.10.0 255.255.255.0 192.168.0.0 255.255.255.0 <-Encryption Domain
crypto map VPNMAP 200 match address 200 <-Encryption Domain

No Proposal Chosen (14)
crypto ipsec ikev1 transform-set ESP-AES-SHA esp-aes esp-sha-hmac <-Encryption and Hash
crypto map VPNMAP 200 set peer 1.2.3.4
crypto map VPNMAP 200 set pfs group2 <-PFS
crypto map VPNMAP 200 set ikev1 transform-set ESP-AES-SHA <-Encryption and Hash
crypto map VPNMAP 200 set security-association lifetime seconds 3600 <-Lifetime

To understand more on configuring IPSec VPNs, please see my Basic Site to Site VPN Article or my Route Based VPN Article to learn more. If you wish to see more on troubleshooting VPNs, please check out my Troubleshooting article as well. If you would like to see any new Articles or if you have any questions, feel free to contact me.

The post ASA IPSec VPN – No Proposal Chosen appeared first on Think Netsec.

Brocade ADX Persistence

John Finnegan — Thu, 11 Jan 2018 18:44:46 +0000

Persistence in General

Brocade ADX Persistence is useful when a user needs their traffic to go back to the same Server for the entire session. For example, a Website may require a login which needs to retain the Clients session for the duration the user is on the site. If the Client gets loadbalanced to another Server, this information could be lost and the Client would need to log back in and start over. Persistence would correct this issue and allow the user to stay connected to the same server.

IP Based Persistence

The easiest form of persistence is based on the Clients Source IP. We can do this at a per IP basis or for an IP range. To configure IP based persistence, we will need to enable something called sticky.

Single Source IP Based Persistence

server real Web1-172.24.16.25 172.24.16.25
port http
port http keepalive
port http url "HEAD /"


server real Web2-172.24.16.26 172.24.16.26
port http
port http keepalive
port http url "HEAD /"


server virtual VS-23.53.90.211 172.24.99.211
port http
port http reset-on-port-fail
port http sticky
bind http Web1-172.24.16.25 http Web2-172.24.16.26 http

The ‘port http sticky‘ is what enables per Client IP based persistence (sticky). When a new Client comes in, if the connection does not have a ‘sticky’ record on the Brocade, the connection will get loadbalanced to either Web1 or Web2. Once a loadbalancing decision is made, the Clients IP will be stored in the Brocade tying the users IP to the Server it was loadbalanced too.

Source IP Range Persistence

The command for IP range is similar to the previous command but will had the addition of a netmask. The command that would replace the one above would be ‘port http client-subnet-sticky subnet-mask 255.255.255.0‘ which would now persist on the entire /24 that the Source IP originates from.

How long IP Persistence stays in the table

By default, if the Client is idle for 5 minutes, this Persistence record will get deleted within the Brocade. To allow the Brocade to hold on to this record longer, the command to use is sticky-age <1-60> on the VIP. This command will allow the Brocade to hold on to the connection up to 60 minutes. If the persistence record needs to be held for longer then 60 minutes, you would need to add the command sticky-age-multiplier <1-60>. The multiplier will multiply the sticky-age value by the value used within the multiplier. For example:

server virtual VS-23.53.90.211 172.24.99.211
port http
port http reset-on-port-fail
port http sticky
port http sticky-age 60
port http sticky-age-multiplier 5
bind http Web1-172.24.16.25 http Web2-172.24.16.26 http

The Brocade will now hold the persistence record for 300 minutes (60 x 5).

Persistence Across Services

The Brocade can also persist across services when using IP Based Persistence. To perform this type of persistence, the track-group command will be used. This command will allow persistence records to exist across any ports bound within the track-group command. This command will also tie the Servers healthchecks together for the ports within the group as well. An example for this command would be like the one below.

server virtual VS-23.53.90.211 172.24.99.211
port http
port http reset-on-port-fail
port http sticky
port ssl 
port ssl reset-on-port-fail
port ssl sticky
bind http Web1-172.24.16.25 http Web2-172.24.16.26 http
bind ssl Web1-172.24.16.25 ssl Web2-172.24.16.26 ssl
track-group http 443

In this example, the Brocade is tracking both HTTP and SSL traffic for this VIP. Any traffic that gets a persistence record for HTTP will also get one for SSL. Keep in mind though this also tracks the ports healthchecks. If SSL for Web1 were to fail, this will also stop sending traffic for HTTP to Web1 even though HTTP may be passing its healthcheck.

Cookie Persistence

To enable Cookie Persistence on the Brocade, a CSW Policy needs to be created. A CSW policy is a mechanism on the Brocade to inspect or alter HTTP traffic that is destined to a VIP. Note, if Cookie Persistence is needed on SSL (https) traffic, the Brocade will need to be terminating SSL.

Types of Cookie Persistence

When doing Cookie Persistence on the Brocade, the cookie is usually injected by the Brocade referencing the Server ID. This can be a session based cookie or a time based cookie depending on the needs needed for the VIP. The Brocade can also use Passive Cookie Persistence based on a Cookie the Server provides but that is much more complicated and will be done in another article.

Basic Session Cookie Persistence

Session Cookie Persistence needs the real/remote servers in the VIP to have Server IDs and Group IDs to function. Group IDs range from 1 to 1023 and Server IDs range from 1024 to 2047. Group IDs are assigned as a range(s) while the Brocade can only have one Server ID per port on a real/remote server. Example configuration below:

server real Web1-172.24.16.25 172.24.16.25
port http
port http keepalive
port http url "HEAD /"
port http group-id 1 1
port http server-id 1024

server real Web2-172.24.16.26 172.24.16.26
port http
port http keepalive
port http url "HEAD /"
port http group-id 1 1
port http server-id 1025

server virtual VS-23.53.90.211 172.24.99.211
port http
port http reset-on-port-fail
bind http Web1-172.24.16.25 http Web2-172.24.16.26 http

The green is what needs to be configured on the real/remote servers before the Session Persistence can be used. If the CSW Policy is created and bound to the VIP without these set, the persistence will not function.

Now we will create the CSW Rule, CSW Policy and apply them to the configuration from before.

csw-rule "COOKIE" header "cookie" search "ServerID=" case-insensitive

csw-policy "COOKIE-PERSIST" case-insensitive
match "COOKIE" persist offset 0 length 4 group-or-server-id
default forward 1
default rewrite insert-cookie "ServerID" 

server virtual VS-23.53.90.211
port http csw-policy "COOKIE-PERSIST"
port http csw

With the above example, I create a rule called COOKIE and asked it to look at the HTTP header and search for a cookie with ServerID=. The policy, if it finds this cookie, will persist on the value of the ServerID cookie starting from 0 with a length of 4. This is because cookie value will be no longer then 4 digits and will use this to match against the Server.

The default portion of the CSW Policy tells the VIP to loadbalance to anything in group 1. Once a decision is made, the Brocade will insert a cookie called ServerID using the Server ID of the Server. If no Server ID is applied to the then the Group ID is used instead. (Note: The VIP has the “port http csw” command in red. If this command is not added to the VIP, the CSW Policy will not be enabled)

Basic Time Based Cookie Persistence

A Time Based cookie means that the user does need to keep their session up in the browser to stay persisted. This cookie will stay in their browser for a certain amount of time and will delete itself one the time is up.

To configure a Time Based Cookie on the Brocade, we will just need to add a time to the cookie that is being inserted by the CSW Policy.

csw-policy "COOKIE-PERSIST" case-insensitive
match "COOKIE" persist offset 0 length 4 group-or-server-id
default forward 1
default rewrite insert-cookie "ServerID" * * 30

To insert a Time Based cookie, we need to add the values highlighted above. The orange *‘s are for adding a domain and path to the cookie. The first * is for adding a domain to the cookie but if a * is used instead of a domain, the domain is set to default. The second * is for adding the URL path to the cookie but having the * means to use the default path. These can be set if those values need to be set but in most cases using the * is fine. The green value is how many minutes this cookie should be stored in the Clients Browser. In this case, the cookie is stored for 30 minutes and then deleted. Having the value set at the end is the only difference between a Session Based Cookie and a Time Based Cookie on the Brocade ADX.

You can find more details about Brocade Real Servers and Remote Server configurations in my other Brocade article here.

Please feel free to reach out to me via my contacts page if you have any requests on more content or if you have any questions. If you want any help with an ADX in your Office, please feel free to contact me as well. I will work with you on configuring, upgrading or migrating the ADX.

The post Brocade ADX Persistence appeared first on Think Netsec.

Issues connecting to a VIP on the Brocade ADX from a Server

John Finnegan — Thu, 11 Jan 2018 00:24:17 +0000

If you are going to be creating a VIP on the Brocade that would need to be accessible from another Server behind the Brocade, there will be some things to consider. For example, if a VIP has Servers that it is loadbalancing too that are in the same segment as a Server that needs to connect to this VIP, it will not function without something called Source NAT.

Real Servers in the same Segment as Client Server

Without Source NAT

Lets use an example that you have a segment of 10.10.10.0/24 behind the Brocade. All of your Servers are in this segment and you need these Servers to connect to a VIP on the Brocade which loadbalances to these servers.

We will use the configuration below:

server real WEB1-10.10.10.5 10.10.10.5
port http
port http keepalive
port http url "HEAD/"
port ssl
port ssl keepalive

server real WEB2-10.10.10.6 10.10.10.6 
port http 
port http keepalive 
port http url "HEAD/" 
port ssl 
port ssl keepalive

server virtual VS-10.10.10.100 10.10.10.100
port http
port http reset-on-port-fail
port ssl
port ssl reset-on-port-fail
bind http WEB1-10.10.10.5 http WEB2-10.10.10.6 http
bind ssl WEB1-10.10.10.5 ssl WEB2-10.10.10.6 ssl

Lets say we need our App Server with IP 10.10.10.50 to connect to the 10.10.10.100 VIP. If you try to connect to this VIP from the App Server, the connection will never complete. The flow would look like the following TCP flow below.

Source IP ———- Destination IP
10.10.10.50 —> 10.10.10.100 (VIP)
10.10.10.50 —> 10.10.10.5 (Member)
10.10.10.5 —> 10.10.10.50 (Client)

Notice that the Server responds back to the Client and not the VIP. The Client Server did not connect to the 10.10.10.5 but rather the VIP at 10.10.10.100. The Server will drop this traffic since it never had made a connection to the 10.10.10.5 so the TCCP connection will never complete.

With Source NAT

To correct the issue from before, we would need to enable Source NAT. This will allow the Brocade to translate the Source IP for any connections to the VIP as the closest egress interface IP. For the sake of the example, the IP on the Brocade is 10.10.10.1 and it is the gateway for these Servers. To enable Source NAT, you will add the source-nat keyword to the real servers.

server real WEB1-10.10.10.5 10.10.10.5 
source-nat

server real WEB2-10.10.10.6 10.10.10.6 
source-nat

With the addition of source-nat keyword to the real servers, the flow will now look like the following TCP flow.

Source IP ———— Destination IP
10.10.10.50 —> 10.10.10.100 (VIP)
10.10.10.1 —> 10.10.10.5 (Member) <–Notice that the Source IP became the Brocade IP
10.10.10.5 —> 10.10.10.1 (Brocade IP -Source-Nat)
10.10.10.100 —> . 10.10.10.5 (Client)

Notice that the VIP is now what responded back to the Client Server. Now that the traffic is coming back from the VIP, the TCP connection is valid and will complete the handshake.

You can find more details about Brocade Real Servers and Remote Server configurations in my other Brocade article here.

Please feel free to reach out to me via my contacts page if you have any requests on more content or if you have any questions. If you want any help with an ADX in your Office, please feel free to contact me as well and I will work with you on configuring, upgrading or migrating the ADX.

The post Issues connecting to a VIP on the Brocade ADX from a Server appeared first on Think Netsec.

ASA Route Based VPN

John Finnegan — Sat, 06 Jan 2018 00:40:42 +0000

ASA Route Based VPN

The ASA only performed Policy Based VPNs prior to 9.7 code which can cause a lot of issues when connecting to other vendors. If you are running 9.7+, you will now be able to create a proper Route Based VPN which will allow you to connect to all other vendors with a lot less headache and overhead.

Route Based VPN

Route Based VPNs differ from Policy Based in the fact that you will only have one IPSec Security Association for each peer. In Policy Based, you would have multiple SAs (Phase 2s) as each tunnel had a Identifier using each Network combination of your Encryption Domain. You can force multiple SAs for the Route Based VPN but all in all, it is generally just the one SA for the entire Encryption Domain.

Basic VPN Configuration Start:

We will start by creating the basics of the Site to Site. This first part will be true whether this is a Route Based or Policy Based.

Here is our requirements for the VPN:
Remote Peer IP: 2.2.2.2
Remote Network: 10.10.0.0/16
Local Peer IP: 1.1.1.1
Local Network: 172.24.0.0/16
Phase 1 Parameters:
Encryption: AES -128
Hash Alg.: SHA1
Lifetime(S): 86400
DH Group: Group2
Phase 2 Parameters:
Encryption: AES -256
Hash Alg.: SHA1
Lifetime(S): 28800
PFS DH: Group5
Pre-Shared-Key: Th1nkN3t$Ec

To configure this on the ASA, the commands would look like the following. Please note that I am simulating as if this is my first VPN on my ASA so some commands you may not need: (Note: If you already have VPNs configured, make sure you are not overwriting your ikev1 policy.)

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

tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 ipsec-attributes
ikev1 pre-shared-key Th1nkN3t$Ec

crypto ipsec ikev1 transform-set ESP-AES128-SHA esp-aes esp-sha-hmac

New Configuration for Route Based

This next bit of configuration is new and is what is needed to get the Route Based VPN completed. We will be creating an IPSec Profile to reference the settings we created prior. We will bind this to a new VTI (Virtual Tunnel Interface) on the ASA which will be used to specify the Phase 2 configuration. Notice though that we have not used the Remote Network anywhere in this configuration yet. We will configure this next after we create the VTI.

crypto ipsec profile ROUTE-BASED-PROFILE
  set ikev1 transform-set ESP-AES128-SHA
  set security-association lifetime seconds 28800
  set pfs group5

interface Tunnel0
   nameif ROUTE-BASED
   ip address 169.254.224.253 255.255.255.252
   tunnel source interface OUTSIDE
   tunnel destination 2.2.2.2
   tunnel mode ipsec ipv4
   tunnel protection ipsec profile ROUTE-BASED-PROFILE

Routing Traffic over the Route Based VPN

In my use case, we will not be doing dynamic routing, but rather, static routing. The Routes will be what defines the encryption domain for the Route Based VPN. Since the ASA can not reference a interface for Routing and needs a Next-Hop, I will use an APIPA IP to simulate the Next-Hop. This APIPA does not have to be configured on the other side of the VPN. This will only be needed to trick the Local ASA and to allow for a static route to be created for the new VTI.

route ROUTE-BASED 10.10.0.0 255.255.0.0 169.254.224.254

If you would like to know more or see more articles on VPNs, please let me know. You can contact me and I will do what I can to help.

The post ASA Route Based VPN appeared first on Think Netsec.

Different ASA NATs 8.3+

John Finnegan — Sun, 20 Aug 2017 05:41:32 +0000

Different NAT Types

There are three types of NAT on the ASA which have different processing orders and functions. To understand the different ASA NAT types, we should first go over the the different types of NAT in general.

General Types of NAT

Static NAT—A consistent mapping between a real and mapped IP address. Allows bidirectional traffic initiation.
Dynamic NAT—Maps a group of IP addresses to another group of IP addresses (possibly smaller). This is done based on which ever IP initiates traffic first. Only the ‘real’ hosts can initiate traffic.
Dynamic Port Address Translation (PAT)—Maps a group of IP addresses to a single IP address with a unique source port of that IP address. Only the ‘real’ hosts can initiate traffic.
Identity NAT—Lets you translate a real address to itself, essentially bypassing NAT. You might want to configure NAT this way when you want to translate a large group of addresses, but then want to exempt a smaller subset of addresses.
Twice NAT—A NAT which can perform all the functions of the other NATs but NATs both the Source and Destination IP addresses. Sometimes called Selective NAT if you NAT the Source but NAT the Destination to itself. Selective NAT is useful when you need to NAT the Source to a different Mapped Address based on Destination.

ASA NATs

Manual NAT—A NAT on the ASA to perform all of the NAT types mentioned above. Manual NATs are processed first and executed on the ASA in the order in which they are configured. These are often used in conjunction with VPNs as Identity NATs to exclude VPN traffic from being NAT’d
Auto NAT—Auto NAT can be used as any NAT type above except for Twice NAT or Selective NAT since the Destination IP address can not be specified. These are generally used for Static NATs and are processed after Manual NATs. These do not necessarily perform in their configured order on the ASA, but rather, perform in Alphabetical order. This can be troublesome if you plan on performing PATs within Auto Nats. You can see the processing order of Auto NATs if you do a ‘show xlate’ on the ASA.
After Auto Nat—After Auto NATs are processed last but are written and performed similar to Manual NATs. These can have both Source and Destination IP Address but this type of NAT is generally used for PATs.

Examples:

Not every scenario will be covered, nor every possible type of NAT, but NAT is a powerful tool on the ASA if one understands the way it functions. You can do something as simple as allowing a LAN out to the Internet by using a PAT or do something more complicated. For example, allow your Local LAN to communicate to many Remote LANs (VPNs for example) which have the exact same Local LAN as the Local environment. With NAT, we can fully control everything on the ASA without requesting the Remote side to make complicated NAT changes on their end or requesting that someone play rock paper scissors on who gets to re-IP their networks.

Manual Nat(Source only):

Here, we will use Manual NAT as a Static NAT. We will NAT our local internal IP 192.168.5.7 to the External IP of 83.24.5.34.

object network Web1-192.168.5.7
host 192.168.5.7

object network Web1-External-83.24.5.34
host 83.24.5.34

nat (inside,outside) source static Web1-192.168.5.7 Web1-External-83.24.5.34

With Manual NATs, the IPs are referenced using objects or object-groups. You are not able to just type the IP addresses with these types of NATs so we need an object for every IP or IP network.

Notice the coloring of the text as this will help you identify which IP is for which segment. If the IP 192.168.5.7 comes into the inside segment and its traffic is destined for the outside segment, then it will NAT as 83.24.5.34. The same is true in the reverse if traffic is destined for the 83.24.5.34 on the outside interface. Note that the first segment in the (), in this case is the inside segment, is the sourcing interface. The next interface, in this case outside, is used as the destination so this will NAT anything Destined for 83.24.5.34 to the 192.168.5.7 in the inside segment.

Manual NAT(Source and Destination):

Manual NAT is best used when you need to NAT your traffic differently for a specific Destination. In this example, I will be doing Selective NAT (Twice NAT). We want to NAT 192.168.5.7 to 83.24.5.34 only when our destination is 72.84.56.78. To do this, we will reuse our NAT from earlier but add a destination.

object network Web1-192.168.5.7
host 192.168.5.6

object network Web1-External-83.24.5.34
host 83.24.5.34

object network Destination-72.84.56.78
host 72.84.56.78

nat (inside,outside) source static Web1-192.168.5.7 Web1-External-83.24.5.34 destination static Destination-72.84.56.78 Destination-72.84.56.78

Notice that I have colored the Destination both light blue and blue. This is because of how this NAT functions and which IP in the NAT talks to which IP. In this case, the inside address 192.168.5.7 is using the first object (IP) referenced in the Destination portion of the NAT. The same is true for the outside portion of the NAT which talks to the second object (IP) referenced in the Destination. Always understand this order as it helps if we need to do a full Twice NAT where we map our Destination as a different IP.

Let’c complicate the same NAT a bit and NAT our Destination to a different remote host. We will state that when our 192.168.5.7 address is destined to 72.84.56.78 that we want to map this to googles DNS Server 8.8.8.8.

object network Google-8.8.8.8
host 8.8.8.8

nat (inside,outside) source static Web1-192.168.5.7 Web1-External-83.24.5.34 destination static Destination-72.84.56.78 Google-8.8.8.8

With this addition to our NAT, when our 192.168.5.7 is destined for 72.84.56.78, it will NAT 192.168.5.7 to 83.24.5.34. At the same time, it will NAT 72.84.56.78 to 8.8.8.8. By using this type of NAT, 8.8.8.8 will see our Web1 Server as 83.24.5.34 but our Web1 Server sourcing as 192.168.5.7 will think it is talking to 72.84.56.78.

Auto NAT:

Auto NAT is simpler to configure then Manual NAT and is mainly used for static NATs. We can perform PATs and other NAT types with Auto NAT but I would recommend that Auto NAT is only used for static NATs. As I stated before, these are processed in alphabetical order so if you try to make more specific port forwarding NATs etc with these, you may not get the outcome you want if you name your objects in the wrong alphabetical order.

Lets configure the same Static NAT we did earlier but with Auto NAT.

object network Web1-192.168.5.7
host 192.168.5.6
nat (inside,outside) static 83.24.5.34

You will notice it took less configuration to get the same desired outcome for the Static NAT. This NAT is configured within your object that you specify your host or subnet that you wish to be NAT’d. I will only cover Static NAT for Auto NAT as this is really the only time we should use Auto NAT.

After-Auto NAT:

After Auto NAT is the last NAT to be processed on the ASA. Since this is the last NAT to be processed, these are generally used as a catch all PAT type of NAT. Lets configure a PAT where we take our entire 192.168.5.0/24 Subnet and NAT (PAT) it to 83.24.5.35.

object network Inside-Subnet
subnet 192.168.5.0 255.255.255.0
object network Default-PAT-Outbound
host 83.24.5.35

nat (inside,outside) after-auto source dynamic Inside-Subnet Default-PAT-Outbound

Notice that this NAT looks a lot like the Manual NAT we did earlier except now we see the after-auto keyword. This is what makes a Manual NAT into an After-Auto NAT. I also changed the keyword static to dynamic which is what makes a NAT act as a PAT on the ASA. As with Auto-NAT, I will only cover PATs with After-Auto NATs as this is really the only time these should be used. Try to keep all of your more complicated NATs within Manual NATs since those are processed first and processed in configured order.

If you would like to know more or see more articles on NAT please let me know. You can contact me and I will do what I can to help.

The post Different ASA NATs 8.3+ appeared first on Think Netsec.

ASA Data Sheet

John Finnegan — Thu, 10 Aug 2017 19:41:53 +0000

The ASA Data Sheet can also be a little misleading so read carefully. You will see that Stateful Inspection throughput appears twice for each device. The one you should look at is Multi Protocol and not Max. Max is for UDP traffic only and not TCP packets which nearly every environment uses. You can see the different information at the bottom in the key.

Cisco ASA Model	ASA 5505 / Security Plus	ASA 5510 / Security Plus	ASA 5512-X / Security Plus	ASA 5515-X

Stateful Inspection throughput (max¹)	Up to 150 Mbps	Up to 300 Mbps	1 Gbps	1.2 Gbps
Stateful Inspection throughput (multiprotocol²)	–	–	500 Mbps	600 Mbps
Next-Generation throughput³ (multiprotocol)	–	–	200 Mbps	350 Mbps
IPS throughput⁴	Up to 75 Mbps with AIP SSC-5	Up to 150 Mbps with AIP SSM-10; 300 Mbps with AIP SSM-20	250 Mbps (Extra hardware module not required)	400 Mbps (Extra hardware module not required)
Concurrent sessions	10,000 /25,000	50,000 /130,000	100,000	250,000
Connections per second	4,000	9,000	10,000	15,000
Packets per second (64 byte)	85,000	190,000	450,000	500,000
3DES/AES VPN throughput⁵	100 Mbps	170 Mbps	200 Mbps	250 Mbps
Site-to-site and IPsec IKEv1 client VPN user sessions	25	250	250	250
AnyConnect or clientless VPN user sessions	25	250	250	250
Cisco Cloud Web Security users	25	75	100	250
VLANs	3 (trunking disabled) / 20 (trunking enabled)	50 / 100	50 / 100	100
High-availability support⁶	Not available	Not available; A/A and A/S	Not available; A/A and A/S	A/A and A/S
Integrated I/O	8-port FE with 2 Power over Ethernet (PoE) ports	5-port FE / 2-port 10/100/1000, 3-port FE	6-port 10/100/1000	6-port 10/100/1000
Expansion I/O	Not available	4-port 10/100/1000 or 4-port GE (SFP)	6-port 10/100/1000 or 6-port GE (SFP)	6-port 10/100/1000 or 6-port GE (SFP)
Dual power supplies	Not available	Not available	Not available	Not available
Power	AC/DC	AC/DC	AC/DC	AC/DC

Cisco ASA Model	ASA 5520	ASA 5525-X	ASA 5540	ASA 5545-X	ASA 5550	ASA 5555-X

Stateful Inspection throughput (max¹⁾	450 Mbps	2 Gbps	650 Mbps	3 Gbps	1.2 Gbps	4 Gbps
Stateful Inspection throughput (multiprotocol²⁾	–	1 Gbps	–	1.5 Gbps	–	2 Gbps
Next-Generation throughput³ (multiprotocol)	–	650 Mbps	–	1 Gbps	–	1.4 Gbps
IPS throughput⁴	Up to 225 Mbps with AIP SSM-10; 375 Mbps with AIP SSM-20; 450 Mbps with AIP SSM-40	600 Mbps (Extra hardware module not required)	Up to 500 Mbps with AIP SSM-20; 650 Mbps with AIP SSM-40	900 Mbps (Extra hardware module not required)	Not Available	1.3 Gbps (Extra hardware module not required)
Concurrent sessions	280,000	500,000	400,000	750,000	650,000	1,000,000
Connections per second	12,000	20,000	25,000	30,000	33,000	50,000
Packets per second (64 byte)	320,000	700,000	500,000	900,000	600,000	1,100,000
3DES/AES VPN throughput⁵	225 Mbps	300 Mbps	325 Mbps	400 Mbps	425 Mbps	700 Mbps
Site-to-site and IPsec IKEv1 client VPN user sessions	750	750	5,000	2,500	5,000	5,000
AnyConnect or clientless VPN user sessions	750	750	2,500	2,500	5,000	5,000
Cisco Cloud Web Security users	300	500	1,000	1,500	2,000	3,000
VLANs	150	200	200	300	400	500
High-availability support⁶	A/A and A/S	A/A and A/S	A/A and A/S	A/A and A/S	A/A and A/S	A/A and A/S
Integrated I/O	4-port 10/100/1000 and 1-port FE	8-port 10/100/1000	4-port 10/100/1000 + 1-port FE	8-port 10/100/1000	8-port 10/100/1000 + 1-port FE	8-port 10/100/1000
Expansion I/O	4-port 10/100/1000 or 4-port GE (SFP)	6-port 10/100/1000 or 6-port GE (SFP)	4-port 10/100/1000 or 4-port GE (SFP)	6-port 10/100/1000 or 6-port GE (SFP)	None	6-port 10/100/1000 or 6-port GE (SFP)
Dual Power Supplies	Not available	Not available	Not available	Not available	Not available	Yes
Power	AC/DC	AC/DC	AC/DC	AC/DC	AC/DC	AC/DC

Cisco ASA Model	ASA 5585-X with SSP10	ASA 5585-X with SSP20	ASA 5585-X with SSP40	ASA 5585-X with SSP60	ASA Services Module

Stateful Inspection throughput (max¹)	4 Gbps	10 Gbps	20 Gbps	40 Gbps	20 Gbps
Stateful Inspection throughput (multiprotocol²)	2 Gbps	5 Gbps	10 Gbps	20 Gbps	16 Gbps
Next-Generation throughput³ (multiprotocol)	2 Gbps (with ASA CX SSP-10)	5 Gbps (with ASA CX SSP-20)	Not available	Not available	Not available
IPS throughput⁴ (multiprotocol)	2 Gbps (with IPS SSP-10)	3 Gbps (with IPS SSP-20)	5 Gbps (with IPS SSP-40)	10 Gbps (with IPS SSP-60)	Not available
Concurrent sessions	1,000,000	2,000,000	4,000,000	10,000,000	10,000,000
Connections per second	50,000	125,000	200,000	350,000	300,000
Packets per second (64 byte)	1,500,000	3,000,000	5,000,000	9,000,000	5,000,000
3DES/AES VPN throughput⁵	1 Gbps	2 Gbps	3 Gbps	5 Gbps	2 Gbps
Site-to-site and IPsec IKEv1 client VPN user sessions	5,000	10,000	10,000	10,000	10,000
AnyConnect or clientless VPN user sessions	5,000	10,000	10,000	10,000	10,000
Cisco Cloud Web Security users	7,500	7,500	7,500	7,500	7,500
Integtrated I/O	8-port 10/100/1000 and 2-port 10 GE (SFP+)⁶	8-port 10/100/1000 and 2-port 10 GE (SFP+)⁶	6-port 10/100/1000 and 4-port 10 GE (SFP+)	6-port 10/100/1000 and 4-port 10 GE (SFP+)	Provided by the switch or router
Expansion I/O⁷	8-port 10 GE(SFP/SFP+) or 4-port 10 GE(SFP/SFP+) or 20-port 1 GE (12-port 1 GE SFP and 8-port 10/100/100)				Provided by the switch or router
Dual power supplies	Yes	Yes	Yes	Yes	Yes. Provided by the switch or router
VLANs	1,024	1,024	1,024	1,024	1,000
High-availability support⁸	1,024	1,024	1,024	1,024	1,000
Power	AC	AC	AC	AC	AC/DC provided by the switch or router

¹ Maximum throughput with UDP traffic measured under ideal test conditions
² Multiprotocol = Traffic profile consisting primarily of TCP-based protocols/applications like HTTP, SMTP, FTP, IMAPv4, BitTorrent, and DNS.
³Throughput was measured using ASA CX Software Release 9.1.1 with multi-protocol traffic profile with both Application Visibility Control (AVC) and Web Security Essentials (WSE). Traffic logging was enabled as well.
⁴ Firewall traffic that does not go through IPS SSP module can have higher throughput.
⁵ VPN throughput and sessions count depend on the ASA device configuration and VPN traffic patterns. These elements should be taken into consideration as part of your capacity planning.
⁶ Requires a separate license
⁷ Half-width modules
⁸ A/A = Active/Active; A/S = Active/Standby

This data was pulled from the following Cisco Article

The post ASA Data Sheet appeared first on Think Netsec.

Basic Site to Site (IKEv1)

John Finnegan — Thu, 03 Aug 2017 02:02:56 +0000

In this Article, we will be breaking down the right questions to ask when configuring a VPN and how to configure a Site to Site on the ASA.

ASA Version

The configuration of the Site to Site will be presented in different variations at the end of this Article. This is for those using either 7.x through 9.x code of the ASA as things are different between the code versions. I will start with 9 (8.3+) code since this should be the version most are running today and I will follow that up with 7.x-8.2. The Site to Site configuration between these code versions vary so I will present the same configuration in all variations between the code versions.

With all VPNs, we need to gather some information before we get started. Always ask the following as they are crucial to getting the VPNs configured correctly the first time. To jump straight to configuration, click here.

Is the remote side requesting Route Based or Policy Based VPNs?

This is helpful to understand first and foremost your limitations. Until 9.7+, the ASA was not capable of performing a true Route Based VPN. The ASA was only capable of performing Policy Based VPNs but there is always ways to kind of get around those limitations but we will cover that in another Article. For now, if the answer is Policy Based, move on to the next question.

What is the Peer IP?

We need to know the IP of the other VPN Concentrator at the other end. It is also helpful to know if this device is behind a NAT device. That means the devices IP address would actually be a Private IP and would have to be NAT’d to reach your ASA. If this is the case, issues could arise based on the Router settings in front of the device and how the device sends its Identity to your ASA. In most cases, you will be creating the Tunnel Group based on their Public IP so it is good to make sure that this is the Identity (IP) coming from their device to build the tunnel. You should also ask that the other side has NAT-Traversal and IPsec passthrough configured on their edge Router in this particular case as well.

What is the Authentication Method?

Authentication Method is usually a pre-shared-key (password) that the Remote side will share with you. You need to make sure that you have the same password so that you both have the same key on both ends. Sometimes, a Remote client will ask for RSA Certificates instead of pre-shared-keys but that is for another discussion.

If the answer to this question is pre-shared-key then you will need to find the best way to share this key with each other so that you can configure this on your ASA for their Peer IP.

What are the Phase 1 Settings?

With these settings, it is not necessary to understand each one in detail. All we need to do is make sure that our values match on both sides. I will do my best to provide a little bit of detail if you wish to pick the best for your needs but, in the end, your goal should be to match these values. All values in red are the default values that will be used when you create a policy.

Encryption: des | 3des | aes-128 | aes-192 | aes-256

The encryption is the way you plan on locking your data. The longer the bits, the harder it is to break the key. That is really oversimplifying encryption but in the end, it is easier to remember that the higher the bits, generally the safer/stronger it is. (The above is not in bit order, just encryption type then bit order. des is 64 bit and 3des is 192 bits)

Hash: md5 | sha-1

These are used for authenticating the source of an IP packet and verifying the integrity of its content. The VPN device will generate a hash and send it to the remote VPN device. It will use this to compare the hashes to check for packet integrity along with authenticating the remote device. If this value changes, then it can assume the segment was altered. As for which to choose for yourself, md5 has been broken before so I would recommend using sha-1. Now, md5 is faster to compute then sha-1 but usually this is negligible in network performance. Again, in the end, your goal should be to match the other sides settings.

Diffie-Helman (DH): 1 | 2 | 5 | 7

DH is used for the key exchange between your ASA and the Remote device. The larger the number, the more bits that are used, which in turn makes it that much more secure. Now, with that in mind, the larger the number, the longer the processing to use the keys. As always, we are just trying to match the other sides configuration for the most part so do not think too much into these values.

Lifetime(Seconds): 120 – 2147483647 (86400)

Lifetime is the amount of time Phase 1 will stay active until it needs to re-key the tunnel. You always want this value greater then the lifetime that you will use in Phase 2.

What are the Phase 2 Settings?

Phase 2 is the Second tunnel that will be built within the Phase 1 tunnel. If you have multiple networks that will be communicating with the remote side, each will get their own Phase 2. In most cases, every network combination will use the exact same Phase 2 settings. You will notice that the questions we need for Phase 2 are very similar to that of Phase 1 but do have some slight additions and options.

You will see your options above are the same as they were in Phase 1, except for the esp keyword and null. The esp keyword is just letting you know that this being used on a ESP packet, which is what IPSec sends once traffic is encrypted. Encapsulating Security Payload (ESP) is its own protocol so it is not TCP or UDP so make sure the other side is allowing this protocol to their device. As for null, this means you can actually apply no Encryption on Phase 2 if you wish to do so but most never use this option.

Hash: esp-md5-hmac | esp-sha-hmac | esp-none

Again, we see that esp keyword but this just means this is being used on a ESP packet. As for hmac, this stands for ‘hash message authentication code’ but this just means it is using this a hashing authentication mechanism. You will notice that there is a none option now. This is if you wish to not add a HMAC to the Phase 2 Tunnels which could hinder security a little but would allow for faster processing. In the end, we just need to match this setting to what the remote location is using.

Diffie-Helman (DH): 1 | 2 | 5 | Not Available

DH is not required in Phase 2 and is allowed to be omitted. This is an optional addition and gets referenced as Perfect Forward Secrecy (PFS) in most cases. This will allow for each Phase 2 Tunnel to generate their own keys. This does mean more security but also adds more computing cycles that your ASA will have to go through per packet.

Lifetime(Seconds): 120 – 2147483647 (28800)

Amount of time that Phase 2 can stay active before it needs to re-key the Phase 2 tunnel. This value should be lower then your Lifetime in Phase 1.

Lifetime(Kilobytes): 10 – 2147483647 | Unlimited (4608000)

Kilobyte Lifetime is a lifetime value that was not available in Phase 1. Just as the Lifetime(Seconds), this will tell the ASA how much data can go over the Phase 2 Tunnel before the Phase 2 Tunnel needs to perform a re-key. In this case, which ever Lifetime (Seconds or Kilobytes) is met first, the Tunnel will re-key. You can also set this value to Unlimited which will, in essence, turn this feature off. This comes in handy since some remote devices do not Support Kilobyte Lifetimes.

What is the Encryption Domain?

Lastly, we need to know the interesting traffic that will be traversing this VPN Tunnel. We need to match these exactly on both sides or issues will arise. Each Source and Destination Network combination will build their own Phase 2 Tunnel. All we need to know on the ASA is to configure an ACL of our Local Source Networks to the Remote Destination Networks. Note, that if your Netmasks are off, that the tunnel may sometimes build but not in all scenarios.

For example, if we have a 192.168.100.0/24 configured as our Local Network.If the Remote side configures our Network as 192.168.100.0/22 on their side of the VPN, only our Local ASA will be able to build the Phase 2 VPN Tunnel for that network. This is because our /24 range fits inside of their /22 IP range. Their device will accept our proposal and build with our /24, even though they have /22 configure. The reverse, however, would not work since their /22 is larger the our configured /24.

Building the Site to Site VPN

Now that we have gotten most of our questions out of the way, we can begin configuring the ASA for the new Site to Site.

We will use the following as an example configuration with the following answers.

Policy Based VPN

Peer IP: 50.56.228.50
Pre-shared-key: Th1nkN3t$ec
Phase 1-
   Encryption: aes-128
   Hash: sha-1
   DH Group: 2
   Lifetime: 86400

Phase 2-
   Encryption: esp-aes-256
   Hash: esp-sha-hmac
   PFS (DH): NA
   Lifetime (s): 28800
   Lifetime (k): 4608000

Encryption Domain:
   Local: 192.168.100.0/22
   Remote: 172.16.240.0/24

Our Public IP for this tunnel (their peer IP) will be 50.57.228.150

ASA Code 9.x (8.3+)

I will be using a Crypto map called MyVPNMap but use the crypto map already configured on your device. If you do not have one, then please pick which ever map name works best for you. I will also be referencing my Internal Network name as INSIDE and my Outbound interface as OUTSIDE but please change these to match your device.

I like to first create my ACL that will be used as our Encryption Domain. We will also be creating object-groups for our Local and Remote Networks which will be useful for making changes later to the VPN and NAT.

object-group network MyVPN-LOCAL
 network-object 192.168.100.0 255.255.255.0

object-group network MyVPN-REMOTE
 network-object 172.16.240.0 255.255.255.0

access-list MyVPN extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE

Now that we have created our object-groups and ACL, we should create our Identity NAT for our Encryption Domain. This is to ensure that communication does not try to use any NATs that may prevent this traffic from traversing the tunnel. (Default PAT Outbound for example). If you do not understand the NAT below, do not worry too much. I do have a Article that breaks down NAT if you wish to understand more but for now, I would recommend using the NAT below in most cases.

nat (INSIDE,OUTSIDE) source static MyVPN-LOCAL MyVPN-LOCAL destination static MyVPN-REMOTE MyVPN-REMOTE no-proxy-arp route-lookup

With our NAT and ACL now configured, we will add our Phase 1 configuration for the VPN. Notice I set my policy as 100 but any value here will work so long as you are not overriding an existing policy.

crypto ikev1 policy 100
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 86400

To complete the Phase 1 configuration, we will create our Tunnel-group so that we can bind our pre-shared-key with our Peer IP.

tunnel-group 50.56.228.50 type ipsec-l2l
tunnel-group 50.56.228.50 ipsec-attributes
 ikev1 pre-shared-key Th1nkN3t$ec

With all of Phase 1 completed on your ASA, we will create our Transform Set (Phase 2 Encryption and Hash) for the VPN.

crypto ipsec ikev1 transform-set AES256-SHA esp-aes-256 esp-sha-hmac

Next, we will complete the VPN by configuring our Crypto map. Our Crypto map will bind our ACL and Phase 2 settings together with the Peer IP.

crypto map MyVPNMap 100 match address MyVPN
crypto map MyVPNMap 100 set peer 50.56.228.50
crypto map MyVPNMap 100 set ikev1 transform-set AES256-SHA

If this is your first VPN on your ASA, you will need to enable IKEv1, set you Identity to your ASAs IP address and bind your new Crypto Map to your Outside interface.

crypto map MyVPNMap interface OUTSIDE
crypto isakmp identity address
crypto ikev1 enable OUTSIDE

When the Remote side has completed their end of the VPN, you should be able to bring the Tunnel up and pass traffic if al routing etc is already accurate.

Here is all of the configuration for 8.3+ below in one snippet.

object-group network MyVPN-LOCAL
 network-object 192.168.100.0 255.255.255.0

object-group network MyVPN-REMOTE
 network-object 172.16.240.0 255.255.255.0

access-list MyVPN extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE

nat (INSIDE,OUTSIDE) source static MyVPN-LOCAL MyVPN-LOCAL destination static MyVPN-REMOTE MyVPN-REMOTE no-proxy-arp route-lookup

crypto ikev1 policy 100
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 86400

tunnel-group 50.56.228.50 type ipsec-l2l
tunnel-group 50.56.228.50 ipsec-attributes
 ikev1 pre-shared-key Th1nkN3t$ec

crypto ipsec ikev1 transform-set AES256-SHA esp-aes-256 esp-sha-hmac

crypto map MyVPNMap 100 match address MyVPN
crypto map MyVPNMap 100 set peer 50.56.228.50
crypto map MyVPNMap 100 set ikev1 transform-set AES256-SHA

! Only do the following if this is your first VPN

crypto map MyVPNMap interface OUTSIDE
crypto isakmp identity address
crypto ikev1 enable OUTSIDE

ASA 8.0-8.2 Code

object-group network MyVPN-LOCAL
 network-object 192.168.100.0 255.255.255.0

object-group network MyVPN-REMOTE
 network-object 172.16.240.0 255.255.255.0

access-list MyVPN extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE

! This is an ACL used to prevent NAT from occurring.
access-list nonat extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE

! This is where we bind the above 'nonat' ACL to state that this traffic is to be excluded from NAT
nat (INSIDE) 0 access-list nonat

crypto isakmp policy 100
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 86400

tunnel-group 50.56.228.50 type ipsec-l2l
tunnel-group 50.56.228.50 ipsec-attributes
 pre-shared-key Th1nkN3t$ec

crypto ipsec transform-set AES256-SHA esp-aes-256 esp-sha-hmac

crypto map MyVPNMap 100 match address MyVPN
crypto map MyVPNMap 100 set peer 50.56.228.50
crypto map MyVPNMap 100 set transform-set AES256-SHA

! Only do the following if this is your first VPN

crypto map MyVPNMap interface OUTSIDE
crypto isakmp identity address
crypto enable OUTSIDE

ASA 7.x Code

object-group network MyVPN-LOCAL network-object 192.168.100.0 255.255.255.0 
object-group network MyVPN-REMOTE network-object 172.16.240.0 255.255.255.0 
access-list MyVPN extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE

! This is an ACL used to prevent NAT from occurring. 
access-list nonat extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE

! This is where we bind the above 'nonat' ACL to state that this traffic is to be excluded from NAT 
nat (INSIDE) 0 access-list nonat

crypto isakmp policy 100 
authentication pre-share 
ncryption aes 
hash sha 
group 2 
lifetime 86400

! This is the same as the tunnel-group command in the other code versions
isakmp key Th1nkN3t$ec address 50.56.228.50 netmask 255.255.255.255 no-xauth
 
crypto ipsec transform-set AES256-SHA esp-aes-256 esp-sha-hmac 
crypto map MyVPNMap 100 ipsec-isakmp
crypto map MyVPNMap 100 match address MyVPN 
crypto map MyVPNMap 100 set peer 50.56.228.50 
crypto map MyVPNMap 100 set transform-set AES256-SHA

! Only do the following if this is your first VPN 
crypto map MyVPNMap interface OUTSIDE 
crypto isakmp identity address 
isakmp enable OUTSIDE

The post Basic Site to Site (IKEv1) appeared first on Think Netsec.