Install the app
How to install the app on iOS

Follow along with the video below to see how to install our site as a web app on your home screen.

Note: This feature may not be available in some browsers.

Solved VPN Plus connection not able to reach internal DNS or subnet

Hi All,

hoping for a little assistance pls and hope I'm in the right forum for it.

My setup:
OSX host(s) making OpenVPN (Viscosity VPN client: www.sparklabs.com/viscosity) connection to RT2600 configured w. VPN Plus Svr.
Internal DNS Svr sitting on DS NAS DSM v6.2.2 w. internal LAN interface in RT2600 LAN subnet.


My issue:
The host(s) make successful vpn connections to the RT2600 - I can see that in the client & svr logs and in Svr UI.
However, both routing to the internal LAN subnet and/or DNS Svr (Internal View) do not seem to work.

What am I missing pls?

Background:
RT2600:

2nd router in a DMZ setup. It sits behind an external router and calls are port fwdd to it.
"Internet > Connection > Primary Interface“ set to Manual w. 10.x.x.x address.
"Internet > Connection > Manually Configure DNS Server“: Preferred points to DNS ‘External View’ : Alternative points to a.n.other DNS addr.
SRM runs DHCP for LAN clients w. DNS set to 'Internal View' for DSM DNS Svr.
Standard VPN 'OpenVPN' setup using VPN Plus Svr package.
UDP Proto : ‘Allow Clients to access Server’s LAN’ ticked. : ‘Use manual DNS’ defaults to Preferred above. N.B. I have tried to set this to LAN’s DNS Internal View w. no success.

DSM:
DSM has a foot in each subnet (i.e. LAN2 sits in the RT2600's LAN subnet -192.168.x.x- and LAN1 in same subnet as RT2600's WAN subnet -10.x.x.x).
Further the DNS Svr sitting on DSM has an "Internal View" - 192.168.x.x addr’s - and an "External View" - 10.x.x.x addr’s - providing different IP's to clients depending from where they query the DNS.

This all works perfectly irrespective of whether the client presently sits in 192.168.x/24 or 10.x.x/24. (i.e. Firewall config appears all good and DNS config - prior to VPN also appears all good).


Hosts:
OSX hosts (Mojave, Catalina) using Viscosity client. Logs and UI show connection to VPN successful.
I have set the 'Internal View' to allow queries from both 192.168.x.x _and_ the OpenVPN 172.22.x.x subnets.
However, tracerouting, pinging, Network Discovery and/or querying the Internal DNS does not work.
Given the DNS setup works for these same hosts, I am working on the assumption that DNS config is all good and what I am facing is a routing issue w. the VPN.

VPN Specific:
I am testing VPN connectivity with the host hotspotted to 4G phone, so completely external.
I have tried to set ‘dhcp-options DNS <DNS Svr Addrs>’ in the ovpn config.

If I leave VPN Plus Svr to determine Traffic Routing, it sets itself to “Split DNS”. But that means “Resolver 1” gets set to whatever DNS is set by the Hotspot network and Resolver 2 then gets whatever I have configured in dhcp-options.

And no internal DNS queries succeed.

However, if I specifically set “ALL Traffic to run over the VPN interface”, it sets itself to use “Full DNS” which then reverses the Resolver order.

But still no internal DNS queries succeed.

Questions:
Possibly unrelated, but a little understanding never hurts. What is the significance of the "Internet > Connection > Manually Configure DNS Server“ setup? Given they are in the “Internet” section, I would expect they are for onforwarding requests for the SRM’s DHCP clients. But there is no Synology documentation for them.

What/Which IP is considered the Default Gateway?
What/Which IP is considered the VPN Gateway?
What/Which IP is considered the Local Network Gateway?

Where else do I need to be looking please?


Hoping I’ve laid it all out sufficiently clearly and really hoping you are able to assist pls. Below is a couple of shots of the Networking options in the Viscosity client and the route table from the host when connected to the VPN.

Screen Shot 2020-05-22 at 17.21.20.png
Screen Shot 2020-05-22 at 17.45.23.png


