Bridge with VLAN support issue

Post your questions about SoftEther VPN software here. Please answer questions if you can afford.
Post Reply
scegg
Posts: 18
Joined: Mon Mar 31, 2014 5:26 pm

Bridge with VLAN support issue

Post by scegg » Wed Apr 17, 2019 7:44 am

Hi. I have an issue on bridging with VLAN support.

Server: A new hub is created, without NAT, without local bridge. System is built on Windows Server.
Client A: A hub is created and linked to the server hub. Local bridge is created on a NIC. NIC is connected to a switch port with VLAN Trunk enabled. System is built on Raspberry Pi 3B+ with Raspbian system. Switch is a CISCO-2960.
Client B: A hub is created and linked to the same server hub with VLAN ID policy set in connection. Local bridge is created on a NIC (loopback driver on Windows). System is built on Realtek network interfaces (with VLAN ID visible in device manager) with Windows.

What I need: On client B, the NIC bridged should at the same lan as the client A connected with the VLAN ID specified in policy.
But actually it does not work at all.

When the switch port connect to client A is NOT set as VLAN Trunk, the VLAN ID policy is NOT set either, the connection works without any problem.

It should be something wrong on VLAN related settings only.

I need to use multiple clients with different VLAN. It’s necessary to use VLAN trunk on client A and server.

Any help?
Thanks.
Last edited by scegg on Wed Apr 17, 2019 12:17 pm, edited 1 time in total.

scegg
Posts: 18
Joined: Mon Mar 31, 2014 5:26 pm

Re: Bridge with VLAN support issue

Post by scegg » Thu Apr 18, 2019 6:16 am

I checked https://www.vpnusers.com/viewtopic.php?t=4878 but still have problem.

Now I created another virtual hub on server, using a user created in original hub with vlan policy set, cascaded to the original hub.
In the session list of the original hub, I can see the connection from the new hub listed with VLAN ID number.
In the session list of the new created hub, I can see the connection to the original hub listed with NO VLAN ID number.
In the MAC address list and IP address list of the new created hub, I CANNOT see any items from the original hub session.
When user connected to the new created hub, it still doesn't work.

One more question: In the MAC address list of the original hub, I can see lots of mac from the network of the client A attached, but no VLAN ID displayed. And in the IP address list, many IPs from the network of the client A attached are displayed too. Does that mean VLAN Tag is not transported from Client A?

cedar
Site Admin
Posts: 1141
Joined: Sat Mar 09, 2013 5:37 am

Re: Bridge with VLAN support issue

Post by cedar » Tue Jun 04, 2019 9:53 am

Policy can set on both cascades and user.
Which policy did you use?

scegg
Posts: 18
Joined: Mon Mar 31, 2014 5:26 pm

Re: Bridge with VLAN support issue

Post by scegg » Wed Jul 17, 2019 4:44 am

cedar wrote:
Tue Jun 04, 2019 9:53 am
Policy can set on both cascades and user.
Which policy did you use?
user side uses default policy.
server side uses policy with VLAN support.

cedar
Site Admin
Posts: 1141
Joined: Sat Mar 09, 2013 5:37 am

Re: Bridge with VLAN support issue

Post by cedar » Wed Jul 17, 2019 5:14 am

In sessions where a VLAN ID policy is set, a VLAN tag is attached to the received packet and sent to the virtual HUB, and the tag is removed from the sent packet.
If you want to cascade VLAN as trunk, do not set VLAN ID policy.

scegg
Posts: 18
Joined: Mon Mar 31, 2014 5:26 pm

Re: Bridge with VLAN support issue

Post by scegg » Wed Jul 17, 2019 5:27 am

cedar wrote:
Wed Jul 17, 2019 5:14 am
In sessions where a VLAN ID policy is set, a VLAN tag is attached to the received packet and sent to the virtual HUB, and the tag is removed from the sent packet.
If you want to cascade VLAN as trunk, do not set VLAN ID policy.
Thanks for your clarification.

In my case, the requirement is:
On the site A: One client is bind to a NIC, connected to a VLAN Trunk port. It should forward all data no matter the VLAN ID is, with the VLAN ID information to the server.
On the server side: One hub is created, with no binding, for connecting sites.
On the site B: Multiple clients need to be connected to the server hub. But different user will need to work with different VLAN. The VLAN is fixed on user account and should be specified in server side.

