[c-nsp] tunnel internet traffic via a VPN?

[Scott Lambert]

On Tue, Jul 03, 2007 at 03:37:10PM +0200, Peter Krupl wrote:
> Hi,
>
> This is propably caused by the fact that you can't have the traffic
> entering and leaving the hub pix on the same interface.

That's what I found out with the help of a couple of off-list replies.

> Unless you use pix/asa 7.0 or newer software.
>
> The following URL explains the necessary steps:
> http://cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00805734ae.shtml#ra-sol-2

It looks like my senario might work with a 515 or above with 7.2
software using the "same-security-traffic intra-interface" command. 

http://www.cisco.com/en/US/docs/security/asa/asa72/command/reference/s1_72.html

However, I don't see absolute confirmation that the above will work to
VPN into the box and then be routed back out the same interface for
Internet access.  Can somebody confirm that it will work? 

Or do I need to have a NAT box inside the PIX so that the Internet
traffic appears to be coming from the LAN?  At some point last night I
ran across a web page which suggested that method.

I guess another option would be to have two Internet connections on the
PIX, since it looks like I will need a newer/bigger PIX anyway.  One for
VPNs and one for surfing.

Thank you to all who have taken the time to help me out!
 
 
> -----Oprindelig meddelelse-----
> Fra: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] På vegne af Scott Lambert
> Sendt: 3. juli 2007 01:15
> Til: cisco-nsp at puck.nether.net
> Emne: [c-nsp] tunnel internet traffic via a VPN?
> 
> I have a customer who has several PIX 506Es, connected to DSL and cable
> connections in various towns.  They have working VPNs for the LAN
> traffic between the towns via VPN tunnels across the Internet.
> 
> The customer now wants to backhaul all Internet traffic from the various
> LANs through the central location so that they can do centralized access
> control and IPS.
> 
> Thinking this would be easy, I set out to add routes and adjust access
> lists for the PIXes at the hub and one of the branches.  
> 
> I didn't want to risk breaking their Internet access in general since
> they are sort of a 24x7 operation.  So, I tried to test with just one
> /24 of the Internet.
> 
> At the branch, I adjusted the access-list for the VPN to the hub site to
> permit one /24 on the Internet to test the config.  I adjusted the nonat
> access-list to include traffic from the local LAN to the /24.
> 
>  access-list nonat permit ip 172.31.29.0 255.255.255.128 172.31.30.0 255.255.255.0 
> +access-list nonat permit ip 172.31.29.0 255.255.255.128 216.61.218.0 255.255.255.0 
>  ...
>  access-list ToHub permit ip 172.31.29.0 255.255.255.128 172.31.30.0 255.255.255.128 
> +access-list ToHub permit ip 172.31.29.0 255.255.255.128 216.61.218.0 255.255.255.0 
>  ...
>  nat (inside) 0 access-list nonat
>  nat (inside) 1 172.31.29.0 255.255.255.128 0 0
>  ...
>  crypto map out_if 11 ipsec-isakmp
>  crypto map out_if 11 match address ToHub
>  crypto map out_if 11 set peer h.h.h.h
>  crypto map out_if 11 set transform-set STRONG
> 
> At the hub, I adjusted the access-list for the VPN to the branch site to
> permit traffic from the /24 to the branch's LAN.  I removed the branch's
> LAN from the nonat access-list.  I added the branch's LAN to the nat
> statements as line 2 just like the statement for the hub's LAN.
> 
> i.e:
> 
>  access-list nonat permit ip 172.31.30.0 255.255.255.128 172.31.29.0 255.255.255.0 
> +access-list nonat permit ip 216.61.218.2 255.255.255.0 172.31.29.0 255.255.255.0 
>  ...
>  access-list ToBranch permit ip 172.31.30.0 255.255.255.128 172.31.29.0 255.255.255.128 
> +access-list ToBranch permit ip 216.61.218.2 255.255.255.0 172.31.29.0 255.255.255.128 
>  ...
>  nat (inside) 0 access-list nonat
>  nat (inside) 1 172.31.30.0 255.255.255.128 0 0
> +nat (inside) 2 172.31.29.0 255.255.255.128 0 0
>  ...
>  crypto map out_if 11 ipsec-isakmp
>  crypto map out_if 11 match address ToBranch
>  crypto map out_if 11 set peer b.b.b.b
>  crypto map out_if 11 set transform-set STRONG
> 
> The access-lists are much longer than I have included here.  Each branch
> has a VPN to every other branch and the hub.
> 
> Somewhere along the way I tried adding a static route to the branch's PIX:
> route inside 216.61.218.0 255.255.255.0 172.31.30.74 1
> 
> I don't think the route statement should be necessary.  If I'm right the
> VPN's access-list will setup the route when the VPN is up.
> 
> I could never reach 216.61.218.0/24 from the branch with the changes
> in place.  Without them, it would NAT out the branch pix and work just
> fine.  I spent 4 hours trying variations of the above without success.
> 
> Could someone tell me what boneheaded mistake I was making?  It can't be
> this hard.
> 
> I haven't been able to find any examples of this type of configuration
> because the search terms, (Cisco PIX tunnel Internet via VPN) and
> various other combinations with and without grouping phrases, pull up so
> much noise about VPNs across the Internet.
> 
> -- 
> Scott Lambert                    KC5MLE                       Unix SysAdmin
> lambert at lambertfam.org
> 
> _______________________________________________
> 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/

-- 
Scott Lambert                    KC5MLE                       Unix SysAdmin
lambert at lambertfam.org