[SOLVED] Using OpenWrt device exclusively to Bridge VPN clients to LAN subnet

I have an existing LEDE device that handles Routing/DHCP, but I have added a new device that will function exclusively as a VPN Server (in "server_bridge" mode) so that remote clients can be assigned IP addresses within the same subnet as LAN devices.

While I could just add a VPN server to the existing device, I am using a secondary device to unburden the primary router from the VPN Server load.

I've got the VPN Server portion setup, but I can't ping any LAN devices from any VPN connected devices... So, I'm clearly doing something wrong here.

Any help is appreciated, even if it's just a link or broad strokes of the general setup I should have in place... For reference, here's my configs:

openvpn/server.conf
config openvpn 'vpnserver'
        option enabled '1'
        option dev 'tap0'
        option port '1196'
        option proto 'udp'
        option comp_lzo 'yes'
        option keepalive '10 120'
        option persist_key '1'
        option persist_tun '1'
        option ca '/etc/openvpn/ca.crt'
        option cert '/etc/openvpn/my-server.crt'
        option key '/etc/openvpn/my-server.key'
        option dh '/etc/openvpn/dh2048.pem'
        option tls_auth '/etc/openvpn/tls-auth.key 0'
        option mode 'server'
        option tls_server '1'
        option server_bridge '192.168.31.1 255.255.255.0 192.168.31.93 192.168.31.99'
        option client_to_client '1'
        option status '/tmp/openvpn_tap0.status'
        list push 'dhcp-option DNS 192.168.31.1'
        list push 'redirect-gateway def1'
        list push 'route-metric 512'
        list push 'route 0.0.0.0'
openvpn/client.conf
  dev tap
  client
  proto udp
  fast-io
  remote ddns.address.removed 1196
  remote-cert-tls server
  nobind
  persist-key
  persist-tun
  comp-lzo no
  verb 3
  key-direction 1
  route-metric 512
  route 0.0.0.0 0.0.0.0
<ca>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
</key>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----
</tls-auth>

etc/config/network
config interface 'tap0'
        option proto 'none'
        option auto '1'
        option type 'bridge'
        option ifname 'eth1 tap0'

etc/config/firewall
config zone
        option name 'vpnserver'
        option input 'ACCEPT'
        option forward 'REJECT'
        option output 'ACCEPT'
        option network 'tap0'

config forwarding
        option dest 'wan'
        option src 'vpnserver'

config forwarding
        option dest 'vpnserver'
        option src 'wan'

config rule
        option target 'ACCEPT'
        option src 'wan'
        option proto 'tcp udp'
        option dest_port '1196'
        option name 'Allow-VPN'

I don't think I changed anything else from stock...
I did add a Static Route, but that didn't seem to help

If the VPN server lies inside the LAN I don't see the point of having a WAN firewall zone.
You can disable the firewall all together, or just leave LAN zone which will have members the tap and eth1 interfaces (which are bridged anyway).

not sure if you want this....

option client_to_client '1'

The majority of the VPN users will be using QuickBooks, which has become more difficult to get to work over a VPN in the past year.

If I disable "client_to_client", wouldn't that prevent sharing between remote clients?

Will just deleting the zones get rid of the firewall? I had no idea it was that simple..

Do I need to bridge the tap interface over another, like eth0 or eth1?

I am assuming, since I don't have complete knowledge of the configuration. But it is extra complexity which might introduce such problems.
You can disable temporarily the firewall to see if it will solve the issue. service firewall stop
Then you can decide what to do with it.

With this tiny piece of the configuration you provided that would merely be guesswork.

1 Like

I'm doing something wrong here. No matter what I've tried, I can't ping the WAN IP address of the "new" device from within the VPN tunnel. Feels like I should start from scratch....

  1. Do I need to add static routing to the LAN device so that it knows it needs to go through 192.168.31.15 to reach the addresses in the 192.168.31.93-99 range?
  2. Do I need to add static routing to the VPN device so that it knows to go through 192.168.31.15 to reach 192.168.31.0/24?

I've tried adding the routing to the VPN device (#2) but would be unsure of how to add it to the LAN device (#1). Routing has always been the last thing I needed to do to get a VPN server to place nice with a network... I've never setup a VPN server with bridging, so not having an IP address for the VPN server itself makes all the other working examples of routing I have useless.

