# Digi transport IPSec using URL, not IP address\[SOLVED\] **URL:** \ **Category:** Digi TransPort WR (Series)\ **Tags:** dns, multiple-sas, multiple-ipsec-tunne\ **Created:** [December 30, 2020, 5:49am UTC](https://forums.digi.com/t/digi-transport-ipsec-using-url-not-ip-address-solved/22095 "2020-12-30T05:49:32Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![jserink](https://avatars.discourse-cdn.com/v4/letter/j/bc79bd/32.png) [@jserink](https://forums.digi.com/u/jserink)\ **Post date:** [December 30, 2020, 5:49am UTC](https://forums.digi.com/t/digi-transport-ipsec-using-url-not-ip-address-solved/22095/1 "2020-12-30T05:49:32Z")
Hello: I have a system of 74 sites that we are going to upgrade the Internet link which will require us to change the static IP. As such, I am changing the IPsec definition to use a URL rather that the IP addess…but here is the problem: From the Cisco: CCrouter#sh crypto sess br | grep CORS18 106.215.173.81 Gi0/0/0 CORS18 00:10:40 UA 106.215.173.81 Gi0/0/0 CORS18 00:10:39 UA Bear in mind this usually has three entries. Digi: Peer ID Peer IP Our IP Session ID Rekeys Auth Alg Enc Alg Time Left (secs) Internal ID CCrouter A.B.C.D 100.86.218.105 0x1 0 SHA256 AES(256) 45923 1 CCrouter A.B.C.D 100.86.218.105 0x2 0 SHA256 AES(256) 45924 2 CCrouter A.B.C.D 100.86.218.105 0x3 0 SHA256 AES(256) 45925 3 And IPSec: # Peer IP First Rem. IP Last Rem. IP First Loc. IP Last Loc. IP AH ESP Auth ESP Enc IP Comp KBytes Delivered KBytes Left Time Left Interface 0 A.B.C.D 1.1.1.10 1.1.1.10 2.2.2.18 2.2.2.18 N/A SHA256 AES(256) N/A 451 0 13679 PPP 1 0 A.B.C.D 1.1.1.10 1.1.1.10 2.2.2.18 2.2.2.18 N/A SHA256 AES(256) N/A 0 0 13677 PPP 1 0 A.B.C.D 1.1.1.10 1.1.1.10 2.2.2.18 2.2.2.18 N/A SHA256 AES(256) N/A 0 0 13678 PPP 1 Inbound V2 SAs # Peer IP First Rem. IP Last Rem. IP First Loc. IP Last Loc. IP AH ESP Auth ESP Enc IP Comp KBytes Delivered KBytes Left Time Left Interface 0 A.B.C.D 1.1.1.10 1.1.1.10 2.2.2.18 2.2.2.18 N/A SHA256 AES(256) N/A 252 0 13679 PPP 1 0 A.B.C.D 1.1.1.10 1.1.1.10 2.2.2.18 2.2.2.18 N/A SHA256 AES(256) N/A 0 0 13677 PPP 1 0 A.B.C.D 1.1.1.10 1.1.1.10 2.2.2.18 2.2.2.18 N/A SHA256 AES(256) N/A 0 0 13678 PPP 1 And here is the Event log: 17:14:25, 30 Dec 2020,(3) New IKEv2 Negotiation peer A.B.C.D,Initiator (Init) 17:14:25, 30 Dec 2020,(2) New IKEv2 Negotiation peer A.B.C.D,Initiator (Init) 17:14:25, 30 Dec 2020,(1) New IKEv2 Negotiation peer A.B.C.D,Initiator (Init) 17:14:25, 30 Dec 2020,DNS Query Failed on [MyURL] 17:14:25, 30 Dec 2020,IKE Request Received From Eroute 0 17:14:15, 30 Dec 2020,DNS Query Failed on [MyURL] 17:14:15, 30 Dec 2020,IKE Request Received From Eroute 0 17:14:05, 30 Dec 2020,DNS Query Failed on [MyURL] 17:14:05, 30 Dec 2020,IKE Request Received From Eroute 0 17:13:55, 30 Dec 2020,DNS Query Failed on [MyURL] 17:13:55, 30 Dec 2020,IKE Request Received From Eroute 0 17:13:46, 30 Dec 2020,DNS Query Failed on [MyURL] 17:13:45, 30 Dec 2020,IKE Request Received From Eroute 0 17:13:45, 30 Dec 2020,Event delay,Logger busy 17:13:36, 30 Dec 2020,DNS Query Failed on [MyURL] 17:13:35, 30 Dec 2020,IKE Request Received From Eroute 0 It “Appears” to be queuing the IPSec initiation attempts until the DNS responds and then rather than send a single initiation attempt, it send 3 simultaneously. It does not do this when I use and IP address in the “The IP address or hostname of the remote unit” field. Is there anyway to “Delay” the IPsec attempts until the DNS is up? How can I stop this behavior? Cheers, john ---
**Author:** ![jserink](https://avatars.discourse-cdn.com/v4/letter/j/bc79bd/32.png) [@jserink](https://forums.digi.com/u/jserink)\ **Post date:** [December 30, 2020, 6:15am UTC](https://forums.digi.com/t/digi-transport-ipsec-using-url-not-ip-address-solved/22095/2 "2020-12-30T06:15:23Z")
This solution is to change the “Bring this tunnel up” from “All the time” to “When a route to the destination is available”. The problem goes away then. Cheers, John