Internet:
DestinationGatewayFlagsRefsUseNetifExpire
0/1172.22.0.5UGSc
55​
0​
utun10
default192.168.1.1UGSc
0​
0​
en0
<Public IP>/32192.168.1.1UGSc
1​
0​
en0
127127.0.0.1UCS
0​
0​
lo0
127.0.0.1127.0.0.1UH
1​
1939386​
lo0
128.0/1172.22.0.5UGSc
1​
0​
utun10
169.254link#5UCS
1​
0​
en0!
172.22/24172.22.0.5UGSc
1​
0​
utun10
172.22.0.1/32172.22.0.5UGSc
0​
0​
utun10
172.22.0.5172.22.0.6UHr
14​
0​
utun10
172.22.0.5/32link#15UCS
0​
0​
utun10
192.168.1link#5UCS
1​
0​
en0!
192.168.1.1/32link#5UCS
1​
0​
en0!
192.168.1.1<MAC Address>UHLWIir
7​
61​
en0
1173​
192.168.1.129/32link#5UCS
1​
0​
en0!
192.168.1.129<MAC Address>UHLWI
0​
30​
lo0
192.168.1.255ff:ff:ff:ff:ff:ffUHLWbI
0​
18​
en0!
192.168.XX172.22.0.5UGSc
1
0
utun10
224.0.0/4link#15UmCS
0​
0​
utun10
224.0.0/4link#5UmCSI
1​
0​
en0!
224.0.0.251<MAC Address>UHmLWI
0​
0​
en0
255.255.255.255/32link#15UCS
0​
0​
utun10
255.255.255.255/32link#5UCSI
0​
0​
en0!
 
I use viscosity with All traffic set to: Send all traffic over VPN and DNS setting to Disabled. True I don't run a DNS service on a NAS as you, but have found that full and split setting caused problems on my end.

Have you tried running with disabled setting? I can access all internal devices after VPN is active with no problem as all.
 
Last edited:
Don't have time to read the whole thing but my experience is this...

RT2600ac: primary Internet DNS server is pointing to my DSM's DNS server, secondary is Cloudflare. This was so Safe Access would defer to my internal DNS because it uses (or used to) the SRM Internet DNS's after intercepting outbound requests.

Running VPN Plus for OpenVPN (TCP), L2TP/IPsec VPN, SSL-VPN. Also have OpenVPN (UDP) running on the NAS too. Why have two OpenVPN servers? Because I couldn't get a minute on VPN Plus' OpenVPN (UDP or TCP) without it disconnecting.

Both OpenVPN server client configs have the same adaptions: DHCP DNS and domain name, and server name. The only real difference between them is the protocol used, and that's so the SRM firewall/port forwarding will direct to the right server.

Both client configs, in the GUI, are set with a defined DNS server, no compression, and to permit access to the LAN.

DSM's firewall is set to permit OpenVPN (and other VPN client subnets) to access its services.

Edit: I forgot. I also run DNS server on SRM. This is a slave zone connected to DSM's DNS server (primary zone). The VPN clients are set to the SRM router (LAN IP) for their DNS server.


=======
BTW only used Tunnelblick client on Mac.

BTW #2 you might as well get a full allocation of free VPN Plus licences that Synology are giving away until September. I prefer the SSL-VPN client on iOS. The web interface + SSL-VPN agent on desktop isn't so bad once you're used to it.
 
Thanks Rusty.

Yes, have now tried with DNS disabled with no luck.

I use viscosity with All traffic set to: Send all traffic over VPN and DNS setting to Disabled. True I don't run a DNS service on a NAS as you, but have found that full and split setting caused problems on my end.

Have you tried running with disabled setting? I can access all internal devices after VPN is active with no problem as all.
 
Thanks fredbert,

nice detailed response.
I have taken advantage of the free VPN licences, hence where I am now.

Just a couple of clarifications if I may pls?

RT2600ac: primary Internet DNS server is pointing to my DSM's DNS server, secondary is Cloudflare. This was so Safe Access would defer to my internal DNS because it uses (or used to) the SRM Internet DNS's after intercepting outbound requests.

Assuming now, you do not have the DMZ setup I'm using. So your SRM Internet Primary points to a 192.168.x.x (or "internal LAN subnet") as opposed to an "external (or public) subnet" like mine presently does? Correct?
Will try that out.

