cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5025
Views
0
Helpful
5
Replies

Split Tunnel VPN access list question

twhittle1
Level 1
Level 1

Hi all,

I am busy configuring up my 871 for remote access and my split tunnel VPN working fine and dandy however I'm not exactly why...

I've followed the below Cisco guide which works great:

http://www.cisco.com/en/US/products/hw/routers/ps274/products_configuration_example09186a0080819289.shtml

But here is my question...

The access list which specifies which VPN traffic should be encrypted is below:

access-list 101 permit ip 10.10.10.0 0.0.0.255 192.168.1.0 0.0.0.255

and it's applied in the client configuration group:

crypto isakmp client configuration group vpnclient
 key cisco123
 dns 10.10.10.10
 wins 10.10.10.20
 domain cisco.com
 pool ippool
 acl 101

but why does this access list work?

I read it as permit all ip traffic from 10.10.10.0/24 (internal traffic) to 192.168.1.0/24 (split tunnel vpn endpoints). So wouldn't this mean all traffic from the internal LAN to Split tunnel endpoints is encrypted by the VPN tunnel. But surely it should be the other way around? A split tunnel VPN should encrpyt all traffic from the VPN client to the internal LAN, and all the other traffic should go out to the internet unencrypted?

What am I missing here? Can anyone shed any light?

Many Thanks,

Tom Whittle

1 Accepted Solution

Accepted Solutions

ACLs are used in several IOS features. Not all ACLs are interpreted as srcnet-srcmask-dstnet-dstmask. For example

  • route redistribution ACL in route-map have a structure of network-netwildcard-mask-maskwildcard
  • VPN filter ACLs have a structure of remotenet-remotemask-localnet-localmask
  • split tunnel ACLs have a structure of localnet-localmask-ignore-ignore

My split tunnel ACL in this blogpost is

ip access-list extended EZsplit
 permit ip 10.54.0.0 0.1.255.255 any

In split tunnel ACLs only the first half is relevant. The second half can be left as any.

View solution in original post

5 Replies 5

jeff slansky
Level 1
Level 1

im an uber novice but here is what i believe to be correct. if someone knows more than me please correct me.

in a split tunnel scenario, web based traffice doesn't go to the home site. it goes straight out to the internet, in which case it would not be encrypted because there is nothing on the other end to know how to decrypt it.

all non web based traffic goes to the node you are connected to and will be encrypted.

if you are trying to setup a home network with a pix i might be able to save you a ton of time by giving you my config.

kevin

Hi Kevin,

Many thanks for your reply, I am in agreement with you, which is sort of what puzzles me

If you follow the above link it gives the full scenario, but in short here is the topology used, which shows the 10.10.10.0/24 subnet as internal and in the document it describes the 192.168.1.0/24 subnet as client VPN pool.rtr-ipsec-internet-connect-1.gif

The piece that confuses me is the access list. Because I would expect the access to be: permit traffic from VPN clients to the internal LAN and deny everything else. When you apply this ACL to the client group configuration is should permit tarffic from VPN clients to the internal LAN I.E. encrypt this traffic) and then deny all other (I.E. don't encrypt the rest). However the Access list is the other way around:

access-list 101 permit ip 10.10.10.0 0.0.0.255 192.168.1.0 0.0.0.255

As you can see it is permitting the LAN subnet towards the VPN client subnet, and I'm just not sure why.

Maybe it's just a case of "just because" and if that's the case then fair enough, but I'd just like to know.

Thanks for the offer of the PIX config, I'm using a 871 at home so it won't help in this instance

Regards,

Tom

i am not a guru. i would have to look at my config to understand it. i am not at home so i can't get it, but

the command reference says this:

[no] access-list id [line line-num] {deny | permit}{protocol | object-group protocol_obj_grp_id {source_addr source_mask} | object-group network_obj_grp_id [operator port [port] | interface if_name | object-group service_obj_grp_id] {destination_addr | remote_addr} {destination_mask | remote_mask} | object-group network_obj_grp_id [operator port [port] | object-group service_obj_grp_id]} [log [[disable | default] | [level]]] [interval secs]]

are you sure you are looking at the command and the direction of the syntax and the picture correctly?

the ios versions are very similiar to each other. you may find benefit in it. the syntax may be slightly different but ultimately it could be very beneficial to you.

jeff

ACLs are used in several IOS features. Not all ACLs are interpreted as srcnet-srcmask-dstnet-dstmask. For example

  • route redistribution ACL in route-map have a structure of network-netwildcard-mask-maskwildcard
  • VPN filter ACLs have a structure of remotenet-remotemask-localnet-localmask
  • split tunnel ACLs have a structure of localnet-localmask-ignore-ignore

My split tunnel ACL in this blogpost is

ip access-list extended EZsplit
 permit ip 10.54.0.0 0.1.255.255 any

In split tunnel ACLs only the first half is relevant. The second half can be left as any.

Poonam Garg
Level 3
Level 3

Hi Tom,

Split tunnel ACL defined under the group is always from server point of view. It is the source not the destination subnet.

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: