cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
829
Views
0
Helpful
12
Replies

vEdge 2000 to GCP with IPSec tunnel (only) Cloud DNS not working

dbogdan
Level 1
Level 1

Hello all, 

 

I have a tunnel to GCP.  It's a standard IPSec tunnel from one of our vEdge 2000 routers.  The tunnel itself works perfectly.  users can get to and go to GCP without issue as far as networking is concerned.  On to DNS.  We would like to employ google cloud dns, so when the instance out there does a lookup for an on-prem host, our on-prem dns server supplies the information.   So without getting into dns itself (hang on to that thought) the documentation suggests we add a route on our on-prem core router for gcp 35.199.192.0/19 to point to the inside interface of our vEdge.  From there we add a route on our vEdge to point to the tunnel interface.  So we placed routes as follows:

 

on core router

ip route 35.199.192.0 255.255.224.0 192.168.240.129

 

vedge:

vpn 10 

 35.199.192.0/19   next-hop 169.254.100.6   ** the interface defined is 169.254.100.5.

 

if I do a sh route the routes are present:

 

sd-1> sh ip route vpn 10 | include 35.199.192.0

10 35.199.192.0/19 static - ipsec7 169.254.100.6 - - - - F,S

 

all looks good. but no go.

 

Now here's the funny part.  If I create the exact same scenario on an ASA-5525x tunnel (dropping the sdwan).  it works perfectly. all dns lookups work, so in my book I'm having a rouing issue the vEdge blocking something.  I can't tell.  tcpdump is not cooperating, nor does any tool available via vManage console.

 

Is there anyone out there that has done this using a vEdge? 

 

I tried to do some tcpdumps, but it doesn't look like tcpdump really works.  If I run captures from the vmanage console it shows no packets at all.  go figure as we are doing all kinds of stuff on this interface so how there is no traffic is comical.

 

BTW we know (from the ASA tunnel) DNS is setup correctly. so not sure where to go here.  if I do a nslookup from an instance to our dns server, that works fine, It's the cloud dns component that is having the trouble.  again, this all works via the ASA tunnel when it was active during my test.

 

A puzzle indeed.  I hope I have explained this well.

 

I opened a TAC case, but TAC usually very lethargic on resolving sd-wan issues.  My best source is usually here or youtube.

 

Thanks again

 

12 Replies 12

Lei Tian
Cisco Employee
Cisco Employee
Hello,

Just to make sure understand your issue correctly, you have a hybrid dns scenario and the compute engine in VPC can’t resolve onprem host?
Do you have any feature enabled on vEdge that drop, intercept DNS packet?

HTH,
Lei Tian

no.  there is nothing that would drop a dns packet to my knowledge.  I have no policy routes or anything like that. just a straight route.  If I do a dns lookup directly to our dns server on prem.  It works.  If I try it via the gcp cloud dns, it does not.  so somehow that IP address seems to be the issue.

Ok, since you mentioned same setup on ASA works as expected, assume GCP DNS forwarder is not issue. Can you do the query and run tcpdump on the LAN side interface (core facing) of the vedge2000? So I think that should help to isolate the issue before or after ipsec tunnel.
HTH,
Lei Tian

Thanks for responding. Tcpdump is not working as expected. I cannot see any traffic going through the interface. I can only see traffic going to the interface. Like if I ping the interface up. That works. Nothing else does. I opened a TAC case for that too. I guess I’m driving in today to put a laptop on the core switch port and grab a wire shark capture on the port. I’ll keep you posted. Thanks again

That indeed sounds weird. If downtime is allowed, I will try reboot the vEdge 2000. Yes, please keep me posted.
HTH,
Lei Tian

Lol yes I already did that. Actually the router rebooted itself because if you run a generate Tech-Admin from vManage it actually runs a show Admin-Tech and runs the router out of memory. Another TAC case. ☹

Ok so I set up a sniffer and found the packet is not getting here. There is something that is either rerouting I am blocking it somehow. I'll keep you posted.

Cisco TAC contacted me. They verified the configuration is correct.  Now apparently they think the packet is not coming down the tunnel at all.  They have asked I reconnect the ASA and run a capture.  A huge waste of time but I see their point.  more to come. 

Yeah, I think TAC wants to make sure outbound dns forwarding is working first.

Let’s see how it goes. I suspect there is software issue on vedge. It doesn’t make sense that capture doesn’t show anything.

Thanks for responding. I'll keep you posted.

I have finally concluded the packet was in fact going out the DIA interface. I wrote policy to accept the ip range and it is now working.

sequence 231
match
source-ip 35.199.192.0/19
!
action accept

*** here's what got me ***
sequence 251
match
source-ip 0.0.0.0/0
!
action accept
nat use-vpn 0

Thanks everyone for your comments. I hope this thread will help someone else. Note that without function tools like tcpdumps or packet captures on these routers makes life very difficult.

That makes sense. The DIA data policy was sending dns query to internet.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco