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 22.214.171.124/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 126.96.36.199 255.255.224.0 192.168.240.129
188.8.131.52/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 184.108.40.206
10 220.127.116.11/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.
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.
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.