OpenVPN can access router, but not local shares on lan, what am I doing wrong?

[Chuckles67]

As mentioned above, it doesn't work because shares are not announced across different subnets "by-design".
Thus it is simply not possible to achieve that without additional software (e.g. an avahi-server running on a server on the remote subnet).

Interested in avahi: I found an avahi daemon running on my Merlin flashed router.

admin@RT-AC66U_B1-8300:/tmp/home/root# ps w | grep avahi
808 nobody    1544 S    avahi-daemon: running [RT-AC66U_B1-8300.local]
32207 admin     4660 D    grep avahi
admin@RT-AC66U_B1-8300:/tmp/home/root#

Is this what you meant by an avahi-server? Any links/suggestions to read more?

 

[xtv]

Interested in avahi: I found an avahi daemon running on my Merlin flashed router.

admin@RT-AC66U_B1-8300:/tmp/home/root# ps w | grep avahi
808 nobody    1544 S    avahi-daemon: running [RT-AC66U_B1-8300.local]
32207 admin     4660 D    grep avahi
admin@RT-AC66U_B1-8300:/tmp/home/root#

Is this what you meant by an avahi-server? Any links/suggestions to read more?

Yes, that's the one.
However there are a couple of considerations:

• that implementation I think is used only to announce the presence of the router on the local network (probably linked to autodiscover features on the control Apps)
• I'm not sure whether if the configuration of that service is accessible, nor if it's safe to change it (without breaking integration with Apps)
• last but not least (assuming that is safely user configurable), you can use it only on the local network to announce locally the existence of a remote server (so that local device can easily connect to it), you cannot use it to announce local services to a remote client. If you want to announce a local server to clients on a remote network the avahi-server needs to be in the remote network. Remember that the announcement will not cross the border of the subnet in which it has been generated.

Anyway, for example, in order to announce a MacOS share (AFP) via avahi-server, you can just add a simple XML file to the configuration.
Typically the avahi configuration on a linux server is located in the directory "/etc/avahi/" (which is not present in a stock AsusMerlin - at least not in mine - from here my doubts listed above - if you have a Raspberry Pi serving the network, that would probably be the best device to host the avahi-server).
From here you can add each server by adding a file (one for each server) with a name ending in ".service" (e.g. my-server_afp.service) with a content similar to:

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name replace-wildcards="yes">My Apple Share</name>
  <service>
    <type>_afpovertcp._tcp</type>
    <host-name>192.168.0.100</host-name>
    <port>548</port>
  </service>
  <service>
    <type>_device-info._tcp</type>
    <port>0</port>
    <txt-record>model=Xserve</txt-record>
  </service>
</service-group>

Obviously you need to change the service-group "name" and the service "host-name", while the "txt-record" indicates what icon will be used in finder.

If you want to publish a samba share you can use something like:

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
   <name>My Samba Share</name>
   <service>
    <type>_smb._tcp</type>
    <host-name>192.168.0.100</host-name>
    <port>445</port>
  </service>
  <service>
    <type>_device-info._tcp</type>
    <port>0</port>
    <txt-record>model=RackMac</txt-record>
  </service>
</service-group>

Actually you can do many more things with Avahi (such as various dynamic integrations with other tools), but this should be what you need to see the shares.

Of course this is has nothing to do with authentication, which will be carried on by the server hosting the share itself.

One small but important note: while it's probably possible to trick Avahi to announce local servers on remote networks such as OpenVPN clients I absolutely would not recommend it, since in the unlucky event that the VPN access will be compromised, an attacker would instantly gain significant information regarding the topology and the services of your home network (aka: what to hack from here). Besides polluting other networks - including internet - with local server announcements, security is a strong point to enforce the do not forward across subnets broadcast packets rule.
Before you ask: yes an attacker able gained access to a VPN may have many other means to discover what is in the local network, but we giving him for free a way to gather knowledge without leaving traces...
Here is the reason why the avahi should be on the remote network: it will announce only stuff known to the remote network (and hopefully local services not strictly needed on the remote network are blocked by a firewall ).

 

[Chuckles67]

Yes, that's the one.
However there are a couple of considerations:

• that implementation I think is used only to announce the presence of the router on the local network (probably linked to autodiscover features on the control Apps)
• I'm not sure whether if the configuration of that service is accessible, nor if it's safe to change it (without breaking integration with Apps)
• last but not least (assuming that is safely user configurable), you can use it only on the local network to announce locally the existence of a remote server (so that local device can easily connect to it), you cannot use it to announce local services to a remote client. If you want to announce a local server to clients on a remote network the avahi-server needs to be in the remote network. Remember that the announcement will not cross the border of the subnet in which it has been generated.

