Resolving LAN hostnames when connected to VPN
Comments
-
Hi @deaftolight,
Host name resolving is based on NetBIOS protocol, It is unable to cross different subnet.
Please tick “Enable NetBIOS broadcast over IPSec” on phase 2You also can assign wins server IP for client to resolve host name (if you have wins server)0 -
Hi,Thank you for your response. I have "Enable NetBIOS broadcast over IPSec" checked. I don't have a WINS server set up because everywhere I've read, it says that WINS is obsolete and shouldn't even be used anymore, and DNS handles all of this now.Also, I went into DNS settings of the router and changed added an entry for my local DC as my DNS server and moved it to priority #1. The second (8.8.8.8) is Google's and the third (12.127.17.72) is my ISP's, which originally was the only one there.
0 -
Hi @deaftolight,
Can you capture packets on ZyWall VPN client and Lan host when you ping the target Host by hostname.
With packets trace on both side, it would be helpful to troubleshoot name resolving issue.
e.g.
Assume you connected to VPN, and ping a Lan side host named “VIC-S101H”.
You should be able to see the name query packets sending from VPN client.After host VIC-S101H receive the name query packets, it respond the name query with its IP.0 -
I can check this for you... what are you using to log that so I can sen dthe information?
0 -
I ended up getting the pings to work, I realized even though I put my DNS server in the VPN client, I didn't see the box for the FQDN. Once I entered the FQDN in the VPN client, i could ping everything by hostname. Unfortunately though, I can't see other computers on the network like I could if I was at a workstation at the office. Network discovery is turned on, but it only shows one computer: itself. Does anyone know how to get network discovery to work so I can access other computer's share folders easier?
0 -
Hi @deaftolight,
As far as I know, windows network discovery does not work across subnets, but you still can access network share by UNC.
e.g.
\\x.x.x.x\folder_name
\\Hostname\folder_name
0 -
I see... and you can't put the VPN client on the same subnet, right?The \\Hostname is a workaround, I just wish there was a way to see the network of hostnames, as we have many hosts, so is there any way to see all the host names on a network over VPN?0
-
would this scan out the host names?
0 -
Hi deaftolight, we have this working quite satisfactorily in several sites where both L2TP IPSEC VPN (client-to-site) and VTI (site-to-site) tunnels also either ends to get to all hosts using a local DNS hostname lookup.
Forget the need for ye old school and frankly irrelevant proprietary NETBIOS and WINS server nonsense. We use L2TP with MacOS L2TP IPSEC clients , FreeBSD and Windows 7/8/10 clients... no need for that so disable both in your:- Configuration / VPN/ IPSEC VPN, VPN Connection / WIZ_L2TP_VPN (disable NETBIOS broadcast over IPSEC) and
- Configuration / VPN/ IPSEC VPN, L2TP VPN (disable WINS SERVER)
This is straightforward and works well.
As mentioned in this thread and to my quite limited knowledge , BONJOUR discovery (aka multicast DNS (mDNS) RFC-6762/6763 ??) is implemented NOT to work across subnets on a VPN. Thus from your L2TP VPN client you will always need to specify a FQ local host name <that-host-01.deaftolight.office> instead of something like that-host-01.local- afp://deaftolight:pwd@that-host-01.deaftolight.office/network_filesystem-01
- smb://deaftolight:pwd@that-host-01.deaftolight.office/network_filesystem-02 or
- in Windows OS parlance in it's Finder / File Manager or whatever it is this week... as \\that-host-01.deaftolight.office/network_filesystem-03
Note also that it is typical the the local domain name.suffix is NOT supplied on assignment if the L2TP IP address by a typical business router. [O.T.O.TH, an L2TP request from say .. a Client connecting to a software VPND in MacOS server WILL give you this domain.suffix)........
BTW some mDNS services can be coerced via a DNS-SD and local ssh port redirection .... ssh -g -L <redirected-port-number>:localhost:<port_at_remote> someone@remote-host@other.place and the announcing the mDNS service onto current computer.. tricky however it does work..
The point is.. ALWAYS deploy a user practice of specifying the fully qualified host name of the host ... (i.e. that-host-01.deaftolight.office ) .. else have yoru clients manually add it in your OS NIC settings for the PPP VPN ... from memory it can be added to the Windows OS VPN connection network definition in the "Network Settings".....
....however it doesn't seem to work over to drive a host's domain suffix.... maybe a windows OS scientist could assist here...
From your posts , me thinks your ROUTE POLICY and maybe some attention your Secuity Policies as well .
Some ideas and knowns to start with... :- your L2TP subnet is at RFC1918.3 192.168.99.10/24.. 100 ... looks ok
- your local DNS server is at IPV4 192.168.1.10 .. one may assume it's addressable from the 192.168.1/ 24 LAN (telnet 192.168.10 53 ...... )
- disable the NETBIOS and WINS Server junk....
- remove the DNS server at 192.168.99.10 from record #1 Configuration/ System /DNS / Domain Zone Forwarder..... no need for this.
- your L2TP VPN Connection is named: "WIZ_L2TP_VPN"
1. Configuration / Network / Routes in order 1 to n
route 01 - "Provide route to and from other L2TP clients " .. { if you allow that }.. ARD/VNC?
Description: provide route to other L2TP clients ...Incoming: TunnelMember: WIZ_L2TP_VPNSource Address: WIZ_L2TP_VPN_IP_ADDRESSDestination: WIZ_L2TP_VPN_IP_ADDRESSNext Hop: Type = VPN TUNNEL .... VPN Tunnel: WIZ_L2TP_VPNDefault the rest
and thenroute 02 "Allow route to Any host connection to any L2TP client from say LAN1 etc ...". {as above is you allow it. Useful for access from another IPSEC VTI tunnel as well}
Description: Allow route to Any host connection to any L2TP client from say LAN1 etc .Incoming: Any (Excluding ZyWall)Member: WIZ_L2TP_VPNSource Address: any (or LAN1)Destination: WIZ_L2TP_VPN_IP_ADDRESSNext Hop: Type = VPN TUNNEL .... VPN Tunnel: WIZ_L2TP_VPNDefault the rest2. Configuration / Security Policy Policy Control { in order 1 to n }
Assuming you already have these or some of them...
Name: 01_L2TP-UDP_from_TUNNEL_USGDescription: L2TP 1701 comes from the TUNNEL NOT the the WAN!From: TUNNELTo: ZYWALL Source: anyDestination: WIZ_L2TP_VPN_IP_ADDRESSService: L2TP-UDPAction: AllowDefault the restName: 02_IPSec_VPN_to_DeviceDescription: IPSec_VPN to Zywall allow its administration (assuming you let this happen)From: IPSEC_VPNTo: ZYWALLSource: anyDestination: anyService: anyAction: Allowdefault the restName: 03_L2TP_TUNNEL_to_USG_via_WAN_from_TUNNELDescription: IPSec_VPN L2TP_TUNNEL_Device_via_WAN {optional for you}From: IPSEC_VPNTo: ZYWALLSource: WIZ_L2TP_VPN_IP_ADDRESSDestination: WIZ_L2TP_VPN_IP_ADDRESSService: anyAction: Allowdefault the rest<div></div>
Name: 04_ANY__L2TP_LAN_SUBNET_ANYDescription: allow LAN_SUBNET ANY_to_other networks ( local or upstream )From: any (Excluding Zywall)To: any (Excluding ZyWALL)Source: WIZ_L2TP_VPN_IP_ADDRESSDestination: anyService: <your_service_group_for_ESP_IKE_NATT>Action: Allowdefault the restName: 05_WAN_to_DEVICE_any_to_1701_L2TPDescription: allow L2TP as a separate rule through USGFrom: WANTo: ZYWALLSource: WAN_ANY_IPDestination: anyService: <your_service_group_for_ESP_IKE_NATT>Action: allowdefault the rest3. Configuration / VPN / L2TP VPN
some suggestions.... however the DNS settings are crucial for the L2TP user. If you are using the ZYXEL itself, then maybe you dont need the ISP WANx DNS server .. test to your taste...
General SettingsEnable L2TP Over IPSec = on (ticked)VPN Connection: WIZ_L2TP_VPNIP address Pool: WIZ_L2TP_VPN_ADDRESSAuthentication Method: Default (local ) … (consider using LDAP or something for business stuff..Advance(d) (another Chinglish from the Taipei Zyxel Lads)…Allow User: anyKeep Alive: 60 (or something less)First DNS server (Optional): Custom Defined 192.169.91.10 (crucial!!)Second DNS server (Optional) From ISP wan1 1st DNS Serverdefault the restVerification: from your L2TP client after successfully connecting the Tunnel (split or full)
Use nslookup or host or dig to lookup a named host with an AAA record in your local DNS at 192.168.1.10.
I've used windows inbuilt VPN Client here to demonstrate this.. its connected to a remote site over windows L2TP inbuilt client t a VPN gateway on a Zyxel USG appliance.
Here's an example where the L2TP windows client whose IPV4 address is provided by the Zyxel L2TP connect as 10.0.169.2 (L2TP subnet 10.0.169.0/24 a figment subnet from the main LAN at connected site) is using DNS server is at 10.0.69.1 on a Zyxel USG appliance as above .
The client may access the local lan on 10.0.69.0/24 and also go upstream via the WAN. The default is a full tunnel VPN ... work great!
Here's is an example of the Windows L2TP PPP NIC (errr.. windows "adapter"..) .. Notice the DNS suffix? It was configured in the WINDOWS L2TP PPP Nic..
Heres an example of the DNS name resolution from the VPN client to the DNS server in the Zyxel router (or else where) t resolve the host by name at IPV4 10.0.69.201 using inbuilt nslookup...
Lastly here is a ICMP ping from L2TP subnet 10.0.169.0/24 to the host on LAN 10.0.69.0/24 using the DNS resolved HOST name from the DNS server at 10.0.69.1.
This all works the same with any network connection using a Full Qualified host name that is resolved from the name server whilst connected to the IPSEC L2TP VPN at the remote site.
Lastly connection using Windows OS parlance/syntax with "\\" url in the Windows OS File Manager/Finder works great from the VPN Client... as follows ,, example....
\\that-host-01.deaftolight.office/network_filesystem-03
Epilogue: This doesn't take too much to do.
If you run into difficulty, turn on zyxel USG logging and look for the usual events.
These USG's are at V4.3.x Firmware (2018-June)
Oh and one more thing... I'm reliably informed that some Windows 10 home edition ( .. non WIN 10 pro ??) ) wont resolve the DNS over its inbuilt VPN client over L2TP....
HTH
Warwick
Hong Kong1 -
Hi DeaftoLight et all, regarding DNS query to a from a host on LAN from REMOTE USG connected to VTI main office USG DNS, here's just an addendum to my post of ages ago that was omitted.
This came up recently and this worth adding.
Thus here's a followup.
Scenario:
Domain: ourworkshop.lab
Head Office USG (VTI: 10.10.10.10 / LAN 10.0.99.1):
Company HOST DNS is in USG router at 10.0.99.1 ..... many many records eg:
- fileserver01.ourworkshop.lab 10.0.99.161
- internalmail.ourworkshop.lab 10.0.99.203
- etc, etc
- this contains ALL the host names A records used in the organisation.
- VTI1 End: 10.10.10.10
- (LAN1 10.0.99.1) etc etc
Remote Office USG (VTO: 10.10.10.20 / LAN 10.0.80.1)
- VTI1 End: 10.10.10.20
- modest DNS settings only for this router at 10.0.80.1
- (LAN1 10.0.80.1) etc etc
The data route is over VTI1 works great!: mbar~ macseefoo$ traceroute fileserver01.ourworkshop.lab traceroute to fileserver01.ourworkshop.lab (10.0.99.161), 64 hops max, 52 byte packets 1 myrouter (10.0.80.1) 2.208 ms 2.956 ms 2.594 ms 2 * * * 3 * * * 4 10.0.99.161 (10.0.99.161) 40.138 ms 16.368 ms 16.945 ms mbair-02:~ macseefoo$
Goal:
To resolve all DNS queries from Remote Office LANs and L2TP subnets for *.ourworkshop.lab via the VTi1 from the USG DNS at Head Office USG (10.0.99.1)
Instinctively one might utilise Remote Office USG/ System/ DNS / Domain Forwarder and ADD a new private DNS forwarder for ourworkshop.lab as:
Domain Zone: ourworkshop.lab Private DNS Server: 10.0.99.1
Test01: (this fails) query hostname to DNS at Head Office USG from a host at Remote Office USF over VTI1
DNS Query from host 10.0.80.9 on LAN1 at Remote Office
host -a fileserver01.ourworkshop.lab or via nslookup fileserver01.ourworkshop.lab
$ host -a fileserver01.ourworkshop.lab Trying "fileserver01.ourworkshop.lab" Received 127 bytes from 10.0.80.1#53 in 66 ms Trying "fileserver01.ourworkshop.lab" Host fileserver01.ourworkshop.lab not found: 3(NXDOMAIN) Received 144 bytes from 10.0.80.1#53 in 74 ms
Result: = no result:
connection timed out; no servers could be reached
etc etc
Investigation:
packet captures for VTI1 on Head Office USG (VTI1) and Remote Office USG (VTI1 and LAN1) reveal (wireshark)
- Query goes out over VT1 to remote at 10.10.10.10 / 10.0.99.1 and gets sent back, then gets lost spme how.
- ssh and HTTPS from Remote Office USG (LAN(1,2) and L2TP subnet always work to Head Office USG over TCP due to SNAT Policy Router..
- however DNS UDP queries get lost...
- Policy Routes snat or other wise for Service=DNS have no effect.
However Router to Router using inbuilt USG's Diagnostics Network Tool NSLOOKUP resolves:
Remote Office USG (10.10.10.20/10.0.80.1)
nslookup fileserver01.ourworkshop.lab 10.10.10.10 resolves:
# host -a fileserver01.ourworkshop.lab 10.10.10.10 Trying "fileserver01.ourworkshop.lab" Using domain server: Name: 10.10.10.10 Address: 10.10.10.10#53 Aliases: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51841 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;fileserver01.ourworkshop.lab. IN ANY ;; ANSWER SECTION: fileserver01.ourworkshop.lab. 43200 IN A 10.0.99.161 ;; AUTHORITY SECTION: ourworkshop.lab. 43200 IN NS ns.ourworkshop.lab. Received 78 bytes from 10.10.10.10#53 in 10 ms
Solution:
The specification for Domain Forwarder record is incorrect using a Private DNS Server 10.0.99.1
Instead , use a Domain Forwarder record as a Public DNS Server and use the VTI1 end 10.10.10.10 as the DNS server address.
Add Domain Forwarder record.....
Domain Zone: ourworkshop.lab Public DNS Server: 10.10.10.10 Query via : Auto
Result = success
mbair-02:~ macseefoo$ host -a fileserver01.ourworkshop.lab Trying "fileserver01.ourworkshop.lab" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60839 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;fileserver01.ourworkshop.lab. IN ANY ;; ANSWER SECTION: fileserver01.ourworkshop.lab. 42274 IN A 110.0.99.161 Received 61 bytes from 10.0.80.1#53 in 8 ms mbair-02:~ macseefoo$
Conclusion:
Deploy USG router to centralise DNS support for remote USG's over VTI tunnels.
use Domain Forwarder record with Public DNS server and VTI address for the VPN Connection on main USG.
Works Great!
HTH
WarwickT
Hong Kong
0
Categories
- All Categories
- 415 Beta Program
- 2.4K Nebula
- 149 Nebula Ideas
- 96 Nebula Status and Incidents
- 5.7K Security
- 263 USG FLEX H Series
- 271 Security Ideas
- 1.4K Switch
- 74 Switch Ideas
- 1.1K Wireless
- 40 Wireless Ideas
- 6.4K Consumer Product
- 249 Service & License
- 387 News and Release
- 84 Security Advisories
- 29 Education Center
- 10 [Campaign] Zyxel Network Detective
- 3.5K FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 85 About Community
- 73 Security Highlight