Sending DNS Resolver traffic through OpenVPN Client (NAT problem)

bannerman

In case anyone is interested, I think I found why the DNS Resolver is coming up without an output-interface specified when the box is rebooted.

It seems that the code that writes the configuration for the unbound service is at /etc/inc/unbound.inc. In that file there is a section that writes the output-interface configuration. It looks like this:


	// Determine interfaces to run on
	$outgoingints = "";
	if (!empty($unboundcfg['outgoing_interface'])) {
		$outgoingints = "# Outgoing interfaces to be used\n";
		$outgoing_interfaces = explode(",", $unboundcfg['outgoing_interface']);
		foreach ($outgoing_interfaces as $outif) {
			$outip = get_interface_ip($outif);
			if (is_ipaddr($outip)) {
				$outgoingints .= "outgoing-interface: $outip\n";
			}
			$outip = get_interface_ipv6($outif);
			if (is_ipaddrv6($outip)) {
				$outgoingints .= "outgoing-interface: $outip\n";
			}
		}
	}

The code checks if each configured output interface has an IP address, and if so adds the outgoing-interface entry to the unbound config file. If the interface doesn't have an IP address it silently skips that interface and doesn't write any outgoing-interface entry for it. This creates a race condition on reboot where the entry will only be written only if the OpenVPN client has connected and received an IP address before the unbound configuration file is written and the unbound service started.

I modified this file slightly to check every two seconds for up to a minute for the interface to get an IP address. I only did it for the IPv4 code, as I'm not using IPv6 yet. This fixes the reboot issue for me.


        // Determine interfaces to run on
        $outgoingints = "";
        if (!empty($unboundcfg['outgoing_interface'])) {
                $outgoingints = "# Outgoing interfaces to be used\n";
                $outgoing_interfaces = explode(",", $unboundcfg['outgoing_interface']);
                foreach ($outgoing_interfaces as $outif) {
                        for ($outifchk=0; $outifchk < 30; $outifchk++) {
                                $outip = get_interface_ip($outif);
                                if (is_ipaddr($outip)) {
                                        $outgoingints .= "outgoing-interface: $outip\n";
                                        break;
                                }
                                sleep(2);
                        }
                        $outip = get_interface_ipv6($outif);
                        if (is_ipaddrv6($outip)) {
                                $outgoingints .= "outgoing-interface: $outip\n";
                        }
                }
        }

DerekChap

Johnpoz, you must be living under a rock if you think that's tin foil hat stuff. ISP's logging DNS actually happens all over the place - China, Russia, UK, France etc.. You look a bit silly now don't you. Ignorance is bliss though as they say ;D

DerekChap

I can verify, this issue has been around for the past 8 months or so. For as long as I have been playing about with pfSense. Restarting the OpenVPN client even though it's already set up connection is a quick fix. An annoying one at that.

Derelict

And your VPN provider can do the same thing. You are just shifting the monitoring possibility from one party to another.

DerekChap

That's true. But when your ISP already is compelled to log, then some hope is better than none. There are plenty of good ones out there if one does his/her research.

Derelict

The bottom line here is that there are things that are pretty difficult for services running on the firewall itself.

If you want this to work 100% with pfSense in its current state, set up an inside DNS resolver that can only go out over OpenVPN (Using policy routing) and block it if it tries to go out WAN (Using mark/match and NO_WAN_EGRESS). Tell your VPN clients to use that to resolve names and not the resolver running on pfSense.

That will immediately solve your current concerns.

DerekChap

Cheers for the info. I hope though that the timing issue is looked at sometime, because regardless of the use it seems like the code could do with the tiniest bit of tweaking here. Thanks

Derelict

Guaranteed if something like that was done it would break someone else.

bannerman

@Derelict:

Guaranteed if something like that was done it would break someone else.

It would be really cool if the floating rule configuration could include a NAT configuration option too. This would allow floating rules to be used to redirect traffic originating from the firewall through non-default outgoing interfaces and have the traffic NAT'd appropriately for that interface.

Derelict

It does that now.

Outbound NAT does nothing to route traffic. It merely determines what NAT occurs when traffic flows out that interface.

If the route changes, so does the NAT.

You cannot policy route traffic originating on the firewall. Period. It happens when traffic enters an interface. Traffic originating on the firewall never does that. DNS traffic from your inside DNS resolver does, thus it can be policy routed.

peppersass

@Derelict:

You cannot policy route traffic originating on the firewall. Period. It happens when traffic enters an interface. Traffic originating on the firewall never does that.

OPNsense can do it. I have my VPN clients on a VLAN and my non-VPN clients on the LAN. I added a rule to the VLAN that routes any TCP/UDP traffic with destination This Firewall and ports DNS-DNS to the VPN gateway, and a rule to the LAN that routes any TCP/UDP traffic with destination This Firewall and ports DNS-DNS to the WAN gateway. Works great. No DNS leaks for VPN clients and the non-VPN clients get faster DNS lookups.

Tried it in pfSense and it doesn't work. Sure would be nice if it did.

Derelict

No idea what OPNsense does for DNS. But it sounds like you have that and pfSense configured completely differently.