VPN Interesting Traffic Routing Issue!

I may have an issue with routing on a VPN config.
I have several remote offices and each of them have different ip schemas but they all are 10.0.0.0 series.
Since my access-list refers to hosts and not networks, how does the vpn know how to route the traffic?
See the access lists below:
access-list 100 extended permit ip host 10.1.200.9 host 10.0.130.2
access-list 100 extended permit ip host 10.1.200.8 host 10.0.130.2
access-list 100 extended permit ip host 10.1.200.9 10.50.0.0 255.255.255.0
access-list 100 extended permit ip host 10.1.200.5 10.0.110.0 255.255.255.0
access-list 100 extended permit ip host 10.1.200.9 10.0.0.0 255.255.255.0
access-list 120 extended permit ip host 10.1.200.9 host 10.0.130.2
access-list 120 extended permit ip host 10.1.200.8 host 10.0.130.2
access-list 150 extended permit ip host 10.1.200.5 10.0.110.0 255.255.255.0
access-list 110 extended permit ip host 10.1.200.9 10.50.0.0 255.255.255.0
access-list 160 extended permit ip host 10.1.200.9 10.0.0.0 255.255.255.0

The access-list 100 links with the
nat (inside) 0 access-list 100
and the incremental access-list each tie to an associated crypto map as shown below:
crypto map VPNClientMap 110 match address 110
crypto map VPNClientMap 110 set peer 162.xx.xx.18
crypto map VPNClientMap 110 set transform-set DV-clientset
crypto map VPNClientMap 120 match address 120
crypto map VPNClientMap 120 set peer 166.xx.xx.171
LVL 2
brian_appliedcpuAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

batry_boyCommented:
>>Since my access-list refers to hosts and not networks, how does the vpn know how to route the traffic?

A site-to-site VPN connection works by first waiting on "interesting traffic" to arrive at the PIX.  Interesting traffic is defined by the ACL referenced in the "crypto map <mapname> <sequence_number> match address <ACL_ID>".  So in your case, from the snippet of code you posted, I see that you have at least 2 site-to-site tunnels.  The first tunnel communicates with another VPN device at IP address 162.xx.xx.18 and the second tunnel communicates with a VPN deivce at 166.xx.xx.171.

So, for peer 162.xx.xx.18, the interesting traffic is defined as traffic coming from source IP 10.1.200.9 and going to any host on the 10.50.0.0/24 network segment.  It then brings up the tunnel (if not already established), performs any NAT processes that need to happen, and then sends the traffic down the tunnel.  In your case, the traffic is exempted from NAT since it also matches a statement in your "nat 0" ACL.  It's important to know that NAT always happens before encryption regarding a VPN tunnel.

Since this traffic does not undergo any translation, it gets encrypted and sent down the tunnel where it arrives on the other side of the tunnel and it looks like it came from IP address 10.1.200.9 and it is going to 10.50.0.x (whichever host on this network the traffic was sent to).

The other VPN device next has to know how to get to whichever 10.50.0.x host that the traffic was sent to.  If that host is on a directly connected interface, then it implicitly knows how to get to it.  If there are multiple subnets on the remote side of the tunnel, then the other VPN device has to have a route to know how to get to 10.50.0.x.

One other important thing to know is that the remote side VPN device should have a mirrored definition of the VPN traffic.  In other words, there should be a similar "access-list 100" on the remote side VPN device with the source and destinations swapped, like so:

access-list 110 extended permit ip 10.50.0.0 255.255.255.0 host 10.1.200.9

I'm not sure if this answered your question about routing, but if you think you may have a routing issue, it becomes very important to understand the network topology on both sides of the tunnel such that all the L3 hops between source and destination can be accounted for so that the traffic flows properly.

Post back with questions...
0
brian_appliedcpuAuthor Commented:
I understand all of what you wrote my question really lies in knowing how does the pix know where to send the traffic in relation to these access-lists.  This is what I had originally as we only wanted traffic from one host to another.  Since 10.0.0.0 's default subnetmask is only an 8 bit or 255.0.0.0.0 if i dont define the subnet by allowing traffic to all the systems on that subnet how does it know to send traffic for 10.0.0.4 down ac 160 instead of 120?  Does it read all the access-lists then decide?  What is happening is that if the tunnel goes down, i can only get it to come up if i connect to the remote ip and clear the crypto isakmp sa then it comes up.  If i do it on the main or central firewall then it does not come up.

access-list 120 extended permit ip host 10.1.200.8 host 10.0.130.2
access-list 150 extended permit ip host 10.1.200.5 host 10.0.110.2
access-list 110 extended permit ip host 10.1.200.9 host 10.50.0.2
access-list 160 extended permit ip host 10.1.200.9 host 10.0.0.4
0
batry_boyCommented:
>>Since 10.0.0.0 's default subnetmask is only an 8 bit or 255.0.0.0.0 if i dont define the subnet by allowing traffic to all the systems on that subnet how does it know to send traffic for 10.0.0.4 down ac 160 instead of 120?

You alluded to the answer to this one in your original question.  It knows because of the "crypto map" command that references ACL 160 with the "match address" parameters.  So, take the following code from your configuration:

access-list 120 extended permit ip host 10.1.200.9 host 10.0.130.2
access-list 120 extended permit ip host 10.1.200.8 host 10.0.130.2
access-list 160 extended permit ip host 10.1.200.9 10.0.0.0 255.255.255.0
crypto map VPNClientMap 110 match address 110
crypto map VPNClientMap 110 set peer 162.xx.xx.18
crypto map VPNClientMap 110 set transform-set DV-clientset
crypto map VPNClientMap 120 match address 120
crypto map VPNClientMap 120 set peer 166.xx.xx.171

Two VPN tunnels here, one going to peer 162.xx.xx.18 and the other going to 166.xx.xx.171.  The sequence numbers for your crypto map commands (110 and 120, in this case), group all of the crypto map statements together so that the firewall knows that it should use traffic matching ACL 110 for peer 162.xx.xx.18 because the two "crypto map" statements that reference those two items both have sequence number 110.  The same goes for the crypto map statements with sequence number 120.

Does this make sense?

>>Does it read all the access-lists then decide?

No, it doesn't have to because the crypto map command with the right sequence number and "match address <ACL>" parameters tells it which ACL to use.

If the tunnel goes down, then you should be able to ping 10.1.200.9 from host 10.0.0.4 (or vice versa) and the tunnel should come back up.  If not, then there is something else going on here.  Do the crypto ACL's look like mirror images of each other on both VPN devices?

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
brian_appliedcpuAuthor Commented:
Thanks,
I found a command crypto map VPNClientMap 110 set reverse route
it only works in v7 or newer but it helps config the routes.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Cisco

From novice to tech pro — start learning today.