S2S VPN....re-route internet traffic for remote site through different ASA than the VPN terminates to.

[deyster94]

Here is my situation.  I setup a S2S VPN for a client so that all the traffic at the remote site comes back to their HQ.  All of this works fine.  However, they have another ASA that uses WCCP with their Ironports.  They want the internet traffic from the remote site go out through this ASA so it is filtered.  The ASA that the S2S terminates with at their HQ has routes to their internal network to a core switch.  I thought of configuring PBR on the clients core switch to see if that will work.  However, I am not 100% sure if it will work. 

Has anyone set anything up like this?  Here is a diagram with what the flow for internet traffic would look like:

remote user - remote ASA - HQ ASA (where S2S terminates) - core switch - HQ ASA (which uses WCCP to Ironport) - internet

This is how I would think the PBR would need to be written:

ACL’s (first three lines are to deny access to local resources):

access-list 115 deny ip 10.X.X.0 0.0.0.63 10.0.0.0 0.255.255.255

access-list 115 deny ip 10.X.X.0 0.0.0.63 170.X.X.X 0.0.0.0

access-list 115 deny ip 10.X.X.0 0.0.0.63 170.X.X.X 0.0.0.0

access-list 115 permit ip 10.X.X.0 0.0.0.63 any

Route map:

Route-map 115Traffic permit 10

     Match ip address 115

     Set ip next-hop 10.XXX.XX.X (IP address of the other ASA that they want internet traffic going through)

Interface config:

int vlan 10 – this has the IP address of 10.XXX.XX.X which the ASA that is doing the S2S VPN is using for the gateway address of the local networks

     ip policy route-map 115Traffic

My conern is that the first three lines of the ACL would block the remote site access to the local resources.  If so, than this is a bust and I am back to square one.  Maybe this should be cross posted in the routing area, but I thought I would put it here first.

TIA for any help or ideas.

Dan

[Andrew Phirsov]

As I understand this:

S2S has routes, pointing towards remote subnet through the outside interface. Default route on the S2S ASA should point to the core. So when this S2S asa receives any traffic (including vpn) it'll send it to the core.

Here, the core switch should have routes towards all the inside subnets, and the default (internet) route throug the internet ASA, wich uses WCCP to WSA.

So all the  traffic from remote office, when going throug the tunnel will follow general routing rules in the LAN as a described above. It's just crypto-acl on the reomte site should be configured to encrypt all the traffic, when going through the tunnel.

So i don't see why you would need any kind of PBR. Or maybe I miss something? If so, picture would help))

[deyster94]

The ASA at the remote site does not have any routes on it pointing to the anything on the HQ side (if that is what you are thinking). 

I tried putting a 'route inside 0 0 x.x.x.x' pointing to core switch on the ASA at the HQ site and it didn't work.  When traffic would try to go to the subnet on the remote end, it would get routed right back into the core switch and then back to the ASA into a loop.  Trust me, I thought this would work. 

I will try to put a diagram (better than what I had) up later.

[Andrew Phirsov]

I tried putting a 'route inside 0 0 x.x.x.x' pointing to core switch on the ASA at the HQ site and it didn't work. 

Did the core has a route towards remote subnet?

When traffic would try to go to the subnet on the remote end, it would  get routed right back into the core switch and then back to the ASA into  a loop

How did you know that? By the fact, that there was no connection between sites? When traffic tries to go to the subnet on the remote end, it'll match more specific route (wich you should have configured on ASA towards remote subnet) and not the default one, so the loop won't happen, as you've said. Think about it once more.

Regards.

[deyster94]

Yes, the core has a route for the remote site pointing to the ASA that the S2S terminates on at HQ.

I knew there was a loop since when we tried to access resouces at the remote site and we couldn't connect.  When I removed the default route on the ASA that the S2S terminates into at HQ, we could connect to the remote side. 

Are you saying that I should have a route on the ASA at HQ pointing to the ASA at the remote site for the remote network?  And then have the default route pointing to the core?

[Andrew Phirsov]

Are you saying that I should have a route on the ASA at HQ pointing to  the ASA at the remote site for the remote network?  And then have the  default route pointing to the core?

Yes, i'm saying that on S2S ASA you should have static route, pointing to the next hop of the outside interface towards reomte subnet. But default route on that ASA should point to your core switch, wich has default route through the other ASA, wich is used for the Internet connectivity.

By doing this, S2S ASA will always forward traffic to the remote site subnet through the tunnel, as it would have more specific route to that subnet, but all other traffic (including internet traffic from the remote subnet hosts) will go through the core switch towards Internet ASA.