[c-nsp] Allowing VPN clients to access L2L tunnels terminating on the same outside interface

Tony td_miles at yahoo.com
Wed Nov 26 02:47:40 EST 2008


Hi Aaron,

I have set this up before (was setup many years ago on PIX v7 but still is used today) and it does work.

I would suggest you change the VPN client address pool to a totally DIFFERENT range. At the moment it seems that it is part of the same /24 that is on the ASA inteface. 

You may need to add a static route to any internal gateways so that they know about this new IP range you are using (this depends on your setup).

You will also need to ensure that this new address range is added to the ACL for the match traffic on your static tunnels.


Here is a Cisco doc on doing this:
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807f9a89.shtml

Look about halfway down the page for the section "Add a Remote Access VPN to the Configuration". The description for this says "This section provides the required procedures to add remote access capability and to allow remote users to access all sites." which would appear to be exactly what you want to do. In the example they have, they also use a seperate subnet for the remote users.


regards,
Tony.

--- On Wed, 26/11/08, Aaron Riemer <ariemer at wesenergy.com.au> wrote:

> From: Aaron Riemer <ariemer at wesenergy.com.au>
> Subject: [c-nsp] Allowing VPN clients to access L2L tunnels terminating on the same outside interface
> To: cisco-nsp at puck.nether.net
> Date: Wednesday, 26 November, 2008, 6:12 PM
> Hey guys,
>  
> I am hoping someone out there has configured something
> similar as I am
> having a lot of grief getting this working.
>  
> Essentially what we are trying to do is to allow our VPN
> clients to
> access other L2L sites that terminate on the same outside
> interface. See
> below for details.
>  
> VPN Client address range 10.100.1.100-200/24
> VPN client default gateway 10.100.1.1/24 (Inside 3750
> switch next hop
> after ASA)
> ASA Inside address 10.100.1.10/24
> VPN tunnel peer addressing: 172.16.0.0/16
>  
> We have configured the necessary commands to allow this
> hairpinning..
> i.e. 'same-security-traffic permit
> intra-interface'. The relevant VPN
> rules and nonat are in place to allow the entire
> 10.100.1.0/24 range
> across the L2L tunnel and this has been tested by
> attempting to telnet
> to a web server at the tunnel destination via the inside
> 3750. 
>  
> It's just the VPN clients on the outside interface
> can't seem to get
> through the tunnel. What makes things even more confusing
> is that ICMP
> goes across no problem but no TCP traffic will pass. (No
> SYN-ACK
> received from the web server). I have checked the logs and
> they don't
> indicate that any traffic is being denied. I can see the
> connection
> being built twice from the outside back to the inside
> default gateway
> then back from the inside (maybe this is the problem do we
> need to make
> the vpn client pool gateway address an address on the
> firewall??)
>  
> 2008/11/26 15:08:48  %ASA-6-302013: Built inbound TCP
> connection
> 137555837 for Outside:10.100.1.101/2523 (10.100.1.101/2523)
> to
> Inside:172.16.1.10/80 (172.16.1.10/80) 
> 2008/11/26 15:08:48  %ASA-6-302013: Built outbound TCP
> connection
> 137555838 for Outside: 172.16.1.10/80 (172.16.1.10/80) to
> Inside:10.100.1.101/2523 (10.100.1.101/2523)
>  
> Thanks in advance.
>  
> Aaron.
>  
>  
>  
>  


--- On Wed, 26/11/08, Aaron Riemer <ariemer at wesenergy.com.au> wrote:

> From: Aaron Riemer <ariemer at wesenergy.com.au>
> Subject: [c-nsp] Allowing VPN clients to access L2L tunnels terminating on the same outside interface
> To: cisco-nsp at puck.nether.net
> Date: Wednesday, 26 November, 2008, 6:12 PM
> Hey guys,
>  
> I am hoping someone out there has configured something
> similar as I am
> having a lot of grief getting this working.
>  
> Essentially what we are trying to do is to allow our VPN
> clients to
> access other L2L sites that terminate on the same outside
> interface. See
> below for details.
>  
> VPN Client address range 10.100.1.100-200/24
> VPN client default gateway 10.100.1.1/24 (Inside 3750
> switch next hop
> after ASA)
> ASA Inside address 10.100.1.10/24
> VPN tunnel peer addressing: 172.16.0.0/16
>  
> We have configured the necessary commands to allow this
> hairpinning..
> i.e. 'same-security-traffic permit
> intra-interface'. The relevant VPN
> rules and nonat are in place to allow the entire
> 10.100.1.0/24 range
> across the L2L tunnel and this has been tested by
> attempting to telnet
> to a web server at the tunnel destination via the inside
> 3750. 
>  
> It's just the VPN clients on the outside interface
> can't seem to get
> through the tunnel. What makes things even more confusing
> is that ICMP
> goes across no problem but no TCP traffic will pass. (No
> SYN-ACK
> received from the web server). I have checked the logs and
> they don't
> indicate that any traffic is being denied. I can see the
> connection
> being built twice from the outside back to the inside
> default gateway
> then back from the inside (maybe this is the problem do we
> need to make
> the vpn client pool gateway address an address on the
> firewall??)
>  
> 2008/11/26 15:08:48  %ASA-6-302013: Built inbound TCP
> connection
> 137555837 for Outside:10.100.1.101/2523 (10.100.1.101/2523)
> to
> Inside:172.16.1.10/80 (172.16.1.10/80) 
> 2008/11/26 15:08:48  %ASA-6-302013: Built outbound TCP
> connection
> 137555838 for Outside: 172.16.1.10/80 (172.16.1.10/80) to
> Inside:10.100.1.101/2523 (10.100.1.101/2523)
>  
> Thanks in advance.
>  
> Aaron.
>  
>  
>  
>  
> 
> LEGAL DISCLAIMER: This message contains confidential
> information and is intended only for the individual named.
> If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify
> the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
> If you are not the intended recipient you are notified that
> disclosing, copying, distributing or taking any action in
> reliance on the contents of this information is strictly
> prohibited.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


      



More information about the cisco-nsp mailing list