In article , Jaime wrote: :I do use a Cisco 1760 with VPN module for IPSec VPNs handling site to site :VPN with both endpoints using a static permanent IP address, but also Cisco :VPN clients where the client IP address es dynamic (ISP assigned).
:Is there a way on this router to set up a site to site VPN where the remote :end-point does not own a permanent static IP address ?
Yes.
I do not know the exact syntax for IOS, but the mechanism you need is to declare a 'dynamic' map, attach attributes to the dynamic map, and then declare an entry in the standard static map sequence which is marked as referencing the dynamic map.
When you create dynamic map entries, you must still associate a transform set. You -may- associate a 'match address' ACL to restrict the scope of the traffic. If you do not associate a 'match address' ACL, then an ACL will be dynamically generated for the link, with the ACL restricting traffic to the network(s) requested by the dynamic client.
For example, if the dynamic client (say a user at home) configured so that their local network was 192.168.1.0/24 and in the device (or software) on their end, they requested access to the remote network 10.10.15.0/24 then the dynamic ACL that would be built would reflect 192.168.1.0/24 to
10.10.15.0/24.
This would, naturally, be a Problem if you have other clients requesting the same access. VPN client -software- is usually set up to request a dynamic IP address from the remote end, and the dynamically generated ACL reflects that one *host* to the desired target network. Thus in practice there is no problem for VPN client software, but it could be a noticable issue if, for example, you have several travelling salesmen equipped with PIX 501... which are going to be requesting a LAN to LAN tunnel rather than a HOST to LAN tunnel.
You would expect to be able to solve this problem by supplying a 'match address' ACL, but not really: any such ACL cannot be too specific about the client IPs because of the dynamic addresses, so such an ACL mostly acts to restrict which internal networks the client can request access to (rather than acting in any real way to sort out which client is which.)
Further note: although if you are allowing the ACL to be dynamically generated, the client can request arbitrary internal destinations, that does not mean that they will always be able to get access to the resources. Unless you specifically configure otherwise all the traffic over the VPN still has to be processed through the interface ACLs -after- decapsulation. Your interface ACLs can be quite strict about which internal hosts and ports can -actually- be reaced. [Note: many people find it easier to turn off this ACL layer rather than to configure extensive rules about authorized access... figuring, I guess, that if they got through the VPN authentication layer, that they should be permitted access just as if they were right onsite. This is, though, not exactly a "defence in layers" setup, and it means that if the client managed to pick up a new virus [e.g., while not connected to the VPN] that the entire internal network can be infected.]