RE: OT: ASA Split-Tunnels

From: Timothy Chin <tim_at_1csol.com>
Date: Tue, 06 Sep 2011 10:01:20 -0400

You can still get creative in the ASA with regular masks. I've done
configurations where I had to split even and odd nets doing a config
like:

 

nat (inside) 10 10.1.0.0 255.255.1.0

nat (inside) 11 10.1.1.0 255.255.1.0

 

global (outside) 10 x.x.x.92

global (outside) 11 x.x.x.91

 

Timothy Chin

CCIE #23866

________________________________

From: Joe Astorino [mailto:joeastorino1982_at_gmail.com]
Sent: Tuesday, September 06, 2011 9:54 AM
To: Brad Edgeworth
Cc: Ryan West; Sadiq Yakasai; Timothy Chin; Cisco certification
Subject: Re: OT: ASA Split-Tunnels

 

Thanks Brad. I fear I still have a problem though, because my home
network is 10.1.0.0/16 but the corporate network uses address space in
all three of the RFC1918 allocations. So, if I used an exclusion like
you have done I would have to find a way to exclude 10.0.0.0/8,
172.16.0.0/12, and 192.168.0.0/16 but not exclude 10.1.0.0/16 at the
same time and THAT is my problem here.

Too bad ASA ACLs don't use wildcard masks or I could get creative
there....

On Tue, Sep 6, 2011 at 9:49 AM, Brad Edgeworth <edgie512_at_gmail.com>
wrote:

Joe, that is correct... I used to do the same thing to allow me to
keep a VPN connection up to my home network (while at work) and still
access work resources (& bypass corporate Internet proxies...) :-)

 

Here is a snippet of relevant config on my Home ASA.

         

        group-policy GP_SVC_SPLIT_EXCEPT attributes

         banner value This is SPLIT-TUNNELLED-EXCEPT.

         split-tunnel-policy excludespecified

         split-tunnel-network-list value ANYCONNECT_SPLITTUNNEL_EXCEPT

         

        access-list ANYCONNECT_SPLITTUNNEL_EXCEPT standard permit
10.0.0.0 255.0.0.0

         

 

My corporate space was 10.0.0.0/8 & my home space was 192.168.0.0/16

 

-Brad

 

  

On Tue, Sep 6, 2011 at 8:32 AM, Joe Astorino <joeastorino1982_at_gmail.com>
wrote:

 

        Thanks for the feedback. I'm not sure I'm following you though.
Let's make

        sure we are on the same page

         

        The network I want to access behind the ASA is 10.1.0.0/16. I
also want to

        tunnel through the ASA for internet access. The corporate
network I am

        accessing the VPN from is the rest of the RFC1918 space. I want
to be able

        to remain connected to corporate resources while at the same
time tunnel

        traffic to 10.1.0.0/16 and the internet.

         

        When you say "interesting traffic ACL" do you mean the ACL used
for the

        split tunnel? This is remote access VPN so I'm not sure I
follow.

        Secondly, if I used a VPN filter, wouldn't that just block the
traffic after

        it was already tunneled to the ASA?

         

        On Tue, Sep 6, 2011 at 9:24 AM, Ryan West <rwest_at_zyedge.com>
wrote:

         

> I've done interesting traffic acls like this. You could us a
vpn-filter to

> block the traffic.

>

> Sent from handheld

>

> On Sep 6, 2011, at 8:17 AM, Sadiq Yakasai
<sadiqtanko_at_gmail.com> wrote:

>

> > Right, you are right - my memory must be getting foggy on
it. Thanks!

> >

> > On Tue, Sep 6, 2011 at 2:06 PM, Timothy Chin <tim_at_1csol.com>
wrote:

> >

> >> I don't think an extended ACL is required for split
tunnels. I've

> >> configured them using standard ACLs with no problems.

> >>

> >> Timothy Chin

> >> CCIE #23866

> >>

> >> -----Original Message-----

> >> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com]
On Behalf Of

> >> Sadiq Yakasai

> >> Sent: Tuesday, September 06, 2011 9:02 AM

> >> To: Joe Astorino

> >> Cc: Cisco certification

> >> Subject: Re: OT: ASA Split-Tunnels

> >>

> >> Hi Joe,

> >>

> >> First, to split-tunnel, you require an extended ACL.

> >>

> >> Secondly, can you be abit more informative with the
topology please? Are

> >> you

> >> terminating the SSL on the outside? But the split tunnelled
networks sit

> >> on

> >> the "inside" of the ASA" I havent worked this one out from
your post.

> >>

> >> Below is an example:

> >>

> >> access-list SPLIT_TUNNEL extended permit ip 132.1.0.0
255.255.0.0 any

> >> access-list SPLIT_TUNNEL extended permit ip 150.1.0.0
255.255.0.0 any

> >>

> >> This would basically funnels these networks through the
tunnel.

> >> Everything

> >> else does NOT go through the tunnel. If you do not specify
an ACL, then

> >> everything goes through the tunnel. You do not put deny
statements in

> >> the

> >> ACL (to exclude networks via the tunnel).

> >>

> >> Thanks,

> >> Sadiq

> >>

> >>

> >>

> >> On Tue, Sep 6, 2011 at 1:47 PM, Joe Astorino

> >> <joeastorino1982_at_gmail.com>wrote:

> >>

> >>> Hey guys! I think the answer to this question is "no"
based on the

> >>> research

> >>> I've done, but being that I am not an ASA expert (yet), I
thought I

> >> would

> >>> ask if anybody knows a solution to this problem.

> >>>

> >>> The problem: I have an SSL VPN connection set up at home.
When I am

> >> VPN in

> >>> I actually want internet tunneled through the ASA. I want
to tunnel

> >>> traffic

> >>> to the LAN 10.1.0.0/16 as well as all internet access
through the ASA

> >>> while

> >>> at the same time NOT tunneling traffic to other internal
IP addresses.

> >> So

> >>> logically, it would be something like

> >>>

> >>> access-list 1 standard permit 10.1.0.0 255.255.0.0

> >>> access-list 1 standard deny 10.0.0.0 255.0.0.0

> >>> access-list 1 standard deny 172.16.0.0 255.240.0.0

> >>> access-list 1 standard deny 192.168.0.0 255.255.0.0

> >>> access-list 1 standard permit any

> >>>

> >>> I don't think deny is a valid option in the ACL though.
Any way to

> >>> accomplish that?

> >>>

> >>> --

> >>> Regards,

> >>>

> >>> Joe Astorino

> >>> CCIE #24347

> >>> Blog: http://astorinonetworks.com
<http://astorinonetworks.com/>

> >>>

> >>> "He not busy being born is busy dying" - Dylan

> >>>

> >>>

> >>> Blogs and organic groups at http://www.ccie.net
<http://www.ccie.net/>

> >>>

> >>>

> >>
Received on Tue Sep 06 2011 - 10:01:20 ART

This archive was generated by hypermail 2.2.0 : Sat Oct 01 2011 - 07:26:25 ART