My solutions are:
Original plan:
On site A: No VLAN related policy is applied.
On server side: Each user, created for site B, is set with a VLAN ID policy. For the one used in site A, no VLAN related policy enabled.
On site B: No VLAN related policy is applied.
After site A connected, I can see many IP found in hub on server side. When clients from client B connected, they CANNOT communicate to the specified VLAN on site A.

Some article from here says my original plan will not work by design. I have to create cascade hub for each VLAN, so here is the 2nd version plan:
On site A: No VLAN related policy is applied.
On server side: A hub-A for site A only, with no VLAN ID policy. For each VLAN, a dedicated hub is created with VLAN ID set and connected it to the hub-A.
On site B: Each user connect to the specified hub which has VLAN ID set.
But it still doesn't work.

Any idea?
Thanks.

cedar
Site Admin
Posts: 1141
Joined: Sat Mar 09, 2013 5:37 am

Re: Bridge with VLAN support issue

Post by cedar » Wed Jul 17, 2019 5:55 am

Is there a problem at Site B?
At which hub did you observe untagged packets?
Where do those untagged packets come from?

scegg
Posts: 18
Joined: Mon Mar 31, 2014 5:26 pm

Re: Bridge with VLAN support issue

Post by scegg » Wed Jul 17, 2019 6:07 am

cedar wrote:
Wed Jul 17, 2019 5:55 am
Is there a problem at Site B?
At which hub did you observe untagged packets?
Where do those untagged packets come from?
I don't know. On the hub linked to site A, I can see lots of IP address listed in server management console. It may be right or wrong I don't know, coz the link should be totally VLAN Trunk enabled. I don't know whether it should be right or wrong to see those IP listed in hub.

At the hub linked with the hub above, with VLAN ID specified, no IP listed at all. When client from site B connect to them, with no doubt, it does not work.

Original plan:
Switch port with VLAN trunk --<cable>-- site A --<vpn (no VLAN ID specified)>-- server hub (hub-A) --<vpn (VLAN ID set)>-- site B client software

2nd plan
Switch port with VLAN trunk --<cable>-- site A --<vpn (no VLAN ID specified)>-- server hub (hub-A) --<cascade (VLAN ID set)>-- server hub (hub-B) --<vpn VLAN ID specified)>-- site B client software

I can see IP from the switch listed in hub-A, and hub-A only.

cedar
Site Admin
Posts: 1141
Joined: Sat Mar 09, 2013 5:37 am

Re: Bridge with VLAN support issue

Post by cedar » Wed Jul 17, 2019 6:19 am

Tagged packets do not appear in the IP table.
Please refer to the MAC address table.

scegg
Posts: 18
Joined: Mon Mar 31, 2014 5:26 pm

Re: Bridge with VLAN support issue

Post by scegg » Wed Jul 17, 2019 6:57 am

cedar wrote:
Wed Jul 17, 2019 6:19 am
Tagged packets do not appear in the IP table.
Please refer to the MAC address table.
I guess so. But actually it's displayed in IP table.
My site A is built with Raspberry Pi 3B+ with Raspbian, VLAN truck port with no VLAN ID policy at all. It seems to be something wrong here. But funny thing is, when bind the hub to server side network card, server cannot communicate to those IP. If the VLAN Tag is removed, it should work without problem in this test.

Do you think my original plan should work if there is nothing wrong in config?

cedar
Site Admin
Posts: 1141
Joined: Sat Mar 09, 2013 5:37 am

Re: Bridge with VLAN support issue

Post by cedar » Wed Jul 17, 2019 7:03 am

There is no difference in VPN behavior with either plan.
I suspect that the Raspberry Pi NIC driver is passing untagged packets to the raw socket.
Please try to set the same configuration on other Windows PC.

scegg
Posts: 18
Joined: Mon Mar 31, 2014 5:26 pm

Re: Bridge with VLAN support issue

Post by scegg » Wed Jul 17, 2019 7:06 am

cedar wrote:
Wed Jul 17, 2019 7:03 am
There is no difference in VPN behavior with either plan.
I suspect that the Raspberry Pi NIC driver is passing untagged packets to the raw socket.
Please try to set the same configuration on other Windows PC.
Thanks for your idea.
I'll do that in next project...

Post Reply