Both OpenVPN server client configs have the same adaptions: DHCP DNS and domain name, and server name. The only real difference between them is the protocol used, and that's so the SRM firewall/port forwarding will direct to the right server.

Both client configs, in the GUI, are set with a defined DNS server, no compression, and to permit access to the LAN.

These are the comments need most clarification pls. There are 2 paragraphs in the above sub-quote.
1. OpenVPN server client configs ...... and
2. client configs, in the GUI

Am I reading you correctly if I interpret the above as being;
1. Your Tunnelblick ovpn configs ...... and
2. The OpenVPN setup config in the SRM GUI

DSM's firewall is set to permit OpenVPN (and other VPN client subnets) to access its services.

Edit: I forgot. I also run DNS server on SRM. This is a slave zone connected to DSM's DNS server (primary zone). The VPN clients are set to the SRM router (LAN IP) for their DNS server.

DSM Firewall: I have duplicated the LAN side (LAN2) firewall rules on DSM to allow access from the Ovpn 172.22.x.x clients subnet to those internal LAN services such as SMB, AFP and Bonjour. I'm expecting that's correct as it's the LAN side I want to interact with and not the DMZ side.

I too also run DNS on SRM LAN side as a slave to the DSM LAN side DNS. I hadn't tried to set the Ovpn clients to use the SRM DNS, so will also give that a shot, thanks.
 
Last edited:
"RT2600ac: primary Internet DNS server is pointing to my DSM's DNS server, secondary is Cloudflare. This was so Safe Access would defer to my internal DNS because it uses (or used to) the SRM Internet DNS's after intercepting outbound requests."
Assuming now, you do not have the DMZ setup I'm using. So your SRM Internet Primary points to a 192.168.x.x (or "internal LAN subnet") as opposed to an "external (or public) subnet" like mine presently does? Correct?
Will try that out.
Correct: no DMZ topology. I've a single 192.168.x.y LAN (plus another for Guest WiFi).

Network Center -> Internet -> Connection
Preferred DNS server: 192.168.x.B (IP of DSM NAS)​
Alternative DNS server: 1.1.1.1​

Network Center -> Local Network -> General
Local IP / IP Address: 192.168.x.A​

