This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
Softether VPN + ReadyNAS — a better solution for full access to network AND the NAS itself
I tried to set up the Softether VPN and struggled a bit, like many others on here, with not being able to access the ReadyNAS directly when connected.
First I set it up with the bridge to eth0 as would be standard for softether VPN, and I could connect to other devices on the network, but not the NAS itself. Apparently the linux kernel doesn't really like packets going 'out' the interface if they're destined toward that same interface.
I played around with SecureNAT and bridging to a tap device, without any luck. That road was also much more complicated so am kind of glad not to have ended up down there.
I then found the advice in a thread on here to set up the second adaptor with a random address (outside the local network subnet). e.g. my eth0 is on the 10.0.0.0/24 range so eth1 would be set up as perhaps 192.168.60.1 and plugged into the same physical network as eth0. This fixes the issue of packets being routed back to the NAS itself (so you can access the NAS from the VPN)... but creates another problem. I ended up having avahi (aka Bonjour or mDNSresponder) advertising two separate addresses for the NAS to local machines: one on 10.0.0.0 and one on 192.168.60.1 (which is inaccessible), and when readynas.local resolved to the latter, the connection would fail. This isn't a problem for many people, who don't rely on bonjour/mdnsresponder/avahi (i.e. if you don't use your-nas-name.local to access it)...
So my next thought was... okay what's actually wrong with having them both on the same subnet? eth0=10.0.0.2 and eth1=10.0.0.3. Then whichever address is advertised as MyReadyNAS.local will be reachable at least. This basically works. Of course it does—Linux doesn't really have a problem with having multiple IPs on the same subnet... as long as they're not bridged together (whatever you do, do NOT use softether to bridge your VPN hub thingy to both adaptors at once, if they're plugged into the same network!). So there's a solution.
Turns out you can go one step further, and set them to the same static IP. Linux is actually fine with this too (I suspect most OSes are). Both eth0 and eth1 as 10.0.0.2, with the VPN bridge on eth1 (it could be either of course, but NOT BOTH).
This solves the VPN bridging issue. And it doesn't cause problems for the advertised address of the ReadyNAS.
I'm not 100% sure exactly how this affects performance, but I think it either has no impact or could actually slightly increase your maximum network bandwidth when you have multiple clients connecting to the ReadyNAS—two different interfaces with the same IP mean that some packets might go into one or the other (as far as I am aware it's random which ethernet port would be chosen by the client when connecting to the IP common to both). It also adds some redundancy, if one of the ports (on the ReadyNAS or the switch it's connected to) failed, or the ethernet cables were damaged or accidentally unplugged, you'd still have a link to the NAS.
I can't think of any negative effects of doing this (maybe an infintecimal amount of additional power used to power the 2nd ethernet port).
TL;DR: For setting up Softether VPN
1. Set both eth0 and eth1 to the same static IP on your network (IP, netmask, router all identical, DNS should be the same or at least working DNS servers).
2. Plug both ethernet ports into your switch/router—yep, both in the same network, it's OK to do this because the NAS isn't a switch, it's not bridging/routing between the two ports.
2. Set up softether VPN, configure your Virtual Hub and users as per the guide and/or your desired configuration...
3. For the Local Bridge Setting, bridge your Virtual Hub to ONE of the ethernet ports (e.g. eth1).
Re: Softether VPN + ReadyNAS — a better solution for full access to network AND the NAS itself
FYI, here is the reference:
While it is possible to designate the physically communicating network adapter used by the VPN Server or VPN Bridge for VPN communication as the physical network adapter to locally bridge to the physical LAN, the following problems may arise.
The VPN Server or the VPN Bridge have to separate the frames used for VPN communication such as for cascade connection with another VPN Server, and the frames subject to local bridging, thereby consuming CPU time and slowing communication speed.
The Ethernet frames inserted into the physical network adapter have to be copied by both the frame buffer to the TCP/IP protocol stack in the OS and the frame buffer required when inserting for local bridging, thereby placing a burden on CPU time and memory and slowing communication speed.
Accordingly, when local bridging with a physical LAN, a physically new LAN should be installed on the computer running the VPN Server or VPN Bridge and used exclusively for local bridging if possible.
[Some stuff removed]
No Protocol Stack is Used for the Local Bridge Network Adapter
Where there is a network adapter prepared on the computer for use exclusively in local bridging, it is recommended that the TCP/IP protocol and other protocol stacks be disabled on that network adapter to enhance performance. The role of the local bridge network adapter is to release Ethernet frames between the Virtual Hub and the physical LAN, entirely without the need for intervention from the protocol stack of the OS running the Virtual Hub.
Re: Softether VPN + ReadyNAS — a better solution for full access to network AND the NAS itself
Actually, the right way to do it (per the docs on the Softether site) is to have no address assigned to the bridging port. That is quite easilly done on a ReadyNAS by disabling both IPv4 and IPv6. Of course, that's not an option for units with a single ethernet port. That is how mine is set up, and it has been stable for months.
Of course, I'm moving to Zerotier now, as I find it a vast improvement over a standard VPN. But Softether and Zerotier happily co-exist while I do the transition. I'm not using the bridging function of Zerotier, which may or may not affect their co-existence.
Re: Softether VPN + ReadyNAS — a better solution for full access to network AND the NAS itself
Very interesting, I didn't see that suggestion on the Softether site, but it makes a lot of sense too (especially if there are any actual down-sides to having two ethernet ports with the same IP?)
Re: Softether VPN + ReadyNAS — a better solution for full access to network AND the NAS itself
FYI, here is the reference:
While it is possible to designate the physically communicating network adapter used by the VPN Server or VPN Bridge for VPN communication as the physical network adapter to locally bridge to the physical LAN, the following problems may arise.
The VPN Server or the VPN Bridge have to separate the frames used for VPN communication such as for cascade connection with another VPN Server, and the frames subject to local bridging, thereby consuming CPU time and slowing communication speed.
The Ethernet frames inserted into the physical network adapter have to be copied by both the frame buffer to the TCP/IP protocol stack in the OS and the frame buffer required when inserting for local bridging, thereby placing a burden on CPU time and memory and slowing communication speed.
Accordingly, when local bridging with a physical LAN, a physically new LAN should be installed on the computer running the VPN Server or VPN Bridge and used exclusively for local bridging if possible.
[Some stuff removed]
No Protocol Stack is Used for the Local Bridge Network Adapter
Where there is a network adapter prepared on the computer for use exclusively in local bridging, it is recommended that the TCP/IP protocol and other protocol stacks be disabled on that network adapter to enhance performance. The role of the local bridge network adapter is to release Ethernet frames between the Virtual Hub and the physical LAN, entirely without the need for intervention from the protocol stack of the OS running the Virtual Hub.
Re: Softether VPN + ReadyNAS — a better solution for full access to network AND the NAS itself
Thanks for the reference — I actually read that guide (amongst others) and seem to have missed the precise point being made there.
So if I'm understanding correctly, the major downside to my proposed method (eth0 and eth1 identical IPs) is the extra CPU load in duplicating frames on the eth1 (bridged) interface, and this redundant CPU load is avoided by removing the IPs so that eth1 is for "bridging only", so to speak.
If so, then yeah, that's a much better solution given the limited CPU power (for most NASes anyway).
