VPN over ADSL using negotiated IP address.

[jakelley]

I have two 1720s configured for a lan to lan VPN. One has a WIC-1T card, the other an ADSL card. Works great! The problem I have is that the address on the ADSL side is negotiated and when it changes the VPN is down. Is there a way to terminate the VPN on another interface, maybe loopback 0? Or maybe another way of getting around this problem? Any ideas or config examples would be appreciated...

Thanks.

[ciscomoderator]

Since there has been no response to your post, it appears to be either too complex or too rare an issue for other forum members to assist you. If you don't get a suitable response to your post, you may wish to review our resources at the online Technical Assistance Center (http://www.cisco.com/tac) or speak with a TAC engineer. You can open a TAC case online at http://www.cisco.com/tac/caseopen

If anyone else in the forum has some advice, please reply to this thread.

Thank you for posting.

[fabios]

Hello there,

you could terminate the VPN on a loopback but the ip address would have to be pubblicly routable and your service provider should have a route for you (either static or accept routing info from you). If it were to do so, it would be easier for them to give you a static IP to you ADSL interface. Any other address would not do because, to work you would have to use NAT between the ADSL interface and the loopback (if possible), but if you use NAT you alter the header of the IP packet encapsulating the ESP/AH payload, therefore the crypto checksum will not match and the packet is silently discarded.

In brief, your problem has no solution. Sorry, but for something only a static IP would do.

Fabio

[dcourtier]

While looking for ADSL configs, I came across this sample which might help.

http://www.cisco.com/warp/customer/707/ios_804.html

regards & good luck!

[g.raymakers]

You could use dynamic crypto maps. This can be used in a setup where you have a central location (with fixed IP address) and remote location that need only to access the central site. The remote location in this case can work with negotiated IP addresses

[fabios]

I do have a similar config (A cisco PIX with static IP address and permanent connection with multiple dinamic IP clients and a couple of fixed tunnels) you can have only a crypto map associated to an interface so you have to build a single crypto map comprisin the info for all of your connection, all the dinamic client have to share the same config (in fact the PIX cannot differentiate the clients during tunnel negotiation) and last but not least, the tunnel can only be initiated by the dynamic ip end of the tunnel. Therefore, whenever the IP address of the dial up end changes, the tunnel will go down. A workaround for this is configuring a script that sends (protected) traffic so that whenever the IP changes a new tunnel is negotiated.

[l.peng]

I have a similar config with one router on the central side (permanent IP addr.), multiple remote sites with dynamic IP addr. can you build one static crypto map, but with different sequence number relate to each of the dynamic crypto map? Can the remote site talk to each other through the central site? If so, how the ACL should be configured?

[fabios]

This would be an interesting test to do ...

The problem is the PIX is not a router and has very limited routing capability.

The way I see it possible, is by setting a router in the protected network doing the routing and the PIX the IPSEC encapsulation.

Lets say the internal IP address of the clients is

172.16.1.x then 172.16.2.x etc. Your Internal PIX interface is 192.168.1.254 and so your protected hosts lie in 192.168.1.0/24

You set up the router as 192.168.1.253 and route as follows

ip route 172.16.0.0 255.255.0.0 192.168.1.254

Now the problem is forwarding all pix traffic for those neworks to the router which is done by a static route in the pix (not sure if it works) or proxy ARP in the router (this should work).

The only real problem to watch is that being the remote clients on dynamic IP, they need to establish the tunnel (the pix is unable because the remote IP is unknown) therefore, if there is a remote client that want to talk to another and the tunnel is down there is no way to do it.

A better understanding of this can be gained by doing a show crypto map when there are several clients and watch the dynamic entries appear and disappear.

I do not have a lab to test the whole thing, and my only PIX is in production ... if anybody does it please let us know. But if you have a config working without the router I would definitely be interested in seeing it.

[alexkane]

This is what I am trying to do, can you be more specific about your config? Maybe post some snippets of what you have. Thanks so much.