DHCP Server:
Gateway: 192.168.x.A​
Primary DNS: 192.168.x.A​
Secondary DNS: 192.168.x.B​
Forward known DNS server: Disabled (stops access to SRM's primary/alternative DNS, if they happen to be direct to Internet without filtering etc.)​

SRM DNS Server:
Forward and reverse slave zones from 192.168.x.B​

From previous testing 18 months to 2 years ago: Safe Access intercepted DNS requests to 192.168.x.A and did it's thing but it resolved back to the LAN client using the DNS server's configured for SRM itself (by-passing DHCP DNS and even SRM's own DNS Server). Which is why my DNS assignment, and use of SRM DNS Server, is somewhat roundabout: it works for me.

Both OpenVPN server client configs have the same adaptions: DHCP DNS and domain name, and server name. The only real difference between them is the protocol used, and that's so the SRM firewall/port forwarding will direct to the right server.

Both client configs, in the GUI, are set with a defined DNS server, no compression, and to permit access to the LAN.
These are the comments need most clarification pls. There are 2 paragraphs in the above sub-quote.
1. OpenVPN server client configs ...... and
2. client configs, in the GUI

Am I reading you correctly if I interpret the above as being;
1. Your Tunnelblick ovpn configs ...... and
2. The OpenVPN setup config in the SRM GUI
Yes, correct. Sorry I should've been clearer.

Between the two servers the only differences are: the SSL certificate that is server generated; the TCP/UDP statement in the VPN [Plus] Server GUI and also the .ovpn file, again server generated; the subnet used for the clients.

In the .ovpn files I just checked my current edits and see they are less than I used to add:
Changed the 'remote' command to be to my FQDN and port number​
One 'dhcp-option' command for DOMAIN, so that I can be lazy and access devices by name 'nas' etc.​
Is 'float' normally enabled? Anyway mine is commented out, so disabled.​
The clients' DNS server is set in the VPN [Plus] Server GUI and is 192.168.x.A

DSM's firewall is set to permit OpenVPN (and other VPN client subnets) to access its services.

Edit: I forgot. I also run DNS server on SRM. This is a slave zone connected to DSM's DNS server (primary zone). The VPN clients are set to the SRM router (LAN IP) for their DNS server.
DSM Firewall: I have duplicated the LAN side (LAN2) firewall rules on DSM to allow access from the Ovpn 172.22.x.x clients subnet to those internal LAN services such as SMB, AFP and Bonjour. I'm expecting that's correct as it's the LAN side I want to interact with and not the DMZ side.

I've finally read your initial post. So what I think you're doing, logically, is:
  1. Untrusted networks.
  2. External router/firewall with Internet IP (or other routable IP) on WAN side, internal side to...
  3. [possibly a separate switch] 'dirty' side DMZ (in network-type's terminology, I'd not say DMZ if it was the default path through to the trusted LAN ... but that's just personal preference), aka external/untrusted subnet
  4. Both the SRM router's WAN interface and DSM NAS's LAN1 connect to the untrusted subnet.
  5. Both the SRM router's LAN switch and DSM NAS's LAN2 connect to the trusted LAN subnet.
  6. [possibly a separate switch] trusted LAN subnet
  7. Local client devices connect to trusted LAN subnet.
[Unless the SRM router is also acting as the router from the LAN to dirty subnet (and out) then there must be another router in here somewhere, unless the clients don't have direct Internet access.]

I'd assume your DSM DNS Server's external view is providing WAN side resolution, meaning routable IP addresses back to you from WAN side clients. Why would VPN clients that are on the trusted side of your setup want to use the external view? They should be accessing the DNS server via the trusted LAN and get internal view resolution.

In the DNS Server Views have you limited which IPs can access each view? Does this include the VPN client subnets (and the VPN server IP too)?

As for DSM firewall, you need to enable access to UDP 53 for those client subnets. Generally you would block TCP 53 from external access.



To answer one of you questions about DNS in SRM...

You have to consider the SRM router as a number of things:
  1. A server/device on the network: it needs to know what DNS servers it should use (e.g. to check for s/w updates) ... set these in NC -> Internet -> Manually Configure DNS Server
  2. A DHCP server for clients: it needs to know what DNS servers the DHCP client should use ... set these in NC -> Local Network -> General. If you want to use or add the SRM's own DNS server setting to this list then enable 'Forward known DNS server'.
  3. A DNS server (if installed): this is independent of any other and if Safe Access isn't running will be used to resolve DNS requests set to the SRM LAN IP.
  4. The Safe Access service: intercepts DNS resolution requests to the SRM router IP*. It then uses SRM's own DNS server setting to resolve onwards (not the SRM DNS Server).
*When configuring the SRM firewall you get destination options of All/SRM/IP/Region. Here the 'SRM' option is special in that the IP address is not the router's LAN IP, or the WAN IP, or whatever. What it is it the one instance that SRM firewall has of a group of IPs (I was there was a way to define my own IP groups, sheesh). So here 'SRM' group means the current IP address for interfaces:
  • LAN
  • WAN
  • Guest LAN
  • OpenVPN server
  • L2TP VPN server
  • etc etc for other VPN services
 
Again thanks fredbert.

Network Center -> Internet -> Connection
Preferred DNS server: 192.168.x.B (IP of DSM NAS)​
Alternative DNS server: 1.1.1.1​

Network Center -> Local Network -> General
Local IP / IP Address: 192.168.x.A​

DHCP Server:
Gateway: 192.168.x.A​
Primary DNS: 192.168.x.A​
Secondary DNS: 192.168.x.B​
Forward known DNS server: Disabled (stops access to SRM's primary/alternative DNS, if they happen to be direct to Internet without filtering etc.)​

SRM DNS Server:
Forward and reverse slave zones from 192.168.x.B​

So you point your dhcp clients to your slave DNS as 1st resolver? Do the dhcp clients not update the DNS with themselves? [Side issue, either way.]

Yes, correct. Sorry I should've been clearer.

Between the two servers the only differences are: the SSL certificate that is server generated; the TCP/UDP statement in the VPN [Plus] Server GUI and also the .ovpn file, again server generated; the subnet used for the clients.

In the .ovpn files I just checked my current edits and see they are less than I used to add:
Changed the 'remote' command to be to my FQDN and port number​
One 'dhcp-option' command for DOMAIN, so that I can be lazy and access devices by name 'nas' etc.​
Is 'float' normally enabled? Anyway mine is commented out, so disabled.​
The clients' DNS server is set in the VPN [Plus] Server GUI and is 192.168.x.A

Since attempted with no success.

I've finally read your initial post. So what I think you're doing, logically, is:
  1. Untrusted networks.

  2. [possibly a separate switch] 'dirty' side DMZ (in network-type's terminology, I'd not say DMZ if it was the default path through to the trusted LAN ... but that's just personal preference), aka external/untrusted subnet

Fair comment. It is "untrusted" as opposed to genuine DMZ. (Never sure how far to go on public forum.)
And pretty astute reckoning for the rest of it as well.

Why would VPN clients that are on the trusted side of your setup want to use the external view? They should be accessing the DNS server via the trusted LAN and get internal view resolution.

Correct. VPN clients do _not_ need access to the external views. It is access to the internal views I am attempting to achieve. Declaration/Explanation of the external views was more about transparency in requesting assistance than anything else.

Basically, I'm simply attempting to achieve normal LAN operations/visibility over a vpn connection. i.e. the same as you; addressing hosts via hostname only v's fqdn, and disovery with bonjour/afp, etc.

In the DNS Server Views have you limited which IPs can access each view? Does this include the VPN client subnets (and the VPN server IP too)?

As for DSM firewall, you need to enable access to UDP 53 for those client subnets. Generally you would block TCP 53 from external access.

Both 'Resolution' access as a whole and Internal View access had been given to both 192.168.x.x and OpenVPN's 172.22.0.x as complete /24 subnets. Have since added what I assume to be be VPN Server's IP of SRM WAN Manual IP.

DSM firewall obviously offers no capacity to distinguish between UDP/TCP in the manner in which SRM firewall does.

All so far, to no avail. I haven't yet made up my mind whether it's a routing or firewall issue.

SRM's routing table "seems" to be ok from my understanding.

Kernel IP routing table
DestinationGatewayGenmaskFlagsMSSWindowirttIface
0.0.0.010.xx.xx.M0.0.0.0UG000eth0
10.xx.xx.00.0.0.0255.255.255.0U000eth0
10.xx.xx.M0.0.0.0255.255.255.255UH000eth0
172.21.0.00.0.0.0255.255.255.0U000vbr3
172.22.0.0172.22.0.2255.255.255.0UG000tun0
172.22.0.20.0.0.0255.255.255.255UH000tun0
192.168.xx.00.0.0.0255.255.255.0U000lbr0
192.168.yy.00.0.0.0255.255.255.0U000gbr0


What I need/want to understand better is the vpn client's routing table and the significance of each 172.22. IP. OpenVPN/Viscosity seems to give the client a 172.22.0.6 IP. But then the route tbl mentions a 172.22.0.5 and a 172.22.0.1 and they seem to be in some form of loop. Will need to read a bit more on that 1st.

Next step is setup an Accept ALL firewall rule(s) and see what happens.
 
Using Mac's Terminal app can you traceroute to the NAS when connected as a VPN client? As it does sound like either a routing issue or DNS server configuration is blocking. Or one of the FWs!

Have you tested with Tunnelblick?


One point on DSM/SRM firewall rules: if you select the “port” using an application then it will include whichever ports and protocols Synology has included. You can create a custom rule that can limit the protocol and port. This is how I did the SRM port forward rule so that OpenVPN UDP goes to the NAS but OpenVPN TCP stays with the router (and similar FW rules). Likewise DSM FW can do the same but select 'custom'.
 
Using Mac's Terminal app can you traceroute to the NAS when connected as a VPN client? As it does sound like either a routing issue or DNS server configuration is blocking. Or one of the FWs!

Have you tested with Tunnelblick?

Apologies for the break in transmission. Other "Life" issues intervened.

I am now of the opinion that neither routing, nor firewall - and unless I'm missing something fundamental - nor DNS access config is the issue. And thus I am at somewhat of a loss. Let me explain.

I have now carried out the following testing with both all security restrictions removed (Firewalls & DNS Source Query Resolution IP Limiting disabled) and with all security restrictions remaining in place (i.e. Firewalls & DNS Source Query Resolution IP Limiting ENABLED)
  1. With the firewall disabled or the appropriate ICMP / UDP+Port combination rules implemented, 'traceroute' to both DSM and SRM LAN IP's is successful.
  2. I am able to connect, in the Browser - via IP - to both the DSM and SRM GUI's.
  3. I am even able to connect via AFP - again via IP - to the DSM Shares.
  4. I can ssh - again via IP - into both devices via LAN-side IP's.
  5. And finally, I can even make a successful 'telnet' connection to port 53 on both DSM _and_ SRM LAN-side.
And yet STILL the cmd 'dscacheutil -q host -a name <fqdn or just hostname>' returns with no result.
Not just a list of the record with no IP in the manner in which 'dig' or 'nslookup' might; but NOTHING.

Poodle:~ me$ dscacheutil -q host -a name <fqdn_or_hostname> Poodle:~ me$

In fact, if I attempt a resolution with either 'dig' or 'nslookup', both tell me they are indeed querying my DSM DNS server, but are still not resolving the hostname. What the hell is with that?

I have changed the VPN protocol to TCP - thinking maybe the fact I am Port-fwding from internet Router to VPN Server and then attempting further UDP DNS resolution on internal LAN might be interfering. No luck there either.

I have since installed and connected with Tunnelblick and in spite of the Tunnelblick logs showing that DNS, WINS, search domain, etc. all succeeded; a 'dscacheutil ' call's results are the same.


I admit I'm stuck.







P.S. Just as an aside @fredbert ; You mentioned earlier you had issues keeping a connection longer than a minute in one of your configs and that you weren't using compression. I noted when I disabled compression on the link, that I too couldn't keep a connection much longer than a minute.
 
Is there something that's acting as a DNS proxy? If connections to other DSM services work and you can confirm you are connecting to the NAS then that would lead to something between the NAS and client.

More questions/thoughts:
  • Try using tcpdump via SSH on the NAS and monitor UDP 53 connections to the VPN client.
sudo tcpdump -i ovs_eth0 | grep -v [my monitoring device's IP]
If you can monitor via a different interface then you don't have to pipe ['|'] the output to 'grep out' the traffic your SSH session is generating :)
My NAS has only one interface 'ovs_eth0', use ifconfig to find the interface name you want to monitor.​
  • Have you tried running DNS Server on the SRM router as a slave of Internal View? And having VPN clients using that instead of directly using DSM's DNS Server?
  • It does sound very weird, such that I'd be at the point of stop/start DNS Server and off/on the NAS: flushing out whatever has been accrued.
  • Have you also tried flushing the Mac's DNS cache? How to Clear DNS Cache on Mac

P.S. Just as an aside @fredbert ; You mentioned earlier you had issues keeping a connection longer than a minute in one of your configs and that you weren't using compression. I noted when I disabled compression on the link, that I too couldn't keep a connection much longer than a minute.
The reason I opted to disable compression stems from the iOS app's Setting header "Allow Compression (insecure)". I looked up about this and decided that for my limited use any bandwidth saving will be acceptable, and also may media formats already employ compression so there would be little benefit too [try zipping a jpeg file]. But a good catch for a fixed if you don't have OpenVPN on DSM.
 
  • Try using tcpdump via SSH on the NAS and monitor UDP 53 connections to the VPN client.
sudo tcpdump -i ovs_eth0 | grep -v [my monitoring device's IP]
If you can monitor via a different interface then you don't have to pipe ['|'] the output to 'grep out' the traffic your SSH session is generating :)
My NAS has only one interface 'ovs_eth0', use ifconfig to find the interface name you want to monitor.​

Sorry, not sure I follow you here. I should run that from DSM terminal? And [my monitoring device's IP] would be the 172.22.0.x addr of the VPN client?

Have you tried running DNS Server on the SRM router as a slave of Internal View? And having VPN clients using that instead of directly using DSM's DNS Server?​

SRM DNS Svr is an exact replica Internal & External Views incl.d Slave of the DSM DNS Master
 
tcpdump will dump out all the activity on the selected interface. If that interface is the same as you're connecting for SSH then you'll get loads of junk regarding the SSH session. It would be best to use a different device to run the SSH session and then grep out its IP address to remove that traffic. Then monitor for requests coming from the VPN client device and/or SRM's VPN/DNS Server.

The objective is to see if requests are coming to the NAS for DNS requests, or if there's a block at the router.

If the SRM DNS Server is an exact replica including the views then I think you said the VPN subnet is on the Internet View. For the moment can you remove the views and have only Internal IP resolution? Could it be this that's the issue? Would you need views on the SRM DNS server if it resolves only for internal devices?
 
Ok,
soooooo, if the NAS has both 'ovs_eth0' (LAN1) and 'ovs_eth1' (LAN2) where LAN2 is the internal 192.168.x.x subnet; what you're suggesting is if I can ssh in via LAN1, I can then just run;

sudo tcpdump -i ovs_eth1 which I can then filter out looking for calls to 53.

Is this correct?


.... Again, not sure I follow here.
VPN subnet is 172.22.0.x/24 ; VPN clients connect to VPN Server offered up on SRM WAN IP in the 10.x.x.x/24 subnet and I am looking for them to connect into the 192.168.x.x/24 internal subnet.

Sorry for being daft.
 
Is this correct?
Yes, exactly.

It's getting hard to follow :) Basically what I'm trying to suggest is to follow each point of the communication and consider what should happen here and what could happen. Then test as best you can and confirm 'it gets here' does it get to the next point.

When debugging a network problem I find it very useful to envisage myself at one point and consider what I can 'see' when 'looking' at other devices and devices behind them. It helps when addressing NAT'ed IPs and routing and 'what should it look like to me'.
 
Last edited:
Oh FFS!

You remember how I said;

unless I'm missing something fundamental ....

and followed that up with;

I have now carried out the following testing with both all security restrictions removed (Firewalls & DNS Source Query Resolution IP Limiting disabled)....


....... errrrrrrrrrrrrmmmmm ..... Seems I sorta, kinda ............. hadn't.

I got the first two...

Screen Shot 2020-05-31 at 15.33.07.png
Screen Shot 2020-05-31 at 15.33.24.png


but, .... I had forgotten about Zone Settings

Screen Shot 2020-05-31 at 15.34.11.png


So, it works.

How I figured it out was, I started playing around with dig and nslookup instead of continuing to use the OSX default of dscacheutil.

And eventually, it was nslookup which returned with a "server can't find <hostname>: REFUSED". That made it clear that despite the result stating it was querying the DNS I was pointing at, it was actually forwarding the query on to its Forwarder. Which obviously had to be an access issue. A little hunting later and a major DOH! ensued.

Thanks @fredbert for being the sounding board.
 
So, a couple of learnings from this;
  1. I didn't do any benchmarking, so only seat-o-the-pants feel but, IMHO Viscosity feels like it provides a faster tunnel (i.e. transfer once connected). As in a fair bit faster.
  2. That said, Tunnelblick's logging - in terms of debugging - is FAR superior.
  3. 'dscacheutil' as a resolution mechanism might be ok. But in terms of debugging to figure out what's wrong it absolutely sucks! Both 'dig' and/or 'nslookup' are far more informative in terms of debugging.
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Popular tags from this forum

Similar threads

Hi Fredbert, I followed your "lazy" tip and it works fine. Thanks :)
Replies
8
Views
988
Anyone have VPN split tunneling and have functionality as described below, using an android VPN app...
Replies
0
Views
794
  • Question Question
Everything else that I have asked you. This could be a cap at work. Maybe network team is controlling...
Replies
4
Views
2,150

Thread Tags

Tags Tags
dns vpn

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Trending content in this forum

Back
Top