Route all client vpn traffic to only one IP on network
-
I have successfully setup an OpenVPN connection between my Android phone and my pfSense router. I can ping and ssh into all the servers on the network via the VPN.
Whenever this VPN from Android is used, however, I want the client to be routed directly to one specific server on the network only. Similar to how port forwarding works on the wan. Is this possible? I've done a lot of research to try and find a solution but can't find an answer
Any tips will be greatly appreciated.
I am using pfSense version 2.1.4-RELEASE (amd64)
-
well create your firewall rules to only allow access to what you want it to have access too.. In port forwarding the user goes somewhere ie public IP:port - this gets redirected to the private IP:port.. Once your on the vpn you have no need for a nat/port forward to get where you want to go.. So just go direct to privateIP:port of the service you want to use..
-
What he said.
There's a difference between forcing all access attempts to any host to a specific host instead and only allowing access to a specific host.
The former is easier than the latter, but both are typically possible.
What, exactly, are you trying to achieve?
-
Thank you both for your replies.
Good question, "Derelict". I probably should have stated my purpose from the onset. I have a email server on my DMZ that I want to access securely from Android over the VPN instead of from the WAN. This email server has a split DNS, and I am using K9 email client on Android to access the email on the server. As it stands now, if K9 issues the email server's FQDN (ie mail.domain.com) over the VPN the FQDN points to the MX record on the Internet which I don't want. If I can get the FQDN to go directly to the email server (like I would with port forwarding from the WAN) the server's split DNS would point it to the internal IP like I need.
I'm relatively new to both pfSense and email servers so I'm struggling with solving this problem so that any pointers will be very appreciated.
Regards
-
if your using a split dns, and you say you locally resolve your email server FQDN to its private local IP when your local.. Then when your on your vpn you should as well when you had your vpn client your local dns to use.
Sounds like your vpn client is not using your local dns..
-
Thank you for your fast reply, "johnpoz".
During my testing I tried to set the local DNS settings but it didn't work.
Here's the steps that I took:
On pfSense Server:Went to VPN -> OpenVPN -> Server tab
Under Client Settings Section, Checked "Provide a DNS server list to clients"
For Server #1 added the internal DNS server IPThis did not work. After reloading the ovpn file on Android, when I pinged the fqdn, it still tried to connect to the MX on the Internet
On Client OpenVPN (on Android):
Went to "IP AND DNS" tab
Under DNS Section, checked "Override DNS Settings by Ser…"
For DNS Server I added the internal DNS server IP
For Backup DNS Server I left Google's DNSThis did not work either. When I pinged the fqdn, it still tried to connect to the MX on the Internet
Did I do something wrong?
-
did you validate that what your doing a query for actually resolves to what your wanting to resolve too?
-
I'm new to this "Johnpoz" so can you please give me some additional information on what you mean?
-
when you query pfsense running on dns your sure its resolving to private IP for your split dns?? use your fav dns query tool, nslookup, dig, drill, host, etc.. or even just a ping for that matter.. Seems to me this is either not working how you think its working or your vpn client is not using your dns.
-
That's a good suggestion; however, if the split dns (the internal dns) wasn't working then the email server wouldn't be sending and receiving emails over the Internet.
I'm only having trouble with the MTA connection through the vpn from Android. Unless I've misinterpreted your suggestion, we can probably rule out the split dns failure, can't we?
I think that the latter part of your suggestion "…or your vpn client is not using your dns" is more accurate. If I ping mail.domain.com from Android, it returns the IP of the WAN provided by my ISP not the Internal IP of the split dns like I need.
-
It's silly to try to use a private DNS server and leave google DNS as a backup. All of your configured DNS servers should return the same data if queried side by side from an endpoint.
If you would get a real DNS tool like dig or drill you could ask specific DNS servers to resolve for you and see what's really going on.
-
Thanks again for the assistance, guys.
It's silly to try to use a private DNS server and leave google DNS as a backup
Good suggestions, I will remove the Google dns as the backup
All of your configured DNS servers should return the same data if queried side by side from an endpoint
Are you sure that's accurate? An internal split dns should, by design, return the internal server mx record (internal ip); whereas an external dns like google's will return the external mx record (which will be the WAN's ip). At least that's how I built the email server from documented sources and it works perfectly via the Internet (just not from Android over the VPN). Am I missing something?
If you would get a real DNS tool like dig or drill you could ask specific DNS servers to resolve for you and see what's really going on
When I built the email server, I used dig domain.com mx, dig domain.com any, and host $(hostname) to verify that the email server returned the correct internal mx and that the router returned the correct external mx record. Everything worked as documentation and as expected.
I know that everything on the server side works as it should, including the dns servers (both the internal mx and the mx on my isp's site).
The problem that I'm having is the dns that Android is using. I tried removing Google as the backup dns (as you suggested) but when I ping the fqdn it still tries to use the wan ip not the internal ip from the internal split dns server.
I just noticed NOYB's post called "Local vs VPN DNS Name Resolution" (https://forum.pfsense.org/index.php?topic=77421.0) and it seems to be the same problem that I'm having. OpenVPN is using the dns settings of the host client (in my case Android) instead of the dns settings specified by OpenVPN.
Am I off track here or are my assumptions that I listed above correct?
Again your suggestions and your patience with me is very much appreciated.
Regards
-
"All of your configured DNS servers should return the same data if queried side by side from an endpoint"
"Are you sure that's accurate?"Yes derelict is right on point here..
His point is if you have a client and you give it 2 dns server address it can use… Those dns server should return the same info..
If you use a local dns 192.168.1.100 for example that knows about say host.madeupnotpubliddomain.tld and returns the address 192.168.1.200 for example... It is completely pointless to also point that client at 8.8.8.8 that no freaking clue what host.madeupnotpubliddomain.tld and can never return your address 192.168.1.200 for that..
You really can never be sure what dns a client is going to ask when you give them more than one, or which one will answer first if you ask them both, etc.. So setting more than 1 dns that can give you different answers for the same fqdn is a BAD idea!!
if you always want to be able to resolve host.madeupnotpubliddomain.tld, having googledns or opendns or your isp anywhere in your client is going to be BAD idea.. no public server are going to resolve host.madeupnotpubliddomain.tld.. So you need to always ask your local dns, so it can resolver that.. You could then have your local dns forward or resolver when you want to look up publid fqdn like www.google.com or pfsense.org, etc..
Now if you have 2 dns locally that resolve host.madeupnotpubliddomain.tld, then sure you can setup to use both of them..
-
All of your configured DNS servers should return the same data if queried side by side from an endpoint
Are you sure that's accurate? An internal split dns should, by design, return the internal server mx record (internal ip); whereas an external dns like google's will return the external mx record (which will be the WAN's ip). At least that's how I built the email server from documented sources and it works perfectly via the Internet (just not from Android over the VPN). Am I missing something?
Yes. You are missing that all configured name servers for a particular client host should all return the same answer at the same time.
When you configure split DNS, outside servers return outside answers and inside servers return inside answers but the client host should not be asking inside and outside servers to resolve names when joined to any network. If joined outside they should ask outside servers. If joined inside they should ask inside servers.
You need to make a decision whether your VPN clients think they are inside or outside your network (since they are really both simultaneously) and cofigure them to ask the correct DNS servers for resolution based on that decision.
If you would get a real DNS tool like dig or drill you could ask specific DNS servers to resolve for you and see what's really going on
When I built the email server, I used dig domain.com mx, dig domain.com any, and host $(hostname) to verify that the email server returned the correct internal mx and that the router returned the correct external mx record. Everything worked as documentation and as expected.
I know that everything on the server side works as it should, including the dns servers (both the internal mx and the mx on my isp's site).
The problem that I'm having is the dns that Android is using. I tried removing Google as the backup dns (as you suggested) but when I ping the fqdn it still tries to use the wan ip not the internal ip from the internal split dns server.
I just noticed NOYB's post called "Local vs VPN DNS Name Resolution" (https://forum.pfsense.org/index.php?topic=77421.0) and it seems to be the same problem that I'm having. OpenVPN is using the dns settings of the host client (in my case Android) instead of the dns settings specified by OpenVPN.
Am I off track here or are my assumptions that I listed above correct?
Again your suggestions and your patience with me is very much appreciated.
Regards
If there's a problem with any of this on the android client that will have to be handled at the android client.
you can use dig @8.8.8.8 www.google.com a|ns|ptr|txt|aaaa|etc to specifically ask google DNS to resolve a name for you. Replace 8.8.8.8 with any DNS server you wish to ask to resolve a name.
You really can never be sure what dns a client is going to ask when you give them more than one, or which one will answer first if you ask them both, etc.. So setting more than 1 dns that can give you different answers for the same fqdn is a BAD idea!!
This. There is no "try this one then try that one if it fails." There is no guarantee. It is completely up to the client which name server it asks first, sequential, simultaneous, round-robin, whatever.
-
And, while on the subject, configuring outside servers to return RFC1918 addresses subjects you to dealing with DNS rebinding protections. Ran into this a few times running internet for a hotel meeting space. Told them to slap their network admin in the face hard when they got back and use a hosts file entry. Many of them were even 192.168.0.X - like that will work reliably on random, private networks.
