Loopback dns at primary site and remote vpn site

[hooz400]

Hello,
Had a quick question on setting up loopback dns on sonicwall remote side of a VPN for my situation. I have an on prem 3cx server at one location serving those local IP phones. They also have another location that is connected to that main location over IP Sec VPN. Currently everything is working great, at the remote location I just have to manually enter the 3cx provisioning link into a new phones gui(which is using local IP currently, not FQDN) and phones register across the VPN and work great, they have around 25 or so at that remote location no issues. However I know that split DNS is coming and using the local IP on the provisioning link will no longer be possible. I believe I see how the loopback dns setup on the main sonicwall would be done, in the nat policy the original dest is the WAN IP (which is the public IP on main site and where the 3cx FQDN resolves now), however my question would be on the remote site, over that vpn. How would the loopback dns be setup on the remote sonicwall? NAT policy with the original destination set to the WAN IP of that primary site and translated destination the local IP of that 3cx at the main site? Hope that question makes sense, I just need the remote site to be able to resolve that FQDN over that VPN so the phones will continue to register and work properly in V20 when the FQDN is mandatory for provisioning. I do realize I could drop SBC on that remote site, however I believe I have everything I already need, just need to get those loopback dns setups done properly on main and remote sonicwall. Thanks

 

[SweetAction]

It depends on what DNS server those phones at the remote site use.

If they use an internal DNS server, you could just make the DNS record on the internal DNS server the internal IP of the 3CX server and skip the hairpinning/loopback conversation altogether. But if they use a public DNS server and get the public IP, you need to make sure that public IP sends them to 3CX. Likely your site to site VPN is split tunnel, meaning that resolving the public IP from the remote site might be fine without any hairpinning needed.

TL;DR - it depends on how your remote site resolves DNS and routes traffic to the main site.

 

[hooz400]

Thanks for the reply. There is no onsite dns server, i had just planned on setting up the hairpin on the sonicwall at the main site so those local IP phones could resolve the FQDN to that local IP of the PBX server. It was the remote site I just wasnt sure about. The remote site does use public dns as well. If I dont touch anything at all, the remote site would resolve over the WAN to main site, however then wouldnt all my voip traffic be going over the WAN to main site instead of the VPN like it does now? Thats why i figured i'd need to setup the hairpin on the remote sites sonicwall as well.

 

[SweetAction]

owever then wouldnt all my voip traffic be going over the WAN to main site instead of the VPN like it does now?

Correct, it would go over the WAN

Thats why i figured i'd need to setup the hairpin on the remote sites sonicwall as well.

Hairping won't fix this. All hairpin does is allow traffic to exit the WAN and turn right back around (SRC and DEST are the same) without being dropped. For your use case, where you want to route over the tunnel instead of the WAN, you will need SplitDNS.

 

[hooz400]

Cool, so it sounds like the loopback on the primary sonicwall and remote sonicwall is what im looking for. What I was wondering about if the remote sonicwall loopback setup. Would it just look like this
Translated Source : WAN IP of the primary site (which is the public IP where the FQDN resloves to that 3cx server)
Original Source: Same WAN IP as above
Translated Destination: Local 3cx server IP at the primary site
Would that take any traffic at the remote site going out to that primary public IP (where the FQDN now resolves), turn it right back around and over that VPN back to primary site network?

 

[SweetAction]

Cool, so it sounds like the loopback on the primary sonicwall and remote sonicwall is what im looking for. What I was wondering about if the remote sonicwall loopback setup. Would it just look like this
Translated Source : WAN IP of the primary site (which is the public IP where the FQDN resloves to that 3cx server)
Original Source: Same WAN IP as above
Translated Destination: Local 3cx server IP at the primary site
Would that take any traffic at the remote site going out to that primary public IP (where the FQDN now resolves), turn it right back around and over that VPN back to primary site network?

No, loopback on the remote sonicwall will not solve your issue for the remote site. Traffic will not go over the VPN if the DNS for remote phones resolves to the WAN IP address of the 3CX server.

For the primary site, loopback will not keep the traffic internal - it will exit the WAN and re-enter the firewall.

Loopback/hairpinning is a crutch to keep things working, but doesn't keep the traffic local. You either need to address by IP address or handle DNS so it resolves the internal IP.

 

[hooz400]

Ok thanks. For the primary site I was just going off what 3cx recommended for setting up split dns for V20. They have sonicwall specific loopback setup on their site, youre saying that wont even work for the primary site where the server resides like they say it will? Just trying to get the phones to register using the fqdn instead of IP on the provisioning link because from what I can tell V20 wont allow to use IP. If loopback setup in fact wont work, then my only option is to spin up a dns server to serve the IP phone/voice network and setup split dns on it? Was trying to avoid dns server setup if loopback setup on the soncwall would serve the purpose of allowing the IP phones on the local lan to register to the local pbx using fqdn like it sounds will be required in V20.I must be missing something on why the sonicwall loopback wouldnt take care of that.

 

[SweetAction]

Ok thanks. For the primary site I was just going off what 3cx recommended for setting up split dns for V20. They have sonicwall specific loopback setup on their site, youre saying that wont even work for the primary site where the server resides like they say it will? Just trying to get the phones to register using the fqdn instead of IP on the provisioning link because from what I can tell V20 wont allow to use IP. If loopback setup in fact wont work, then my only option is to spin up a dns server to serve the IP phone/voice network and setup split dns on it? Was trying to avoid dns server setup if loopback setup on the soncwall would serve the purpose of allowing the IP phones on the local lan to register to the local pbx using fqdn like it sounds will be required in V20.I must be missing something on why the sonicwall loopback wouldnt take care of that.

Loopback will make the phones in primary site work, but what's actually happening is that traffic is going out the wan, turning around, and coming back in. That trick only works for the primary site.

No amount of loopback on the secondary site will make the secondary site traffic route over the VPN instead of out the WAN.

 

[Alphabetic]

At 2nd site do this https://www.sonicwall.com/support/k...for-internal-private-network/220627023353147/

 

[hooz400]

Awesome. So at the remote site say my phones are on x3 interface, and my sonicwall is currently acting as the dhcp server. I just enable dns proxy, add that static dns entry pointing the fqdn to the local IP of the 3cx server at the main site, and then just add the local IP of interface x3 into the primary dns spot in the dhcp settings on interface x3? Im assuming I would want to keep a second dns entry in there for public dns as well, like the 8.8.8.8 in the example? And this would only affect my voice subnet that resides on X3? DNS on all the other interfaces would be unaffected. Thanks

 

[hooz400]

Good Morning, wanted to come back and thank you guys for the help. At the end of the day I can always just stop going over the vpn and use SBC at the remote site right? I guess i always have a handful of options, but thanks for the Firewall and dns assistance on ths one. Just trying to get ready for that required use of the fqdn for provisioning.

 

[SweetAction]

At the end of the day I can always just stop going over the vpn and use SBC at the remote site right?

Correct