Resolving LAN hostnames when connected to VPN

Bud
Bud Posts: 6
First Comment
edited April 2021 in Security
Has anyone figured out how to be able to get the internal LAN hostnames to resolve when connected to the IPSec VPN?  Running a Zyxel USG40.  I  have a domain controller on site that handles DHCP and DNS with local IP 192.168.1.10, so I tell the Zywall VPN client that is my DNS server.  But I still can't ping the computers on the network by hostname, only IP.  Oddly enough, if i do ping -a <ip address>, it will resolve the hostname, and then I can ping that computer by hostname... but only one that I have used ping -a with.  In addition, I can't see the computers on my network when I try to browse in Windows 10, which I would like to do to access shared folders.
«1

Comments

  • Zyxel_Cooldia
    Zyxel_Cooldia Posts: 1,426  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    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 2

    You also can assign wins server IP for client to resolve host name (if you have wins server)

  • Bud
    Bud Posts: 6
    First Comment
    edited June 2018
    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.



  • Zyxel_Cooldia
    Zyxel_Cooldia Posts: 1,426  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    edited June 2018
    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.

  • Bud
    Bud Posts: 6
    First Comment
    I can check this for you... what are you using to log that so I can sen dthe information?
  • Bud
    Bud Posts: 6
    First Comment
    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? 
  • Zyxel_Cooldia
    Zyxel_Cooldia Posts: 1,426  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    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
  • Bud
    Bud Posts: 6
    First Comment
    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?
  • PeterUK
    PeterUK Posts: 2,651  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer

    would this scan out the host names?

    https://www.softperfect.com/products/networkscanner/

  • warwickt
    warwickt Posts: 111  Ally Member
    First Anniversary Friend Collector First Answer First Comment
    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
    The local DNS server are either in a Zyxel USG appliance or a separate server (MacOS or FreeBSd, Centos servers for example).. as long as they are addressable and accessible by your L2TP client, which is your issue here..... 

    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... :
    1. your L2TP subnet is at RFC1918.3 192.168.99.10/24.. 100   :) ... looks ok
    2. 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 ...... )
    3. disable the NETBIOS and WINS Server junk.... 
    4. remove the DNS server at 192.168.99.10 from record #1 Configuration/ System /DNS / Domain Zone Forwarder..... no need for this. 
    5. your L2TP VPN Connection is named: "WIZ_L2TP_VPN"
    Try this config settings:

    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: Tunnel
    Member: WIZ_L2TP_VPN
    Source Address: WIZ_L2TP_VPN_IP_ADDRESS
    Destination: WIZ_L2TP_VPN_IP_ADDRESS
    Next Hop:  Type = VPN TUNNEL .... VPN Tunnel: WIZ_L2TP_VPN
    Default the rest 

    and then 

    route 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_VPN
    Source Address: any (or LAN1)
    Destination: WIZ_L2TP_VPN_IP_ADDRESS
    Next Hop:  Type = VPN TUNNEL .... VPN Tunnel: WIZ_L2TP_VPN
    Default the rest

    2. 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_USG
    Description: L2TP 1701 comes from the TUNNEL NOT the the WAN! 
    From: TUNNEL 
    To: ZYWALL Source: any 
    Destination: WIZ_L2TP_VPN_IP_ADDRESS 
    Service: L2TP-UDP 
    Action: Allow 
    Default the rest

    Name: 02_IPSec_VPN_to_Device
    Description: IPSec_VPN to Zywall allow its administration (assuming you let this happen) 
    From: IPSEC_VPN
    To: ZYWALL
    Source: any
    Destination: any
    Service: any
    Action:         Allow
    default the rest

    Name: 03_L2TP_TUNNEL_to_USG_via_WAN_from_TUNNEL
    Description: IPSec_VPN L2TP_TUNNEL_Device_via_WAN {optional for you} 
    From: IPSEC_VPN
    To: ZYWALL
    Source: WIZ_L2TP_VPN_IP_ADDRESS
    Destination: WIZ_L2TP_VPN_IP_ADDRESS
    Service: any
    Action: Allow
    default the rest 
    <div></div>
    Name: 04_ANY__L2TP_LAN_SUBNET_ANY
    Description: allow LAN_SUBNET ANY_to_other networks ( local or upstream ) 
    From: any (Excluding Zywall)
    To: any (Excluding ZyWALL)
    Source: WIZ_L2TP_VPN_IP_ADDRESS
    Destination: any
    Service: <your_service_group_for_ESP_IKE_NATT>
    Action: Allow

    default the rest 

    Name: 05_WAN_to_DEVICE_any_to_1701_L2TP
    Description: allow L2TP as a separate rule through USG 
    From: WAN
    To: ZYWALL
    Source: WAN_ANY_IP
    Destination: any
    Service: <your_service_group_for_ESP_IKE_NATT>
    Action: allow
    default the rest 

    3. 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 Settings

    Enable L2TP Over IPSec = on (ticked) 
    VPN Connection: WIZ_L2TP_VPN
    IP address Pool: WIZ_L2TP_VPN_ADDRESS
    Authentication Method: Default   (local ) … (consider using LDAP or something for business stuff.. 

    Advance(d)          (another Chinglish from the Taipei Zyxel Lads)…

    Allow User:                   any
    Keep 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 Server

    default the rest


    Verification: 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 Kong
  • warwickt
    warwickt Posts: 111  Ally Member
    First Anniversary Friend Collector First Answer First Comment

    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

Security Highlight