Unavailability of smb sharing via vpn (L2TP / ipsec)

Support
,
1

Greetings to the community.
I would like to put my situation into discussion with the expectation of some ideas:

I have been running a nethserver for local sharing for some time now. Everything works as it should. For homeoffice users we use the connection via OpenVPN on the nethserver. This also works fine. Due to the arrival of a new Mac laptop user running “Big Sure” and CPU M1, I am dealing with its connection from home. The OpenVPN client application Tunnelblick is not currently supported on OS “Big Sur” … and who knows if it will ever be … everything is in beta testing … Apple applies restrictions for loading drivers in “Big Sur”. So we cannot solve this path yet. I implement a parallel VPN tunnel on the Mikrotik router. I set it up on technology (L2TP / ipsec) and I’m starting to test the connection and availability of services on the LAN through L2TP / ipsec. Connection and availability is OK, but sharing on a nethserver (smb) is broken. I will specify the situation … sharing for clients directly in the LAN - tested OK. Sharing for clients via OpenVPN (nethserver service) is also OK. Nethserver sharing for clients connected to an L2TP / ipsec VPN - no Samba response (or authorization prompt). Sharing to other servers in the same LAN (Windows server 2012R2), to Synology NAS also OK (works via L2TP / ipsec, also OPenVPN).

I don’t understand what makes it different for nethserver / samba from Synology / NAS (samba) and Windows server sharing …

I have some connection with setting up MTU and encrypting encrypted packets and setting up ethernet / bridge / smb on the nethserver. I don’t know how to tune on the nethserver side.

Comparison of what I see -
Synology (Linux) eth: eth0: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdisc mq state UP qlen 532

Nethserver:
em1: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000

br0: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

Thanks for any idea.
Viktor

NethServer release 7.9.2009 (final)
kernel 3.10.0-1160.11.1.el7.x86_64
Samba version 4.10.16

2

@Viktor_Moravec

Hi Viktor

You probably need to add in the IP used by the Mac for LT2P to the “Trusted Networks” for NethServer. For VPNs by NethServer, this is done automatically, but not if NethServer doesn’t “know” about your Microtic VPN…

Or - you could use Viscosity as VPN Client, that works on Mac Big Sur.
I’m using Viscosity here (On Mac) but mine is not yet on Big Sur…
Viscosity is commercial, but very reasonable price, and works great.
Licensing is per User, and that user can run Viscosity on as many Macs AND Windows as he wants / needs.
This is far superior to Tunnelblick.

My 2 cents
Andy

Bildschirmfoto 2021-01-21 um 11.14.18
Bildschirmfoto 2021-01-21 um 11.14.182190×872 106 KB

3

Hi Andy.

I don’t see a problem on the apple side - I tried it from Windows 10. The problem is the same. the nethserver firewall allows the entire LAN subnet C. The Ipsec on the mikrotik has its own pool within the C subnet.
Other packets pass (both from Mac and from client on Win), ping to nethserver is OK, web console of nethserver is also OK. Only samba is silent. Maybe we can log something …

Viktor

4

Viscosity as VPN Client may be nice, but I would like to solve VPN on ipsec for the future. Basically, it works quite well now - but I have a mystery with the different behavior of samba on the net server. Synology with samba is OK, samba on nethserver - so far a mystery. Nethserver is behind a firewall and only a green interface in the bridge configuration … What comes from the mikrotik router is everything like a LAN for it.
I really suspect a problem with the fragmentation of packets encapsulated in the L2PT / ipsec tunnel and samba on the nethserver side.

5

Hi

It’s anyway L2TP (Layer 2 Transport Protocol).

IPsec is crappier for road warrior users and much more suited for Site2Site VPNs, which is what I use here in Switzerland a lot.

I’ve switched most of my clients now from IPsec based RoadWarrior VPN to OpenVPN based RoadWarriors.

Reconnection is very much faster, less issues with restrictive Hotspots, a LOT of advantages.

A VPN should NOT use internal IPs for VPN Clients - this Method is outdated! You should use a seperate Network for VPNs - no matter if IPsec or OpenVPN or Wireguard.

Test out VPNtracker, this can handle almost anything with IPsec (And OpenVPN, but it’s MUCH slower than Viscosity). You can download a limited Client for testing. This is only for Mac.

For Windows you can test Greenbow VPN. I used that for my Windows RoadWarriors, it works very well and with almost any IPsec Firewall. Greenbow VPN can also do OpenVPN, but does not come close to Viscosity.

Both products are good, but you notice they’re built for IPsec and “can” handle OpenVPN. But nowhere as simple and as fast as Viscosity.

I’m also a heavy Synology user, about 30 at my clients. Synology and Windows do NOT care where a packet comes from. NethServer does!

Nethserver: Ping is no problem, even from the Internet, also the Web-GUI is specifically allowed from anywhere, to allow users to change their password. But Samba, Mail, Squid Proxy and other services require real LAN access. (Or trusted Networks!)

You can test Viscosity for about a Month on both Mac and Windows - it’s really FAST!

For me and my 30 clients all using NethServer as AD, mail, File, NextCloud, DokuWiki and Zabbix Monitoring, IPsec and OpenVPN work VERY well !

My 2 cents
Andy

6

In any case… Subnet of L2TP clients should be added as trusted networks.
Also, NethServer should “know” how to route that subnet. Via Static Routes or via Gateway…

1 Like
7

@pike
@Viktor_Moravec

There IS no subnet for L2TP, the Microtic allocates LAN IP Addresses (Which do not use routing, they’re in the LAN…). This is why the Client does NOT get a response back…
And that’s why it can’t go in Trusted Networks, because there is none… (Trusted Networks!).