I deleted all of the firewall zones and ended the service. I deleted the WAN6 interface because I don't think I'll need it (I don't think OpenVPN uses ipv6). I've left the LAN interface so that I can connect directly in the event of a bad configuration preventing access through the WAN port.

What other pieces of the config would help you determine what I might be doing wrong? Thank you for your replies and help so far!

You don't need static routes. If configured properly they are part of the same network.
For a start post the whole output of the following:
cat /etc/config/network; cat /etc/config/firewall; cat /etc/config/dhcp ; ip -4 addr ; ip -4 ro ; ip -4 ru

Also something similar to ip -4 addr ; ip -4 ro from the client when connected.

I haven't trashed the current configuration yet...

server
config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd81:ed64:447c::/48'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.32.1'

config interface 'wan'
        option ifname 'eth1.2'
        option proto 'dhcp'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 3 5t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '4 6t'

config route
        option interface 'wan'
        option netmask '255.255.255.0'
        option target '192.168.31.0'
        option gateway '0.0.0.0'
        option metric '20'

config interface 'tap0'
        option proto 'none'
        option ifname 'eth1'
        option auto '1'


config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config include
        option path '/etc/firewall.user'


config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option nonegcache '0'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv6 'server'
        option ra 'server'
        option ra_management '1'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
15: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    inet 192.168.32.1/24 brd 192.168.32.255 scope global br-lan
       valid_lft forever preferred_lft forever
18: eth1.2@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    inet 192.168.31.15/24 brd 192.168.31.255 scope global eth1.2
       valid_lft forever preferred_lft forever
default via 192.168.31.1 dev eth1.2  src 192.168.31.15
192.168.32.0/24 dev br-lan scope link  src 192.168.32.1
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default
client/ipconfig
Windows IP Configuration


Ethernet adapter Ethernet 3:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Ethernet adapter Ethernet 4:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::a50b:1f5d:a452:e448%22
   IPv4 Address. . . . . . . . . . . : 192.168.31.93
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.31.1

Wireless LAN adapter Local Area Connection* 1:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Wireless LAN adapter Local Area Connection* 11:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . : lan
   IPv6 Address. . . . . . . . . . . : 2600:8800:7b80:7db::7b9
   IPv6 Address. . . . . . . . . . . : 2600:8800:7b80:7db:6d0e:9f0f:3098:8d2c
   IPv6 Address. . . . . . . . . . . : fdb7:3e79:7b05::7b9
   IPv6 Address. . . . . . . . . . . : fdb7:3e79:7b05:0:6d0e:9f0f:3098:8d2c
   Temporary IPv6 Address. . . . . . : 2600:8800:7b80:7db:140b:feb0:812:c269
   Temporary IPv6 Address. . . . . . : fdb7:3e79:7b05:0:140b:feb0:812:c269
   Link-local IPv6 Address . . . . . : fe80::6d0e:9f0f:3098:8d2c%14
   IPv4 Address. . . . . . . . . . . : 192.168.76.215
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : fe80::6038:e0ff:feb6:4030%14
                                       192.168.76.1

Clearly it will never work if the LAN interface on the router is 192.168.32.0/24 and the VPN server is allocated an IP range from 192.168.31.0/24 which is the WAN.
The way it is you don't need the WAN interface. You can assign a static IP on the LAN interface from the 192.168.31.0/24 subnet, shut down DHCP server on LAN interface, and connect the LAN interface you your upstream router.
And I believe there is an IP conflict as you are using 192.168.31.1 in server bridge but it looks like it also belongs to the upstream router.

Also this static route in the wan

config route
        option interface 'wan'
        option netmask '255.255.255.0'
        option target '192.168.31.0'
        option gateway '0.0.0.0'
        option metric '20'

is pointless as the wan interface belongs to this subnet, so the prefix should exist as directly connected. In your case I don't see it so you need to fix that first.

To recap:
Erase WAN interface and zones.
Attach the TAP0 of VPN server on the LAN interface.

1 Like

I gotcha, that makes a lot of sense.

I don't have ready access of the device without taking a drive. Would I be able to wipe out the WAN interface and switch the LAN interface over from eth0 to eth1, or am I just asking for trouble trying to save myself a ~45min drive?

What @trendy said. For a TAP OpenVPN, add the TAP interface into the lan network (br-lan). This is entirely layer 2. The remote users will work like they are on your LAN. They will get a DHCP address from the LAN server in the main router. No routing or firewalls need to be configured for VPN users to reach the whole network.

The VPN server doesn't have a WAN network. It is a device on the LAN. It has a LAN IP that is in the same network as the rest of the LAN. This should be set statically to allow it to be referenced in the main router's firewall. The clients' incoming connections from the Internet need to be port-forwarded through the main router to the VPN server.

2 Likes

You can do all these changes in Luci or UCI where there is commit and restore in case something went wrong.

Alright, so I've managed to wipe out the WAN and associated FW zone, but now the device doesn't appear to have internet. Do I want to setup the LAN interface in "DHCP client" mode?.

EDIT: I can't run opkg update, which leads me to believe it does not have internet access; however, I do have web and SSH access of the device.

EDIT2: Forgot to mention, I had to wipe the device... Completely vanilla installation, aside from disabling VLAN, removal of WAN interface and FW zone, and removal of WLAN stations.

EDIT3: I reserved an IP address for this device and have been able to access it using that address, but for what it's worth, I cannot switch the LAN interface to "DHCP Client".

EDIT4: I manually set the Default Gateway and DNS servers (using Google's for now) and now I can download packages...

EDIT5: I can ping the device on the network from other computers, and the device can ping other computers on the network. But VPN connected clients cannot ping out or receive a ping. I also cannot ping the VPN device from a VPN connected client. I'm using the same config as above in original post.

Updated diagnostic output from device
config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdcb:3242:20c0::/48'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.31.15'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 3 5t'
        option vid '1'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '4 6t'
        option vid '2'


config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option network ' '

config include
        option path '/etc/firewall.user'


config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option nonegcache '0'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'

config dhcp 'lan'
        option interface 'lan'
        option ignore '1'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
8: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    inet 192.168.31.15/24 brd 192.168.31.255 scope global br-lan
       valid_lft forever preferred_lft forever
192.168.31.0/24 dev br-lan scope link  src 192.168.31.15
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

You need to add gateway and DNS under the LAN interface (most likely the upstream LEDE router that handles routing/DHCP)
In Firewall section, either add the LAN interface in LAN firewall zone or switch

option forward 'REJECT'

at the defaults section into ACCEPT.
Finally change option server_bridge '192.168.31.1 ... to .31.15
I hope you have already bridged tap0 under LAN.

I appreciate all of your help so far. I still cannot ping the server from a connected client, or vice versa.

I should mention that the VPN Network is listed as "Public" in the "Networking and Sharing Center", which is typically an early indicator that network sharing will be an issue. Ordinarily, setting a route like route 0.0.0.0 0.0.0.0 would "force" it into "Private" status.

None of the routing I've tried has resolved the issue, which I suppose isn't much of a surprise, given that both you and the other person trying to help say that additional routing isn't necessary in this case.

Updated configs / diagnostics

vpn_server: /etc/config/network
config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdcb:3242:20c0::/48'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.31.15'
        option gateway '192.168.31.1'
        option dns '192.168.31.1'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 3 5t'
        option vid '1'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '4 6t'
        option vid '2'

config interface 'tap0'
        option type 'bridge'
        option proto 'none'
        option auto '1'
        option ifname 'eth0.1 tap0'
vpn_server: /etc/config/firewall
config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option network 'lan'

config include
        option path '/etc/firewall.user'
vpn_server: /etc/config/dhcp
config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option allservers '1'

config dhcp 'lan'
        option interface 'lan'
        option ignore '1'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'
vpn_server: *ip -4 addr ; ip -4 ro ; ip -4 ru*
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
518: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    inet 192.168.31.15/24 brd 192.168.31.255 scope global br-lan
       valid_lft forever preferred_lft forever
default via 192.168.31.1 dev br-lan
192.168.31.0/24 dev br-lan scope link  src 192.168.31.15
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default
vpn_server: /etc/config/openvpn
config openvpn 'vpnserver'
        option enabled '1'
        option dev 'tap0'
        option port '1196'
        option proto 'udp'
        option comp_lzo 'yes'
        option keepalive '10 120'
        option persist_key '1'
        option persist_tun '1'
        option ca '/etc/openvpn/ca.crt'
        option cert '/etc/openvpn/my-server.crt'
        option key '/etc/openvpn/my-server.key'
        option dh '/etc/openvpn/dh2048.pem'
        option tls_auth '/etc/openvpn/tls-auth.key 0'
        option mode 'server'
        option tls_server '1'
        option server_bridge '192.168.31.15 255.255.255.0 192.168.31.93 192.168.31.99'
        option client_to_client '1'
        option status '/tmp/openvpn_tap0.status'
        #list push 'route 192.168.31.0 255.255.255.0 192.168.31.15 350'
        list push 'dhcp-option DNS 192.168.31.15'
        #list push 'redirect-gateway def1'

vpn_client: client.ovpn
  dev tap
  client
  proto udp
  fast-io
  remote vpn.server.address 1196
  remote-cert-tls server
  nobind
  persist-key
  persist-tun
  comp-lzo no
  verb 3
  key-direction 1
  #route 0.0.0.0 0.0.0.0 192.168.31.15 350
  #route 192.168.31.0 255.255.255.0 192.168.31.1 350
  #route-metric 350
<keys omitted>
vpn_client: *route print -4*
===========================================================================
Interface List
 12...00 ff 81 0c 40 9e ......Private Internet Access Network Adapter
 22...00 ff dc fb 95 14 ......TAP-Windows Adapter V9
 19...10 02 b5 57 47 7b ......Microsoft Wi-Fi Direct Virtual Adapter
 15...12 02 b5 57 47 7a ......Microsoft Wi-Fi Direct Virtual Adapter #2
 14...10 02 b5 57 47 7a ......Intel(R) Dual Band Wireless-AC 7265
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     192.168.11.1   192.168.11.215     50
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
     192.168.31.0    255.255.255.0         On-link     192.168.31.93    281
    192.168.31.93  255.255.255.255         On-link     192.168.31.93    281
   192.168.31.255  255.255.255.255         On-link     192.168.31.93    281
     192.168.11.0    255.255.255.0         On-link    192.168.11.215    306
   192.168.11.215  255.255.255.255         On-link    192.168.11.215    306
   192.168.11.255  255.255.255.255         On-link    192.168.11.215    306
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link    192.168.11.215    306
        224.0.0.0        240.0.0.0         On-link     192.168.31.93    281
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link    192.168.11.215    306
  255.255.255.255  255.255.255.255         On-link     192.168.31.93    281
===========================================================================
Persistent Routes:
  None

That last one is probably more of what you asked for a few days ago.

I would start looking into the upstream router, but the fact that I cannot ping the VPN server from a connected client within the tunnel (or vice versa) stands out. I think I should fix that before trying to adjust anything in the upstream router.

I don't think this is necessary

config interface 'tap0'
        option type 'bridge'
        option proto 'none'
        option auto '1'
        option ifname 'eth0.1 tap0'

Just add the tap0 at the ifname option of lan interface.
Other than that routing looks good from client perspective:

192.168.31.0    255.255.255.0         On-link     192.168.31.93    281

Next thing to verify is that packets arrive to the vpnserver, by using tcpdump. tcpdump -i any -vvn host 192.168.31.93

I don't think that upstream router has anything to do here, as the vpn session is set up successfully.

Alright, I can ping things finally! Deleting the extraneous tap interface and bridging the lan adapter so that it included tap0 (per your instructions), did the trick :slight_smile:

I can't load the shares from the remote network, which, like I said before, is ordinarily solved by adding route 0.0.0.0 0.0.0.0 to the client's .ovpn file.

Thank you so much for your patience and effort in this!

EDIT: The network shares are up!

I changed both VPN configs, adding list push 'route 0.0.0.0 0.0.0.0 192.168.31.15 350' to the server, and changing comp-lzo no to comp-lzo yes (to remove the Bad compression stub decompression header byte: 102 error I noticed in the OpenVPN log in the client).

I've used the route 0.0.0.0 0.0.0.0 trick so many times now that I've completely forgotten why it was necessary in the first place. Any ideas?

I didn't notice that, but in general settings in both server and client must match.

It is directing all traffic from the client to go through the tunnel.
Are the network shares inside 192.168.31.X or somewhere else?

Yes, they are located in the 192.168.31.xxx subnet. I added rules to the firewall to whitelist that subnet before I did anything else with the test PC.

If I take your meaning correctly, I don't think I want to direct all traffic through the tunnel; however, unless I add that command, the VPN network is listed as "Unidentified network / Public".

I've mucked around in the registry to force a physical adapter into "Private" before, but I can't recall ever having luck forcing a virtual adapter to go "Private" any other way. In my experience, for Samba shares to work in Win10, usually the final hiccup is making sure the network is set to "Private".