NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
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...
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.
Obtained from here: Softether VPN Server Manual
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?)
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.
Obtained from here: Softether VPN Server Manual
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).
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