Anyway, for example, in order to announce a MacOS share (AFP) via avahi-server, you can just add a simple XML file to the configuration.
Typically the avahi configuration on a linux server is located in the directory "/etc/avahi/" (which is not present in a stock AsusMerlin - at least not in mine - from here my doubts listed above - if you have a Raspberry Pi serving the network, that would probably be the best device to host the avahi-server).
From here you can add each server by adding a file (one for each server) with a name ending in ".service" (e.g. my-server_afp.service) with a content similar to:

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name replace-wildcards="yes">My Apple Share</name>
  <service>
    <type>_afpovertcp._tcp</type>
    <host-name>192.168.0.100</host-name>
    <port>548</port>
  </service>
  <service>
    <type>_device-info._tcp</type>
    <port>0</port>
    <txt-record>model=Xserve</txt-record>
  </service>
</service-group>

Obviously you need to change the service-group "name" and the service "host-name", while the "txt-record" indicates what icon will be used in finder.

If you want to publish a samba share you can use something like:

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
   <name>My Samba Share</name>
   <service>
    <type>_smb._tcp</type>
    <host-name>192.168.0.100</host-name>
    <port>445</port>
  </service>
  <service>
    <type>_device-info._tcp</type>
    <port>0</port>
    <txt-record>model=RackMac</txt-record>
  </service>
</service-group>

Actually you can do many more things with Avahi (such as various dynamic integrations with other tools), but this should be what you need to see the shares.

Of course this is has nothing to do with authentication, which will be carried on by the server hosting the share itself.

One small but important note: while it's probably possible to trick Avahi to announce local servers on remote networks such as OpenVPN clients I absolutely would not recommend it, since in the unlucky event that the VPN access will be compromised, an attacker would instantly gain significant information regarding the topology and the services of your home network (aka: what to hack from here). Besides polluting other networks - including internet - with local server announcements, security is a strong point to enforce the do not forward across subnets broadcast packets rule.
Before you ask: yes an attacker able gained access to a VPN may have many other means to discover what is in the local network, but we giving him for free a way to gather knowledge without leaving traces...
Here is the reason why the avahi should be on the remote network: it will announce only stuff known to the remote network (and hopefully local services not strictly needed on the remote network are blocked by a firewall ).

Fantastic answer - thank you.

I tried a few things, and find Merlin's stock avahi daemon does not function as hoped :
- I tried setting up a service for a networked printer on a subnet, this printer IP is "ping-able" from the remote router ssh command line and from a remotely connected computer. Along with your reply, I used this link as a reference for the service file.
- to test I set the remote router firewall off (...!...), and enabled 515 and 5353 port forwarding in my remote router
- in the remote router I created a printer.service file in /tmp/avahi/services and restarted the daemon
- the remote router System Log shows the avahi daemon finds this service, and attempts to set up this service but fails due to "Invalid host name".

I'll look into this more on the Merlin thread in this Forum. The remote router firewall is set back on Cheers.

 

[eibgrad]

One small but important note: while it's probably possible to trick Avahi to announce local servers on remote networks such as OpenVPN clients I absolutely would not recommend it, since in the unlucky event that the VPN access will be compromised, an attacker would instantly gain significant information regarding the topology and the services of your home network (aka: what to hack from here). Besides polluting other networks - including internet - with local server announcements, security is a strong point to enforce the do not forward across subnets broadcast packets rule.
Before you ask: yes an attacker able gained access to a VPN may have many other means to discover what is in the local network, but we giving him for free a way to gather knowledge without leaving traces...
Here is the reason why the avahi should be on the remote network: it will announce only stuff known to the remote network (and hopefully local services not strictly needed on the remote network are blocked by a firewall ).

Btw, very nice write-up about Avahi and its uses. Very helpful.

Regarding its use w/ the OpenVPN client, good point. But if you think about it, using a bridged OpenVPN tunnel is even worse! As I pointed out here and other threads, should it be compromised, the attacker has the keys to the kingdom, and why a routed OpenVPN tunnel is much preferred. At least then you can restrict access to specific devices.

IOW, the argument against using Avahi w/ a routed tunnel is really an argument against bridged tunnels in general. You can think of a routed tunnel w/ Avahi as a hybrid solution. At least you're only announcing the availability of resources, w/o necessarily providing the access.

And frankly, think how many guest networks are implemented in a bridged rather than routed configuration, including ASUS/Merlin! Guests typically can still *see* the private network's resources, thus minimally revealing potential targets. And why I'm NOT a fan of bridged guest networks.

My point is, yes, your concerns are totatally legitimate, and I even agree w/ them, but you could apply that same logic across numerous situations, many of which ppl don't even give a second thought as to the implications.

 

[Chuckles67]

For the original poster, I got something similar working on two Merlin enabled routers (thanks to xtv for describing avahi)

creating a service with Merlin Avahi daemon : invalid host name (FIXED)

Asus AC-66U_B1 flashed with Merlin 386.2_2 I'm trying services (printer, Mac share, smb; all on a different subnet than the router's IP pool) with the stock Merlin Avahi daemon by creating .service files in the /tmp/avahi/services folder. After restarting the avahi daemon with service...

www.snbforums.com

Requires confidence working on the command line through ssh on the remote router, and writing and testing scripts.