OpenVPN Not Connecting - Unable To Contact Daemon
-
@panzerscope said in OpenVPN Not Connecting - Unable To Contact Daemon:
The devices on my network are set to either Auto/192.168.1.1 which either way will get the DNS from PfSense
So they try to request pfSense. But the LAN ruleset does not allow this, as long as the is no floating rule passing it, as I tried hard to explain above.
which is currently configured on PfSense to look remotely at 1.1.1.1.
What pfSense does on its own, is another part.
In fact it passes out requests to the default gateway, which is WAN according to gateway status.DNS Forwarding is not enabled on my PfSense.
I also tried to explain the benefit of this and behavior and drawback without.
The issue I am facing is per my last post where disabling or enabling the Lan Subnet rule (as per the last screenshot) will either force all my clients over VPN, or none of them.
From your rules and gateway status I have no idea why this should be the case, if it's not on DNS.
In which case is the traffic passing over the VPN?
Ans as you said any, I assume, this concerns any LAN device.From one of the devices included in the VPN alias try to simply ping 1.1.1.1 and 8.8.8.8 in both cases, VPN connected and disconnected.
What do you get? -
@viragomann said in OpenVPN Not Connecting - Unable To Contact Daemon:
@panzerscope said in OpenVPN Not Connecting - Unable To Contact Daemon:
The devices on my network are set to either Auto/192.168.1.1 which either way will get the DNS from PfSense
So they try to request pfSense. But the LAN ruleset does not allow this, as long as the is no floating rule passing it, as I tried hard to explain above.
which is currently configured on PfSense to look remotely at 1.1.1.1.
What pfSense does on its own, is another part.
In fact it passes out requests to the default gateway, which is WAN according to gateway status.DNS Forwarding is not enabled on my PfSense.
I also tried to explain the benefit of this and behavior and drawback without.
The issue I am facing is per my last post where disabling or enabling the Lan Subnet rule (as per the last screenshot) will either force all my clients over VPN, or none of them.
From your rules and gateway status I have no idea why this should be the case, if it's not on DNS.
In which case is the traffic passing over the VPN?
Ans as you said any, I assume, this concerns any LAN device.From one of the devices included in the VPN alias try to simply ping 1.1.1.1 and 8.8.8.8 in both cases, VPN connected and disconnected.
What do you get?Ok, so I went back and added the rule you suggested on LAN tab regarding DNS as seen below.
Look ok to you ?
I re-read your responses, but I cannot see anything mentioning the setup of any DNS Forwarding.
Yes all my LAN devices will use the VPN, assuming I have disabled the following rule.
I can ping 1.1.1.1 or 8.8.8.8 from any device on my network whether its running over the connected VPN or over standard WAN.
-
@panzerscope said in OpenVPN Not Connecting - Unable To Contact Daemon:
Ok, so I went back and added the rule you suggested on LAN tab regarding DNS as seen below.
Look ok to you ?No, the protocol has to be "TCP/UDP" for DNS.
And this assumes, that the devices really use pfSense.My suggestion is to combine this with two port forwarding rules. One for the devices, which should go over VPN. This avoid DNS leaking, as mentioned multiple times. And a second for the rest.
This are port forwarding rule to redirect DNS and NTP to pfSense:
You have to ensure the "localhost" is added to the listening interfaces in the DNS Resolver settings.AND to the VPN add a similar rule ABOVE of this one, but set the source to the VPN devices alias and the destination to 1.1.1.1 for Cloudflare (assumes, that Cloudflare allows access from the VPN provider) or better enter the DNS of the VPN provider.
-
@viragomann said in OpenVPN Not Connecting - Unable To Contact Daemon:
@panzerscope said in OpenVPN Not Connecting - Unable To Contact Daemon:
Ok, so I went back and added the rule you suggested on LAN tab regarding DNS as seen below.
Look ok to you ?No, the protocol has to be "TCP/UDP" for DNS.
And this assumes, that the devices really use pfSense.My suggestion is to combine this with two port forwarding rules. One for the devices, which should go over VPN. This avoid DNS leaking, as mentioned multiple times. And a second for the rest.
This are port forwarding rule to redirect DNS and NTP to pfSense:
You have to ensure the "localhost" is added to the listening interfaces in the DNS Resolver settings.AND to the VPN add a similar rule ABOVE of this one, but set the source to the VPN devices alias and the destination to 1.1.1.1 for Cloudflare (assumes, that Cloudflare allows access from the VPN provider) or better enter the DNS of the VPN provider.
No problem, I can give that ago.
Looking at the screenshot provided, how are you getting the Interface to show as "Internal" ? and how are you getting the Source Address to show as RFC1918, Did you setup an Alias ?
Or do I just follow this article : https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html
-
@panzerscope
"Internal" is an interface group, which includes my internal interfaces.RFC1918 is an alias for private network ranges (RFC 1918).
So these rules are applied to all internal interface and only to private source IPs (no forwarded traffic).
The RFC1918 alias is also good to use in policy routing rules. With this you can apply the rule to none-RFC1918 only ("invert. match" checked).
So the rule is not applied to traffic for local destinations.Or do I just follow this article : https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html
Yes, I know this suggestion. It does pretty the same, except DNS request to the pfSense LAN address are not forwarded to localhost. But I don't see an advantage of this.
-
@viragomann said in OpenVPN Not Connecting - Unable To Contact Daemon:
@panzerscope
"Internal" is an interface group, which includes my internal interfaces.RFC1918 is an alias for private network ranges (RFC 1918).
So these rules are applied to all internal interface and only to private source IPs (no forwarded traffic).
The RFC1918 alias is also good to use in policy routing rules. With this you can apply the rule to none-RFC1918 only ("invert. match" checked).
So the rule is not applied to traffic for local destinations.Thanks.
So to make sure I am setting this up, as I have not setup "Internal" group for my interfaces, can I just set the Source address to "LAN Address" ? I will setup an alias for RFC1918 but what IP's should this be covering ?
I did check this article : https://docs.netgate.com/pfsense/en/latest/recipes/rfc1918-egress.html
I cannot add these to an Alias as I get an error:
-
@panzerscope said in OpenVPN Not Connecting - Unable To Contact Daemon:
So to make sure I am setting this up, as I have not setup "Internal" group for my interfaces, can I just set the Source address to "LAN Address"
"LAN subnets"!
However, this is the source, not the interface. Since you only have one interface, there no need for an interface group.You have to select "networks" for the type in the alias.
-
@viragomann said in OpenVPN Not Connecting - Unable To Contact Daemon:
@panzerscope said in OpenVPN Not Connecting - Unable To Contact Daemon:
So to make sure I am setting this up, as I have not setup "Internal" group for my interfaces, can I just set the Source address to "LAN Address"
"LAN subnets"!
However, this is the source, not the interface. Since you only have one interface, there no need for an interface group.You have to select "networks" for the type in the alias.
Awesome thanks.
I have created the RFC1918 Alias, my Port Forward rule for DNS now looks like :
Checking that is correct before I move ahead with NTP and then the rules for VPN.
I also ensured that the localhost is added to the listening interface for DNS:
-
@panzerscope said in OpenVPN Not Connecting - Unable To Contact Daemon:
Checking that is correct before I move ahead with NTP and then the rules for VPN.
Yes, looks well.
But you will need an additional rule for the VPN devices, as mentioned above.I also ensured that the localhost is added to the listening interface for DNS:
Again, this setting is for pfSense only.
If you want to forward client requests to Cloudflare go to the DNS Resolver settings and check "DNS Query Forwarding".
If you do this with DoT also check the SSL/TLS option below:
-
@viragomann said in OpenVPN Not Connecting - Unable To Contact Daemon:
@panzerscope said in OpenVPN Not Connecting - Unable To Contact Daemon:
Checking that is correct before I move ahead with NTP and then the rules for VPN.
Yes, looks well.
But you will need an additional rule for the VPN devices, as mentioned above.I also ensured that the localhost is added to the listening interface for DNS:
Again, this setting is for pfSense only.
If you want to forward client requests to Cloudflare go to the DNS Resolver settings and check "DNS Query Forwarding".
If you do this with DoT also check the SSL/TLS option below:Many thanks for all your help.
So my rules are now as below:
"Valak Server Apps" is the device I am wanting over the VPN as that contains my Plex server.
I would have chosen the PureVPN's DNS servers but they are being a pain about it at the moment, will switch that later.
-
@panzerscope
Exactly this way.I would have chosen the PureVPN's DNS servers but they are being a pain about it at the moment, will switch that later.
Ensure that DNS works on the concerned device.
-
@viragomann said in OpenVPN Not Connecting - Unable To Contact Daemon:
@panzerscope
Exactly this way.I would have chosen the PureVPN's DNS servers but they are being a pain about it at the moment, will switch that later.
Ensure that DNS works on the concerned device.
Thanks.
I have checked, I can ping 1.1.1.1 from my VPN connected device (Valak Server Apps). I just wandered over to the Firewall>Rules>LAN Tab and noted the following DNS entry
I assume this is normal? I am fairly sure that has been there since day one, but cannot be confident.
I can also see the rules I just setup on Port forwarding are showing in the same area as well. I assume I do not need to set a specific Gateway for the rules ?
Thanks again.
-
@panzerscope
The first one might be manually added.
The red framed are from the NAT rules.
With your recent rule set they will never be applied, since the are other matching rule above of them.
You can also disable the filter rule association for these rules.
-
@viragomann said in OpenVPN Not Connecting - Unable To Contact Daemon:
@panzerscope
The first one might be manually added.
The red framed are from the NAT rules.
With your recent rule set they will never be applied, since the are other matching rule above of them.
You can also disable the filter rule association for these rules.
Many thanks.
Where would I find the "Filter Rule Association" setting ?
-
@panzerscope
In the NAT rule.
If you have this selected pfSense adds a filter rule.
If you select "pass" it lets the traffic pass without a filter rule. -
@viragomann said in OpenVPN Not Connecting - Unable To Contact Daemon:
@panzerscope
In the NAT rule.
If you have this selected pfSense adds a filter rule.
If you select "pass" it lets the traffic pass without a filter rule.Thanks.
I may be oversimplifying my next question, but isn't it easer to just set the Filter to "Pass" ?
-
@panzerscope
This depends on your needs. If you let pfSense create a rule you can verify it in your rule set.
If you let it create an "unassociated" rule you can also edit it. For instance, turn it into a policy-routing. -
@viragomann said in OpenVPN Not Connecting - Unable To Contact Daemon:
@panzerscope
This depends on your needs. If you let pfSense create a rule you can verify it in your rule set.
If you let it create an "unassociated" rule you can also edit it. For instance, turn it into a policy-routing.Ok thanks, will leave it as it is.
I note that since changing these rules with respect to DNS that my pfBlockerNG is seemingly no longer blocking ads. I have loaded up a few websites now and ads are now displaying. Worth noting that I have killed the VPN connection to make sure it was nothing to do with that.
As we have used the RF1918 in recent DNS rules I am wondering if it is causing issues, I ask as when I go to pfBlockerNG configuration, that the IP and DNSBL use these private addresses for it to operate (as per below screenshots) and wondered if I have inadvertently done something.
Any thoughts ?
-
@panzerscope
This might be due to DNSBL. Is the service even running? If not, try to restart it. -
@viragomann said in OpenVPN Not Connecting - Unable To Contact Daemon:
@panzerscope
This might be due to DNSBL. Is the service even running? If not, try to restart it.I restarted it a couple of times and now seems to be resolved.
I am still having a curios issue with the VPN.
I have deleted all my prior VPN related rules to start fresh. What is really odd is if my VPN is connected ALL my devices are being routed through the VPN, despite my LAN rules as shown below should be sending all my traffic through my WAN as there are no VPN related rules in existence and the standard rule for all LAN Subnets being sent through the default gateway (AKA my WAN)
I noted that I could stop this behaviour by going into the VPN client and checking the following option.
Now, with the VPN connected, my clients now use the WAN and not the VPN. However this is no help as I do not want to use a -Rout Up script, and obviously with this setting enabled if I try to use my LAN rules to direct devices out to the VPN, it is not working.
**Sigh, I really do not know why this is such a pain.