Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update vpn_softetherbridge.md : to briged interaface will assiged with physical interface's MAC address. #589

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

LinearAlpha
Copy link

In previous methods, the physical and bridged interfaces were both online, so a single device had two different IP addresses. Thus, it caused performance issues and sometimes (in my case, all the time) DNS errors that prevented the device from accessing the Internet.

By setting the bridge interface with the physical interface's MAC address. We can take advantage of the bridged interface with a single IP address from the router and improve the performance of the VPN connection. Also, users do not need to search for a new IP address assigned to the bridge interface.

Please let me know if you have any concerns or questions about these changes. Thank you!

In previous methods, the physical and bridged interfaces were both online, so a single device had two different IP addresses. Thus, it caused performance issues and sometimes (in my case, all the time) DNS errors that prevented the device from accessing the Internet.

By setting the bridge interface with the physical interface's MAC address. We can take advantage of the bridged interface with a single IP address from the router and improve the performance of the VPN connection. Also, users do not need to search for a new IP address assigned to the bridge interface.

Please let me know if you have any concerns or questions about these changes.
Thank you!
tools/vpn/vpn_softetherbridge.md Outdated Show resolved Hide resolved
tools/vpn/vpn_softetherbridge.md Show resolved Hide resolved
@sebastiankb
Copy link
Contributor

from today's PlugFest call:

  • there is no objection to use VPN during the PlugFest
  • @egekorkan will test the provided updated guideline from @LinearAlpha (@k-toumura will support)
  • PR can be merged when the merge error is solved

To reflect the changes that I made, I've updated the vpnbridge file.
As Toumura-san suggested, the method of getting a physical MAC address changed from 'ifconfig' to 'ip link.'

Also, download links for the Softether VPN have been updated to comply with the guidelines. Still, the SoftEther VPN dev and stable release pages have been added as alternative options since the dev version(ver 5.x.x) is more active than the legacy version.
tools/vpn/vpn_softetherbridge.md Outdated Show resolved Hide resolved
tools/vpn/vpn_softetherbridge.md Outdated Show resolved Hide resolved
tools/vpn/vpn_softetherbridge.md Outdated Show resolved Hide resolved
tools/vpn/vpn_softetherbridge.md Outdated Show resolved Hide resolved
tools/vpn/vpn_softetherbridge.md Outdated Show resolved Hide resolved
tools/vpn/vpn_softetherbridge.md Outdated Show resolved Hide resolved
tools/vpn/vpn_softetherbridge.md Outdated Show resolved Hide resolved
tools/vpn/vpn_softetherbridge.md Outdated Show resolved Hide resolved
tools/vpn/vpn_softetherbridge.md Outdated Show resolved Hide resolved
tools/vpn/vpn_softetherbridge.md Show resolved Hide resolved
Thank you for all the suggestions!
@TallTed
Copy link
Member

TallTed commented Nov 5, 2024

@LinearAlpha @sebastiankb @egekorkan
Please correct typos in title, from

Update vpn_softetherbridge.md : to briged interaface will assiged with physical interface's MAC address

to

Update `vpn_softetherbridge.md`: bridged interface will be assigned with physical interface's MAC address

@k-toumura
Copy link
Contributor

Thank you for the PR. I've tested it out on my end as well.

With Linux bridges, one of the NIC's MAC addresses is automatically assigned to the bridge itself, and the IP address is generally assigned only to the bridge. Is there a specific reason to explicitly copy the MAC address? For example, in a configuration like the one below, would it be necessary for br0's MAC address to always match the physical NIC (in this case, wlan0)?

graph TD;
  vpnbridge(SoftEther VPN bridge)
  dhclient(DHCP client and other processes)
  other(other machines in the local WiFi network)
  tap_svpn([tap_svpn<br>MAC: 01:23:45:67:89:ab])
  br0([br0<br>MAC: same as tap_svpn or wlan0<br>IP: 192.168.30.2])
  wlan0([wlan0<br>MAC: cd:ef:01:23:45:67])
  subgraph VPN Bridge
   tap_svpn --> vpnbridge;
  br0 --> tap_svpn;
  br0 --> wlan0;
  dhclient --> br0;
  end
  subgraph local WiFi network
  wlan0 --> other
  end
Loading

On a separate note, by using ip link add br0 type bridge instead of brctl addbr br0, we could eliminate the need to install bridge-utils.

Thank you again!

@LinearAlpha
Copy link
Author

LinearAlpha commented Nov 18, 2024

@k-toumura

Hello, sorry for the late reply,

  • Is there a specific reason to explicitly copy the MAC address?

In my experience, without copying the MAC address into the bridge interface, I had an issue with the DNS resolution, so the bridge or VPN server could not connect to the internet.

Also, I've seen that copying the MAC address into the bridged interface shows better performance and stable connections. (I've tried to figure out why it is more stable, but I cannot figure out why)

  • would it be necessary for br0's MAC address to always match the physical NIC?

The MAC address always matches the physical interface that connects to the ethernet (more likely, the interface that connects to the router).

So, yes, in this case, it needs to match the MAC address br0 with wlan0.
However, most of my cases were using WLAN as a VPN wifi access point that I did not know how to configure it for this case, but my guess is similar to how to set up a wifi connection into netplan but having extra lines for bridged network.

Lastly, I used brctl, which can be a permanent solution that does not need to reconfigure every time it reboots.

Thank you for your time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants