SoftEther VPN User Forum

Posted: **Fri Feb 17, 2023 8:52 am**

Can we add permanent virtual interface for local bridge using "ip" command (or any other commands) in Linux for SE server on a remote host?

I tested "dummy" and did not work
Introduction to Linux interfaces for virtual networking

Code: Select all

 sudo ip link add eth0 type dummy

the rest of commands applied + MAC address of provided by SecureNAT (on SecureNAT just vDHCP enabled, vNAT disabled)

Also tested "macvlan" as mentioned here Create a virtual network interface using the iproute2 "ip link" command with a spoofed MAC address

Code: Select all

ip link add   name vif0 address 5E:FD:E6:69:83:DF  link eth0 type macvlan
ip addr add  192.168.104/24 brd + dev vif0
ip link set dev vif0 up

netstat

Code: Select all

netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0      1500     9350      0      0 0          4498      0      0      0 BMPRU
lo       65536      288      0      0 0           288      0      0      0 LRU
tap_tap   1500      298      0      0 0           256      0      0      0 BMRU
vif0      1500      394      0      0 0           477      0      0      0 BMPRU

it seems that P mode is enabled
Is the network device in promiscuous mode?

Code: Select all

grep -r 'promiscuous' /var/log/kern.log
Feb 16 11:00:50 server-fra kernel: [416435.753728] device eth0 entered promiscuous mode
Feb 16 21:17:14 server-fra kernel: [453419.230297] device eth1 entered promiscuous mode
Feb 17 11:13:06 server-fra kernel: [503570.743742] device vif0 entered promiscuous mode

As I read the documentation SE server emulates Ethernet (layer 2) switch named it "Virtual HUB"
And as long as I know tap devices operate at layer 2 so SE can bridge to a tap device (e.g. tap_tap) via Local Bridge
Stopping a SE server or making a HUB offline removes these tap devices (I know we can use "PostStartExec" with systemd but it does not have a use case for my condition)

Beside asking the VM provider to add a new interface (NIC) to the VM, is there any ways to make it work?

Also please correct me if I have misunderstood any concepts mentioned above.
Since I am not sure which type is the right way to use or even is it possible or no, maybe I should look at "MACVTAP/IPVTAP"

Regards

Posted: **Fri Feb 17, 2023 10:27 am**

shakibamoshiri wrote: ↑
Fri Feb 17, 2023 8:52 am
I tested "dummy" and did not work
...
(I know we can use "PostStartExec" with systemd but it does not have a use case for my condition)

- had "dummy" kernel module been loaded before using it?

- what's your objective?

Posted: **Fri Feb 17, 2023 1:41 pm**

solo wrote: ↑
Fri Feb 17, 2023 10:27 am
- had "dummy" kernel module been loaded before using it?

- what's your objective?

Q1.
Yes

Code: Select all

modprobe dummy

here are steps I followed
Linux: Create virtual network interface

Q2.
I am checking out both Stable and DE version
For some condition Stable works for some DE
As an example today I realized Mikrotik connects to Stable but fails to connect to DE version (error SSL handshake failed) for sstp-client
Another test a ran was having multi-HUB + multi-dnsmasq configurations and I noticed Stable is not reliable while DE is reliable
Thus I am running many "start" and "stop" with SE servers and each time I have to reconfigure tab_xxx(s)
As I said systemd helps to some degree but it is annoying to modify xyz.service file and daemon-reload

I want to have permanent interfaces so switching between SE servers has no effect on interface configuration. (+ learning more about networking and its configurations)

Posted: **Sat Feb 18, 2023 4:22 am**

shakibamoshiri wrote: ↑
Fri Feb 17, 2023 1:41 pm
I want to have permanent interfaces so switching between SE servers has no effect on interface configuration. (+ learning more about networking and its configurations)

I see. I think you got it right with the dummy NIC but it "did not work" because you had missed this...

3.6.11 Points to Note when Local Bridging in Linux, FreeBSD, Solaris or Mac OS X
Limitations within the Linux or UNIX operating system prevent communication with IP addresses assigned to the network adapter locally bridged from the VPN side (Virtual Hub side). The cause of this restriction lies with OS's internal kernel codes rather than with the SoftEther VPN. When wishing to communicate in any form with a UNIX computer used for local bridging from the VPN side (Virtual Hub side), (for instance, when running both the VPN Server / VPN Bridge service & the HTTP Server service and wishing to grant access to the server service from the VPN side as well), prepare and connect a local bridge network adapter and physically connect both it and the existing network adapter to the same segment (as explained in 3.6 Local Bridges, it is recommended to prepare a network adapter for exclusive use in local bridging for this and other situations).

In short, you need a workaround with double "dummy" bridge. Here is a very quick, proof of concept, test:

SE LBS with soft tap, no SecureNAT
ip link add name lo2 type dummy
brctl addbr br0
brctl addif br0 lo2 tap_tap
ifconfig br0 192.168.9.2 netmask 255.255.255.0 promisc arp up

Code: Select all

root@ubuntu:/home/a# ifconfig
br0       Link encap:Ethernet  HWaddr 5e:53:f4:48:db:1c
          inet addr:192.168.9.2  Bcast:192.168.9.255  Mask:255.255.255.0
          inet6 addr: fe80::5c53:f4ff:fe48:db1c/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1

root@ubuntu:/home/a# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.0.2.2        0.0.0.0         UG    0      0        0 enp0s3
10.0.2.0        *               255.255.255.0   U     0      0        0 enp0s3
192.168.9.0     *               255.255.255.0   U     0      0        0 br0

Windows SE client (only static IP for quick test)

Code: Select all

Ethernet adapter VPN - VPN Client:
        Connection-specific DNS Suffix  . :
        IP Address. . . . . . . . . . . . : 192.168.9.3
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . :

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
      192.168.9.0    255.255.255.0      192.168.9.3     192.168.9.3       1
      192.168.9.3  255.255.255.255        127.0.0.1       127.0.0.1       1

ping 192.168.9.2
Reply from 192.168.9.2: bytes=32 time<1ms TTL=64

back to Linux

Code: Select all

root@ubuntu:/home/a# ping 192.168.9.3
PING 192.168.9.3 (192.168.9.3) 56(84) bytes of data.
64 bytes from 192.168.9.3: icmp_seq=1 ttl=128 time=1.16 ms

iptables -t nat -A POSTROUTING -s 192.168.9.0/24 -o enp0s3 -j MASQUERADE

back to Windows

Code: Select all

route add 9.9.9.9 mask 255.255.255.255 192.168.9.2
ping 9.9.9.9
Reply from 9.9.9.9: bytes=32 time=67ms TTL=53

Cheers!

Posted: **Sun Feb 19, 2023 10:48 am**

solo wrote: ↑
Sat Feb 18, 2023 4:22 am

SE LBS with soft tap, no SecureNAT

ip link add name lo2 type dummy

brctl addbr br0

brctl addif br0 lo2 tap_tap

ifconfig br0 192.168.9.2 netmask 255.255.255.0 promisc arp up

Thank you for testing it but while I tested this way you mentioned
- worked on my local machine :)
- did not work on OVH servers :(
- worked on Hetzner servers :)
And I am more confused than before now, since I had something else in mind.

Originally I thought I have three ways of "Bridge"ing with SE server into a Linux machine
1. asking the Host Company (VM provider) to give me a second network adopter with IPv4/6 just the adopter to assign Private IPs
2. setting and configuring a second virtual network adapter using "ip" and "brct" commands
3. setting and configuring a tap device (which SE server does that) e.g tap_xxx

Number (3) tested many times it was okay
Number (2) is this question I asked about which you tested
But
Number (1) I tested last night at home while running vmWare ESXi on a server and did not work !

vmWare admin panel
- setting up a Linux server
- first network adopter added by ESXi
- adding second network adopter (no IP assigned)