My 2 cents
Andy

8

Thanks for your explanation, @Andy_Wismer but let me say that… i’m quite horrified, just like TAP installations for OpenVPN.
Which works great for only “inner VPN Clients”, but if there’s any different user profile (Remote workers, external collaborators, customers, sales department) won’t allow any differentiation (firewall rules, time conditions, etc etc).
It was quite tough for me make understand a customer that a full subnet change was necessary for allowing a customer to remote connect, but with a few answers most of questions were clarified (and the customer scared enough to allow the subnet change).

Anyway, going back to the issue. NethServer do not recognise L2TP clients as… clients. Because these addresses seems to lie on a bridge “unknown” to NethServer.

9

As I have already written, L2TP clients are assigned an ip address corresponding to the LAN subnet (a separate short pool that does not overlap with other clients in the LAN). Packets from the tunnel client on the microtike side go to the LAN. The l2tp-server interface is on mikrotik in bridge-local (as well as LAN ports). Nethserver does not distinguish this packet from others that are directly on the LAN. There is only one (br0) Nethserver interface - green zone. What should the firewall block ??? The SRC-IP of packets from the client is in the LAN range.

10

Is possible to change configuration from bridged to routed for L2TP clients?

11

@Viktor_Moravec

Some people have difficulty understanding!

Your IPs are LAN IPs, and cannot be reached by a simple broadcast, like any LAN client or host.
There is no routing (easily) possible.

Because You’re using LAN IPs for your L2TP VPN, contrary to what everyone knowledgeable will tell you, your VPN Client will not get any response. NethServer sends answers to the LAN - NOT to the Microtic to forward!

My 2 cents
Andy

See here:
https://community.ui.com/questions/L2TP-IPSec-VPN-Issue-when-remote-network-and-local-network-are-in-the-same-IP-range/5bca5946-4780-4665-a06b-91e400fe148b

Other Microtik users have the same problem!

The concept of using LAN IPs is from before 2000! Nowadays, you use “Other” Ips, commonly in the 10.x.x.x range. I use 10.99.XX.0/24 as VPN LAN (The XX corresponds with Octet 3 of the LAN IPs.). This works very well, and if I’m connected to several VPNs, I can “see” from the Network IP where I’m connected to.

12

I will specify again who did not read the whole thing.
L2TP is not in the bridge. This VPN is on mikrotik, it converts to LAN (arp-proxy settings in bridge-local). For everything in LAN for mkrotik including nethserver.

In the same LAN segment, sharing on windows server and NAS (synology / samba) is OK. Samba is silent on the nethserver.

13

Anything passed thru a Bridge / Router IS NOT IN THE LAN !!!

If you’re using LAN IPs for the VPNs, this is called “Bridged”, read the RFCs!

But as you know better, good luck!

Why come here looking for help with a foreign product, if you think you know better?

My VPNs all work without issues, more than 100 VPNs for RoadWarriors and about 40 Site2Site VPNs.

My 2 cents
Andy

14

Each service in the LAN responds to a request from the ip client and returns the microtik (using an arp-proxy) to the client in an encapsulated tunnel.
It works - verified on other services that match (ping anywhere on the device in the LAN, including the nethserver, on other Windows servers, on the Synology NAS, ip phone ip printer) … everything except samba on the nethserver!

I listen to the above opinions on using different VPNs, and bridge topologies or NAT and addressing … but I see the problem elsewhere.

15

Good Hunting! (Or finding!) :slight_smile:

16

I’m sorry I’m not as expert as you are.
Your VPN solution is certainly great. I didn’t ask to help with mikrotik if it offends you in any way. Not even a guide on how to make a VPN completely differently according to the guaranteed advice. I was just trying to find an answer to the different behavior of samba on the nethserver. I was expecting an idea how to find something from the nethserver log, or the idea of tuning settings.
In short, somehow understand the cause of the problem.
If there is anyone patient to explain it to me and write where to look, I will be happy.

… Finally, I can always abandon the idea of microtics / VPN L2TP, and use Viscosity as a VPN Client on a Mac.

17

IP Addressing

Before starting, determine which IP addresses to use for the L2TP server and clients and now many concurrent clients to support.

Server Address
An unused IP address outside of the Remote Address Range , such as 10.3.177.1 as shown in Figure L2TP IP Addressing.

Remote Address Range

Usually a new and unused subnet, such as 10.3.177.128/25 (.128 through .255). These are the addresses to be assigned to clients when they connect.

I’m NOT a fan of PFsense, but even they get this correct!

You might be aware of the fact that ProxyArp just handles IP packets. What Info is “INSIDE” the packet is ignored. Now, if your clients has it’s WAN IP in there, there’s your problem.

NethServer has a built in firewall, even if you didn’t install a firewall on NethServer. It does analyse the traffic. Why do you think there’s the concept of “trusted networks”?

Home Users or VPN Users need access, the trusted networks can be seen as a sort of whitelist for “Out of LAN” clients.

But you can’t add in LAN IPs in there…
And you can’t add in a “route” to your VPN clients, as they can’t be routed… They’re in the LAN, even when they aren’t really in the LAN…

My 2 cents
Andy

18

So should it be enough to temporarily turn off the firewall on the nethserver? … then test samba sharing? then we can say “yes is the problem in what you describe?”

19

You’ll never know until you try!

I’ve suggested several options for you to “isolate” the problem - or getting an alternative to work.

It’s up to you to try what works best in your environment / use case.

My 2 cents
Andy

20

I was not looking for an alternative, but understanding why it doesn’t work for the nethserver as it does for other servers on the same LAN.