• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 432
  • Last Modified:

PIX VPN Questions

I am relatively new to cisco VPNs.  I have a couple of questions.

o-How do I limit access to what services are provided across the VPN tunnel.
    * I assume that the access list used for the 'address match' statement is how one would accomplish this.
    * This would make sense, but I think that I read somewhere that this list is used ONLY to determine which
    * IP addresses are allowed through and nothing else.  This seems stupid though.

o-How do I definitively certify that specific traffic is making it through the tunnel (ftp for example).

o-What is the proper proceedure to 'tear down' a vpn tunnel on a central site PIX that can't be reloaded.

Any help would be appreciated.

  • 2
1 Solution
In addition to the address match statement, you should have a no_nat access list that exempts VPN traffic from NAT. You can use this to restrict traffic (the applied direction is from inside-->VPN)
I don't know of any technical reason why you can't use the address-match acl to define the encrypted traffic. It is an extended access-list and understands ports... Problem is that conversations can have random ports >1024 at the client end, so it's not really practical to use any access-list to restrict the traffic in this context.

If you use the Pix Device Manager (PDM) 3.01 GUI you can monitor VPN's to see packet counts, etc, and the wizard makes it pretty easy to set up. Simple "show access-list" will sho hit-counts on any access-list line items.

Same to tear down. If using the GUI, simply unapply the crypto map to the interface, or delete the policy and apply it. No downtime required.
mtetzlaffAuthor Commented:
So.....it would appear that there is no really good way to restrict what type of traffic traverses a VPN tunnel?  Doesn't sould likely.  As lrmoore mentions the 'match address' access list is an extended list.  When you are building that list, aren't you referring to destination port numbers which would therefore allow you to be granular in your selection of traffic matching?

Also, I was woring on a tunnel setup last week.  It seemd like the tunnel took FOREVER to actually come up.  After I had the config in place, I wasn't getting anything on any of the following:
o- debug crypto ipsec
o- debug crypto isakmp

o- show crypto isakmp sa -- didn't have an entry.

Thoughts?  Is there a certain timeframe I should ecpect to wait before a tunnel actually is attempted when interesting traffic is present?
>When you are building that list, aren't you referring to destination port numbers which would therefore allow you to be granular in your selection of traffic matching?
Yes, but remember, this is defining interesting traffic for an IPSEC tunnel, so you must also define the return traffic, with destination port now up >1024. There is no facility for stateful inspection "through" the tunnel to allow the return traffic to a request.

The tunnel will not actually show up until/unless there is actual 2-way traffic from host to host. This means that the hosts have to have routing set up as well as the tunnel..

If you have a host at side A pinging (continuous) a host at side B, and both hosts have the proper routing, and you setup the VPN correctly, it will come up almost instantaneously..
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

NEW Internet Security Report Now Available!

WatchGuard’s Threat Lab is a group of dedicated threat researchers committed to helping you stay ahead of the bad guys by providing in-depth analysis of the top security threats to your network.  Check out this quarters report on the threats that shook the industry in Q4 2017.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now