cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
912
Views
20
Helpful
6
Replies

ASA group-policy split-tunnel ACL: Cisco instructions seem illogical..

Hello.

I need to configure an ASA 5525 group-policy split-tunnel ACL, but the Cisco instructions seem illogical.

Only traffic from 192.168.1.1   to   10.1.1.1 should travel through the VPN, and www traffic should travel through the remote user's www untunneled gateway. Yet the below instructions from "vpn_groups.pdf" seem to state that I'm supposed to list the 10.1.1.1 destination as the source.

May you please clarify this confusion? Thank you!

_____

Cisco ASA 5500 Series Configuration Guide using the CLI
Chapter 67 Configuring Connection Profiles, Group Policies, and Users
Group Policies
Split tunneling network lists distinguish networks that require traffic to travel across the tunnel from
those that do not require tunneling. The ASA makes split tunneling decisions on the basis of a network
list, which is an ACL that consists of a list of addresses on the private network.
If you use extended ACLs, the source network determines the split-tunneling network. The destination
network is ignored. In addition, because any is not an actual IP address or network address, do not use
the term for the source in the ACL.

1 Accepted Solution

Accepted Solutions

Ok, it seems you are talking about a LAN-2-LAN connection and not about Remote-Access VPNs. Split Tunneling is a construct for Remote-Access VPNs and not for L2L. In the config you prepared, the ACL that you reference in the crypto map would be the part that you thought Split-Tunneling would be.

Even better, configure a VTI-based VPN and just route the two IPs through the tunnel:

https://tayam-infra.net/asa-route-based-ipsec-vpn-with-ikev2/

View solution in original post

6 Replies 6

The logic behind Split-Tunneling is that the function is pretty simple. It is completely controlled by routing on the client. That is the reason only the source-entry of the ACL is used to decide if a packet is sent to the tunnel or not. It is just destination IP-based and all ports are ignored. With that you "send www-traffic locally" will not work. IMO it was a bad decision to allow the usage of extended ACLs as this causes a lot of confusion.

So my STANDARD ACL entry to instruct: "Only traffic from 192.168.1.1 to destination 10.1.1.1 should travel through the VPN, and www traffic should travel through the remote user's www untunneled gateway" is this?...

#access-list SPLIT-TUNNEL-ACL

#10 permit 10.1.1.1 255.255.255.255

...and that's it?

the split-acl is config in ASA but it use by client. 
so the client see destination IP which is source in view of ASA.
the split-acl is use by client not as acl but as route, 
the route will be 
ip route <source in view of ASA> <first IP of VPN Pool> <<- the next-hop is first IP of VPN Pool. 
and also 
the client add 
ip route 0.0.0.0 0.0.0.0 <IP of NIC the client use>

No, what you want can not be achieved with split-tunnelling. First, the IP 192.168.1.1 is not evaluated. The source of the controlled communication is always the IP that got assigned to the client which could be IP A today and IP B tomorrow. And with this ACL *all* traffic for 10.1.1.1 will be sent through the tunnel, also for www traffic.

My goal is to erect a VPN from 1.1.1.1 (with LAN-1 server 192.168.1.1), to 2.2.2.2 (with LAN-2 server 10.1.1.1.). All other traffic in both directions should travel NOT through the VPN, but through the regular www gateways.

My first configuration did not use a Group Policy, so I was using the split-tunnel technique with the command "no sysopt connection permit-vpn".
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 strongly suspect I am making mistakes. I expect parts of the below code are redundant, and also incorrect.

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.1 255.255.255.255 192.168.1.1 255.255.255.255

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.1 255.255.255.255
#object network CLIENT1-LAN-SERVER-1
#subnet 10.1.1.1 255.255.255.1
#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.1 255.255.255.255 192.168.1.1 255.255.255.255

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.1 255.255.255.255

Ok, it seems you are talking about a LAN-2-LAN connection and not about Remote-Access VPNs. Split Tunneling is a construct for Remote-Access VPNs and not for L2L. In the config you prepared, the ACL that you reference in the crypto map would be the part that you thought Split-Tunneling would be.

Even better, configure a VTI-based VPN and just route the two IPs through the tunnel:

https://tayam-infra.net/asa-route-based-ipsec-vpn-with-ikev2/