cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
984
Views
35
Helpful
12
Replies

Split Tunnel Config using Group Policy. Please help.

Hello.

Goal: Configure a VPN From 1.1.1.1 (inside LAN-1 subnet 192.168.1.0/24), to 2.2.2.2 (with LAN inside subnet 10.1.1.0/24.). All other traffic in both directions should not travel through the VPN, but through the regular www gateways.

I must use a Group Policy configuration, so I cannot use "no sysopt connection permit-vpn".

This is my first configuration using Group Policy with a VPN, so I don't want to accidentally destroy the enterprise production network configuration. May you please inspect the below configuration, and reveal to me the faults?

I appreciate your effort. Thank you!!
==========================================

1. Enable IKE processing on the outside interface "outside1" 1.1.1.1 .
#crypto ikev2 enable outside1

2. Create the ISAKMP policy (** is this redundant/incorrect with the line within step 9? **).
#crypto ikev2 policy 100
#encryption aes-256
#integrity sha-256
#group 14
#prf sha-256
#lifetime seconds 86400

3. Set tunnel group and tunnel type.
#tunnel-group 2.2.2.2 type ipsec l2l
#tunnel group 2.2.2.2 ipsec-attributes
#ikev2 remote-authentication pre-shared-key $My-kEy$
#ikev2 local-authentication pre-shared-key $My-kEy$

4. Define the IPsec policy.
#crypto ipsec ikev2 ipsec-proposal MY-PROPOSAL-1
#protocol esp encryption aes-256
#protocol esp integrity sha-512

5. Create the ACL for crypto map OUTSIDE_IN.
#access-list OUTSIDE_IN line 1 remark >>ACL REFERENCED BY CRYPTO-MAP<<
#access-list OUTSIDE_IN line 5 extended permit ip 10.1.1.0 255.255.255.0 192.168.1.0 255.255.255.0

6. Configure the crypto map.
#crypto map CLIENT1-cryptomap-1 interface outside1
#crypto map CLIENT1-cryptomap-1 1 match address OUTSIDE_IN
#crypto map CLIENT1-cryptomap-1 1 set peer 2.2.2.2
#crypto map CLIENT1-cryptomap-1 1 set ikev2 ipsec-proposal MY-PROPOSAL-1

7. Bypass NAT.
#object network MY-LAN-SERVER-1
#subnet 192.168.1.0 255.255.255.0
#object network CLIENT1-LAN-SERVER-1
#subnet 10.1.1.0 255.255.255.0
#exit
#nat (inside,outside) source static MY-LAN-SERVER-1 CLIENT-LAN-SERVER-1 destination static MY-LAN-SERVER-1 CLIENT-LAN-SERVER-1

8. Configure Internal Group Policy & attributes.
#group-policy 2.2.2.2 internal
#group-policy 2.2.2.2 attributes
#vpn-filter CLIENT_VPN_FILTER_ACL-1
***Is this Redundant from Step 3?**   #vpn-tunnel-protocol ikev2

#pfs enable
#split-tunnel-policy tunnelspecified
#split-tunnel-network-list CLIENT1_SPLIT_TUNNEL_NETWORK_LIST_ACL-1

9. Create the ACL for MY_CLIENT1_VPN_FILTER_ACL-1.
#access-list MY_CLIENT_VPN_FILTER_ACL-1 extended
#10 permit ip 10.1.1.0 255.255.255.0 192.168.1.0 255.255.255.0

10. Create the (special logic) ACL for MY_CLIENT_SPLIT_TUNNEL_NETWORK_LIST_ACL-1.
#access-list MY_CLIENT_SPLIT_TUNNEL_NETWORK_LIST_ACL-1
#10 permit 192.168.1.0 255.255.255.0

2 Accepted Solutions

Accepted Solutions

***Is this Redundant from Step 3?***>>   #vpn-tunnel-protocol ikev2 
NO this another secure feature, 
assume you have 100 user in remote LAN, and you want 50 user to access serverA and other 50 not access serverA, 
you will use VPN filter here. 

#nat (inside,outside) source static MY-LAN-SERVER-1 CLIENT-LAN-SERVER-1 destination static MY-LAN-SERVER-1 CLIENT-LAN-SERVER-1

this wrong 
if your local is  MY-LAN-SERVER-1
and remote is CLIENT-LAN-SERVER-1
then 

#nat (inside,outside) source static MY-LAN-SERVER-1 MY-LAN-SERVER-1  destination static  CLIENT-LAN-SERVER-1 CLIENT-LAN-SERVER-1

View solution in original post

@jmaxwellUSAF the crypto ACL (the ACL referenced in the crypto map) purely defines what traffic is to be encrypted, don't confuse it with restricting traffic as per a normal ACL. This is bi-directional, so you don't need to permit the return traffic (reverse logic). 

So in you scenario traffic from 192.168.1.0/24 to/from 10.1.1.0/24 would be encrypted.

View solution in original post

12 Replies 12

@jmaxwellUSAF you don't need a split tunnel ACL on a Site-to-Site VPN, only traffic defined in the crypto ACL will be encrypted and routed over the VPN tunnel.

Traffic not defined in the crypto ACL will break out locally.

You guys are so helpful. Thank you!

you add this config and remove it in your last post, so I didnot get time to reply to you. 
there is NO SPLIT-ACL in S2S VPN the SPLIT-ACL is only in remote access VPN.

MHM you are so helpful. Thank you!

https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/107596-asa-reverseroute.html

