cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Ask the Expert- SD-WAN

3214
Views
0
Helpful
5
Replies
Highlighted
Beginner

IPSEC tunnel via hostname instead of IP address

Hi there,

Is it possible on an ASA 5500 device to connect an IPSEC tunnel via hostname instead of the IP address?  I have a site without a static IP address that is currently connected via Easy VPN but I want to change one of the sites to a regular IPSEC site to site as one side, the one with the dynamic IP, is being changed to SonicWALL.  I will have DDNS setup on the site with the SonicWALL so I want to know if I can point the ASA device to the hostname instead of the IP.

Thanks ahead of time for anybody with the knowledge to help!

5 REPLIES 5
Beginner

IPSEC tunnel via hostname instead of IP address

Hi

Locally on the firewall you can configure the remote destination ip with a namel-list, is this what you were after?

name 46.46.2.2 site-to-site

tunnel-group site-to-site type ipsec-l2l

tunnel-group site-to-site ipsec-attributes

pre-shared-key cisco

Regards

Nouraj

Beginner

IPSEC tunnel via hostname instead of IP address

Hi there and thanks for the quick reply.  Unfortunately that's not what I was looking for.  I don't have a static WAN IP on the device the ASA will be connecting to and I was wondering if instead of putting in an IP in the config I could just give a hostname and the ASA would translate the hostname to it's current IP via DDNS.

Thanks!

Beginner

IPSEC tunnel via hostname instead of IP address

that wont be possible on the asa firewalls. Only other solution would be to put a router in front of a firewall and if you would like the terminate the tunnel on the firewall is to use idenity dn and point it at the router.

Beginner

IPSEC tunnel via hostname instead of IP address

That's what I thought.  Thanks for the help, I just wanted to confirm that before I proposed to the client my resolution.  Have a great weekend!

Beginner

Re: IPSEC tunnel via hostname instead of IP address

I know this is a real necro-post, but others may be looking for this information - I know I was last week : )

 

I managed to resolve the problem using a TCL script and setting it to run every few minutes.  The script turned out to be surprisingly simple ...


I initially thought I'd have to get TCL Script to do an IP lookup, parse the result, then craft a "tunnel destination {The Required IP}" command string and execute it.

Then I remembered that whenever I had tried to enter a hostname instead of an IP in the 'tunnel destination' command, the IOS automagically did the lookup for me and replaced the hostname with the IP when it wrote the line into the config.

So, whilst that was annoying at the time... it turned out to be very useful behaviour, which simplified my script.

You basically execute a "tunnel destination  your.ddns.com" command in your TCL Script and save it as something like 'nvram: resolveddns.tcl'

Now, just schedule that to run every minute, and  \o/  : )

 

The process of script creation goes like this :

router#  tclsh

router(tcl) # puts [ open "nvram:resolvedns.tcl" w+ ] {

 

##

##  Reconfigure the Tunnel1 interface, to refresh the DDNS

##

ios_config "int tunnel1" "tunnel destination your.ddns.com"

##

##  I deliberately left it without a 'copy run start', because we don't

##  want to have a rebuild every minute.  This means that on

##  startup the tunnel is broken.  Regardless, within 60s of booting

##  the tunnels come up.

##

##  To avoid accidental tunnels to strange places, the startup-config

##  will have no destination address saved.

##

}

tclquit

 

That will create the TCL Script in your filesystem!   Now, set up a Kron policy-list with the required CLI command to run the script ...

 

router(config)#  kronpolicy-list  myddnsevent
router(config-kron-policy)#  cli tclsh nvram:resolvedns.tcl

 

And lastly set up an 'occurrence' in Kron, to fire the policy event to your chosen schedule ... in this case, once per minute.


router(config)#  kron occurrence refresh_ddns in 1 recurring
router(config-kron-occurrence)#  policy-list myddnsevent

 

And finally, check it all looks good with :

router#  show kron schedule

 

And you're golden : )

 

This weekend I might have a go at checking that tunnel1 is down first before conditionally running the command and writing the config back to startup-config.  It shouldn't be too difficult to parse an int show tunnel1, but I only just learned about TCL and Kron  today so I need to do a little experimentation.  I'm very new to Cisco IOS (this is my first week with a cisco router) ... sorry.

 

I believe there's a much neater solution ...

 

I read that you can also fire events when interfaces (like tunnels?) come up or down.  So perhaps you could fire a 'startchecking' event on tunnel loss, that creates a periodic 'fixdns' event that keeps retrying the DDNS every minute ... and have a 'stopchecking' event fired automatically by Kron on 'tunnel interface up' that removes the periodic 'fixdns' kron job.  This seems the most efficient way if I understand triggered events correctly ... but I'd need to do a little reading up in the cisco kron docs... again, sorry I'm not in a position to provide a better solution just yet.

 

Right now it still feels like a bit of a hack.  But using triggered events (tied to interface state) to turn the periodic checker on and off would seem to be an optimal solution.  By worry is that tunnels won't report as down on first boot ... they may just 'not report up'.  If so, we may need an additional 'on boot' event to turn on the periodic checker for the first time.  This will bring the tunnel up ... and from then on it manages itself using only the interface state transitions.

 

Leave a comment if you'd like me to post my findings on that.

 


So, to answer the OPs question, no ... you absolutely cannot use a DDNS hostname in a "tunnel destination"command because it immediately looks it up and hardcodes it as an IP, which sucks for DDNS users ... but you CAN use a scheduled script to configure that line regularly enough, so that within 1 minute of an IP change, the tunnel reconfigures to the new IP.

The result is that everything works perfectly and your config automatically tracks the dynamic DNS changes on those odd occasions when your lease expires : )



Hope that info is of some help to others : )  Can I get a 'like' ?

6 years? not a bad turnaround XD