Linux server running on ESXi
- first network adopter 192.168.1.9 (NOT was not used from ESXi) my home router 192.168.1.1/24
- second network adopter I assigned 192.168.30.1 (for SE server)
- SE server installed (stable version)
-- L2TP enabled
-- a user added to default HUB
-- vDHCP enabled / vNAT disabled
-- SE server Secure NAT > network adopter IP 192.168.30.2
-- SE server Secure NAT > vDHCP address 192.168.30.10 - 192.168.30.200 (default)
-- SE server Secure NAT > gateway 192.168.30.1
-- sysctl ip_forward enabled
-- iptables POSTROTING added
-- SE server local bridge, linked to second network adopter

result from L2TP client
- ping 192.168.30.2 (SE server network adopter) [ OK }
- ping 192.168.30.1 (gateway) and second network adopter added via ESXi -- it did not work :|

My expectation was that it should work but did not.
Thus I think I did not understand some fundamental part of SE server or Networking right :(

Posted: **Sun Feb 19, 2023 4:19 pm**

The kernel restriction "prevent communication with IP addresses assigned to the network adapter locally bridged from the VPN side" so we need to double bridge. On Linux it's easy with soft tap, on eg FreeBSD a hardware workaround is required.

It's irrelevant if you don't need to access the server from VPN itself.

Posted: **Sun Mar 19, 2023 5:46 pm**

solo wrote: ↑
Sun Feb 19, 2023 4:19 pm
The kernel restriction "prevent communication with IP addresses assigned to the network adapter locally bridged from the VPN side" so we need to double bridge. On Linux it's easy with soft tap, on eg FreeBSD a hardware workaround is required.

Yes working with IP forwarding is trickier than what I thought, but it did not make sense to me there could not be a solution for this.

solo wrote: ↑
Sun Feb 19, 2023 4:19 pm
It's irrelevant if you don't need to access the server from VPN itself.

I did not get you. What is the use case for bridging with an actual interface?

Also I felt dummy asking questions which appear to be irrelevant and decided to take CCNA , netfilter, iproute2 courses. So consider me a student who is learning "Network Engineering" and forgive me for any questions being asked naively.

first fix
We do not need "dummy" one to use a bridge and connecting to a SE server hub. Just
- SE tab interface
- iproute type bridge
are needed. I tested and it worked no "dummy is needed".

But the problem did not solve yet. if the SE server goes down, the tap device is done, ip address is lost, and when the SE server is up again,
- ip addr should be added
- the tap device should be added to bride

second fix
Theoretically just using "dumpy" one we should be able to solve it as mention here How can I create a virtual ethernet interface on a machine without a physical adapter and one answered has been approved. With a new test did not work, but trying it with "veth" type succeeded.

here is how
- a pair of "vath" is created
- one is connected to SE server hub
- one is added to a bridge
We can stop the SE server and start the SE server again. everything works fine and SE server shutdown has no effect to our "veth" or bridge. this is the right solution (at least up to now with what I know).

Posted: **Sun Mar 19, 2023 8:17 pm**

third fix
further testing reveals that we do not even need a bridge, just two pair of "veth" can be used. One for SE server bridge , the other one as the gateway.

Code: Select all

ip link add name softether type veth peer name host

- softether for SE server
- host as the gateway

Posted: **Sun Mar 19, 2023 9:07 pm**

shakibamoshiri wrote: ↑
Sun Mar 19, 2023 5:46 pm

solo wrote: ↑
Sun Feb 19, 2023 4:19 pm
It's irrelevant if you don't need to access the server from VPN itself.
I did not get you. What is the use case for bridging with an actual interface?

LAN and setup simplicity. This topic is getting convoluted...

SoftEther VPN User Forum

permanent virtual interface for a local bridge

permanent virtual interface for a local bridge

Re: permanent virtual interface for a local bridge

Re: permanent virtual interface for a local bridge

Re: permanent virtual interface for a local bridge

Re: permanent virtual interface for a local bridge

Re: permanent virtual interface for a local bridge

Re: permanent virtual interface for a local bridge

Re: permanent virtual interface for a local bridge

Re: permanent virtual interface for a local bridge