this example help you to get the idea of 
1- split ACL for remote access 
2- RRI for S2S VPN (reverse route inject )

OK, I deleted the split tunnel part of the config.

This is my 1st time using group policy and ASA command line.

1. May you please tell me if this config looks OK?

2. I must do the "reverse" configuration, including ACL's, on the opposite side, correct?

3. How do I correct line 2 and line 9 so that there is no redundancy? What is the commands/syntax?

THANK YOU!!

======================================================

1. Enable IKE processing on the outside interface "outside1" 1.1.1.1 .
#crypto ikev2 enable outside1

2. Create the ISAKMP policy        <<(** is this redundant/incorrect with the line within Step 9? Should this list under group policy? If so, what is the syntax? **)
#crypto ikev2 policy 100
#encryption aes-256
#integrity sha-256
#group 14
#prf sha-256
#lifetime seconds 86400

3. Set tunnel group and tunnel type.
#tunnel-group 2.2.2.2 type ipsec l2l
#tunnel group 2.2.2.2 ipsec-attributes
#ikev2 remote-authentication pre-shared-key $My-kEy$
#ikev2 local-authentication pre-shared-key $My-kEy$

4. Define the IPsec policy.
#crypto ipsec ikev2 ipsec-proposal MY-PROPOSAL-1
#protocol esp encryption aes-256
#protocol esp integrity sha-512

5. Create the ACL for crypto map OUTSIDE_IN.
#access-list OUTSIDE_IN line 1 remark >>ACL REFERENCED BY CRYPTO-MAP<<
#access-list OUTSIDE_IN line 5 extended permit ip 10.1.1.0 255.255.255.0 192.168.1.0 255.255.255.0

6. Configure the crypto map.
#crypto map CLIENT1-cryptomap-1 interface outside1
#crypto map CLIENT1-cryptomap-1 1 match address OUTSIDE_IN
#crypto map CLIENT1-cryptomap-1 1 set peer 2.2.2.2
#crypto map CLIENT1-cryptomap-1 1 set ikev2 ipsec-proposal MY-PROPOSAL-1

7. Bypass NAT.
#object network MY-LAN-SERVER-1
#subnet 192.168.1.0 255.255.255.0
#object network CLIENT1-LAN-SERVER-1
#subnet 10.1.1.0 255.255.255.0
#exit
#nat (inside,outside) source static MY-LAN-SERVER-1 CLIENT-LAN-SERVER-1 destination static MY-LAN-SERVER-1 CLIENT-LAN-SERVER-1

8. Configure Internal Group Policy & attributes.
#group-policy 2.2.2.2 internal
#group-policy 2.2.2.2 attributes
#vpn-filter CLIENT_VPN_FILTER_ACL-1
***Is this Redundant from Step 3?***>>   #vpn-tunnel-protocol ikev2

#pfs enable

9. Create the ACL for MY_CLIENT1_VPN_FILTER_ACL-1.
#access-list MY_CLIENT_VPN_FILTER_ACL-1 extended
#10 permit ip 10.1.1.0 255.255.255.0 192.168.1.0 255.255.255.0

@jmaxwellUSAF yes, you need step 2 - this policy needs to match what the peer device is configured for.

You crypto ACL is incorrect if your network is 192.168.1.0/24 - it should be the other way around. - "access-list OUTSIDE_IN line 5 extended permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0"

You need to define "vpn-trunnel-protocol ikev2" otherwise IKEv2 will not be permitted - although if enabled on the default group-policy it would inherit.

I wouldn't call the crypto ACL "OUTSIDE_IN" - that could be confusing, I'd call it "CLIENT1_VPN" of something unique for that VPN tunnel.

"You crypto ACL is incorrect if your network is 192.168.1.0/24 - it should be the other way around. - "access-list OUTSIDE_IN line 5 extended permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0"

1. My understanding is: If this currently configured map is placed on the outside interface of the local ASA, the ACE as written permits the source (remote) inside network 192.168.1.0 traffic to enter the destination (local) internal network 10.1.1.0. If this is incorrect, may you please explain what is the incorrect logic?

2. Must I also create a second ACL, with reverse logic, and place it on the same interface, but with direction out? (I didn't see this step in the Cisco literature)?

Thank you Rob.

@jmaxwellUSAF the crypto ACL (the ACL referenced in the crypto map) purely defines what traffic is to be encrypted, don't confuse it with restricting traffic as per a normal ACL. This is bi-directional, so you don't need to permit the return traffic (reverse logic). 

So in you scenario traffic from 192.168.1.0/24 to/from 10.1.1.0/24 would be encrypted.

***Is this Redundant from Step 3?***>>   #vpn-tunnel-protocol ikev2 
NO this another secure feature, 
assume you have 100 user in remote LAN, and you want 50 user to access serverA and other 50 not access serverA, 
you will use VPN filter here. 

#nat (inside,outside) source static MY-LAN-SERVER-1 CLIENT-LAN-SERVER-1 destination static MY-LAN-SERVER-1 CLIENT-LAN-SERVER-1

this wrong 
if your local is  MY-LAN-SERVER-1
and remote is CLIENT-LAN-SERVER-1
then 

#nat (inside,outside) source static MY-LAN-SERVER-1 MY-LAN-SERVER-1  destination static  CLIENT-LAN-SERVER-1 CLIENT-LAN-SERVER-1

I'm ready to implement this tunnel. Thank you so much folks, you guys truly help the world.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: