Strange issue - not sure how to fix
-
@johnpoz said in Strange issue - not sure how to fix:
And lets see what you have in there...
When I checked earlier, it was set to the wrong gateway (it was set to one of the VPN server interfaces). Now it is set to the correct gateway and everything is working again.
We seem to be having difficulty understanding each other. I will try to break this down again:
- While troubleshooting the issues I have described in this thread, I came across another post that noted curl errors for pfBlockerNG updates, which I had also been noticing in association with my inability to access feedly.com. The post indicated that the default gateway had been changed under system/routing/gateways, and changing it back to the correct setting fixed the problem.
- I checked my own instance of pfSense, and discovered that under system/routing/gateways, the wrong default gateway had been set. The default gateway was set to one of my OpenVPN server interfaces, when it should have been set to WAN. I had never initiated this change, and I have no idea how this setting got changed.
- I corrected the choice of default gateway, and immediately, DNS resolution by Unbound started working again.
- I am wondering how this change happened, and how I can prevent it from occurring again.
- I understood (perhaps incorrectly) that you suggested that if my VPN clients are set to pull routes from the VPN server when connected, this could somehow have changed the setting for the default gateway under system/routing/gateways. I am wondering how this could be, and if so, how to prevent this setting from being changed.
I hope that is clearer.
-
By default the gateway selection will be automatic... In that case pfsense will and can use the gateway it best determines to use.. This is not always the correct one... But you would want that if you have actually multiple wans and you want it to fail over to something on loss of connectivity.
If you going to use a vpn service to hide your traffic from your isp... Then you need to correctly set that up for how you want to use it.. Do you want pfsense traffic to go out it? If so then pull routes and set pfsense to use that gateway.. There is are also things you can do as a kill switch so traffic will not flow if the vpn down..
How you want your resolver or dns to flow is another thing.. do you want its resolving to use the vpn, or not? If you do - to be honest the best solution is to move your dns off pfsense so its easier to policy route the traffic.
Here is the thing - if you have issues with connectivity then yes dns will have problems - be it actual problem, or problem with say your vpn blocking all dns other than to theirs.. Have seen that..
Pfblocker while its trying to update its lists, can cause delay in unbound working.. So if that has problems updating - that could also cause problems.
-
Noted. I don't have any outgoing VPN's set up. But I did notice that under system/routing/gateways, the default gateway was indeed set to "automatic". I have changed the default to my intended interface. Hopefully this setting stays set and I don't run into this problem again.
-
That 'automatic' setting was almost certainly the cause here.
-
While auto is a good "default" settings.. Its not like it can't cause issues.. Unless you have reason to set it to automatic.. Its best to set it to specific..
I am with @stephenw10 here that could be the root of the problem... Lets see how stability is once you have set it to something specific..
So what do you have in gateways - only the 1 interface?
-
@johnpoz said in Strange issue - not sure how to fix:
So what do you have in gateways - only the 1 interface?
No, under system/routing/gateways, I have the WAN interface and my VPN server interfaces listed. I have set the WAN interface as the default gateway.
-
@pfguy2018 said in Strange issue - not sure how to fix:
nd my VPN server interfaces listed.
WHY that shouldn't be int there... No wonder you having issues!!!
Whee did you get the nonsense that you should set a gateway to yourself???
That ns1vpn you see is in my posting is to vpn where pfsense is the client!!!! Not the server..
-
I am pretty sure that the extra interfaces under system/routing/gateways (i.e. the VPN server interfaces) got added automatically when I set up the VPN servers years ago (using the built in "wizards" in pfSense). Should I remove everything other than the WAN interface? If I do that, how will the VPN clients be able to access the VPN servers?
-
The vpn server instances would have to have been assigned. Which is fine you can do that but I would not expect so see a gateway on them.
You can unassign them as interfaces and clients will still be able to connect and use them just fine, that's the default setup for an OpenVPN server.
You don't have to do anything since you've now set the WAN as your default gateway the system won't choose the VPN servers again.
Steve
-
@johnpoz said in Strange issue - not sure how to fix:
That ns1vpn you see is in my posting is to vpn where pfsense is the client!!!! Not the server..
I am not sure what you are referring to here. Which posting?
-
Dude A gateway for a vpn server your setting up would NEVER get created - you must of created it.... Because you read some guide wrong or the guide was just borked.
Pfsense is acting as the vpn server for clients to connect too... Why and the F would it need a gateway set - where would it go via it, how would it be used... Having a gateway setup to yourself is just plain bonkers when your acting as a remote server to clients. Now if your a client, ie pfsense itself connects to some vpn server out there - then yes it would need a gateway to use that...
I would fix your clearly borked setup!!
-
That makes sense. I will go ahead and remove them. So far, since I set the default gateway as WAN, I have not experienced any further DNS resolution issues.
-
OK - have removed all the other interfaces from system/routing/gateways, and have left the 1 remaining interface (WAN) as the selected default. No problems connecting to any of the VPN server instances. And DNS resolution remains functional. I will continue to monitor, but it really does appear that this problem has now been solved. Thanks again to @johnpoz and @stephenw10 .
