SOLVED: Overriding entire domain w DNS forwarder over OpenVPN site2site tunnel?
-
I posted this in this thread but I thought it would be better in this forum.
I have a site-to-site OpenVPN tunnel to my job, and I want to make sure that DNS requests to whatever.company.local get resolved on the company's Active Directory DNS server. I want everything else to be resolved on the DNS servers I have here. I had this working when I was using IPSec (as I explained in the other thread) but I can't get it to work in this implementation. I was hoping for some advice.
-
I use both OpenVPN and IPSec site-to-site tunnels and I've not had to put a static route into an OpenVPN tunnel yet, and had to put a static route into every IPSec tunnel - complete opposites of each other.
Since you've switched implementations, have you removed the static route(s) to match?
-
Yes, I've removed the static routes. Currently there are NO static routes set up in the system.
Are you saying you had to setup static routes for IPSec to get what I described working (DNS forwarder using an authoritative server on the other side of the VPN), or that you needed a static route just to get the tunnel itself working?
-
My experience: IPSec site-to-site tunnel, DNS forwarder forwarding to DNS on remote server requires a static route from local net to remote net.
Just in case you didn't realise/know, the static route applies to the LAN interface.
-
My experience: IPSec site-to-site tunnel, DNS forwarder forwarding to DNS on remote server requires a static route from local net to remote net.
Just in case you didn't realise/know, the static route applies to the LAN interface.
Yes I fully understand this.. I explained that in my first post, and in the other thread I linked to in the first post. What I'm trying to do is achieve the same thing using an OpenVPN site-to-site tunnel. Since an entry in the routing table already exists with an OpenVPN tunnel, there is no reason to add one (and when I do the behavior doesn't change), yet even with the routing entry the DNS forwarder does not work.
You said you've used OpenVPN tunnels before. Were you able to achieve this with those?
-
Anyone? I would really prefer to use OpenVPN but this issue is going to cause me to reconsider unfortunately :( It's such a shame, as OpenVPN is so flexible, it seems like there should be an easy way to resolve it. Any help is greatly appreciated.
-
You said you've used OpenVPN tunnels before. Were you able to achieve this with those?
dnsmasq & OpenVPN works first time, every time for me, no static routes, no black magic.
Sorry, can't be more help than that.
-
You said you've used OpenVPN tunnels before. Were you able to achieve this with those?
dnsmasq & OpenVPN works first time, every time for me, no static routes, no black magic.
Sorry, can't be more help than that.
Okay so just to be clear, you have a DNS server on the remote side of openvpn site-to-site connection, and you are overriding an entire domain in DNS forwarder, telling it to resolve at that DNS server, and it works? As in, your local subnet is say 10.1.2.0/24 and the remote is 10.11.12.0/24, and the DNS server for domain.local is 10.11.12.13. You tell DNS forwarder to override domain.local and send requests for that domain to 10.11.12.13, and a local machine 10.1.2.3 can resolve kitten.domain.local correctly?
Sorry if I'm being annoying, I'm just in awe, because I couldn't get this to work before, on 1.2.2, and then my hard drive in the router died and replaced it, did a fresh install of 1.2.3 and am having the exact same result; it won't work. If it's working for you there must be something I'm doing wrong…
-
Real-world example from a customer. Two sites, 10.0.0.0/8 and 192.168.0.0/24 linked by site-to-site OpenVPN tunnel.
The "remote" site is on 192.168.0.0/24. Screenshots of its DNS forwarder and static routes (ie. none) are attached.
The firewall itself is 192.168.0.1 at the "remote" site.
firewall# ifconfig sk0 | grep netmask
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255Try to resolve an IP using public DNS. These shell snippets were executed on the firewall itself; the client PCs use the firewall as their DNS server, naturally.
firewall# host datastore2.XXX.co.uk
datastore2.XXX.co.uk has address 67.215.65.132
Host datastore2.XXX.co.uk not found: 3(NXDOMAIN)Not found, not surprisingly. The firewall isn't using itself as a DNS server and OpenDNS doesn't know where datastore2.XXX.co.uk is!
Try again, specifying the firewall's DNS forwarder
firewall# host datastore2.XXX.co.uk 192.168.0.1
Using domain server:
Name: 192.168.0.1
Address: 192.168.0.1#53
Aliases:datastore2.XXX.co.uk has address 10.0.0.1
Which is the correct answer.
The OpenVPN tunnel is nothing special:
tun0: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
inet6 fe80::211:2fff:fece:8673%tun0 prefixlen 64 scopeid 0x7
inet 192.168.2.2 –> 192.168.2.1 netmask 0xffffffff
Opened by PID 384There is nothing else to configure or show, I'm afraid.
</up,pointopoint,running,multicast> -
Bern,
Thanks so much for that post. After trying some of those steps, like trying to reach the remote subnet from the router, I was able to figure out the problem.
The remote machine with the DNS server has two NICs on different networks. The primary NIC, with the default gateway, is not the network that resolves back to the router. I was already aware of this from previous VPN setups, so I already had a persistent static route for my local subnet here back to pfSense router. This is what made me think it couldn't have been this kind of problem, because clients on this end could contact that machine without a problem.
It wasn't until after I tried to use the local router to connect to that machine that I realized that it couldn't, but it could connect to other machines on the remote end (which used the correct gateway by default). What I needed to do was add a persistent static route on that machine that routed the "internal" subnet of the VPN (172.whatever) back to the gateway, and all is well now.
Most users wouldn't run into this but hopefully this helps someone.
Thanks again!