Reply

Re: How to prevent packets from being seen from devices which belong to other VLANs?

MainMa
Aspirant

How to prevent packets from being seen from devices which belong to other VLANs?

Hello.

I configured my GS516TP switch to use VLANs. There are currently three VLANs: VLAN 10, 11, and 12, with three devices, 10.0.10.5, 10.0.11.5, and 10.0.12.5 connecting respectively through ports 10, 11, and 12. The VLAN routing configuration is set, and the devices are configured to have the correct IP address, matching their VLAN.

  • VLAN 10 should communicate with the two other VLANs. All ports are therefore marked as untagged for this VLAN.
  • VLAN 11 should be able to communicate with the VLAN 10 only. Only the ports 10 and 11 are untagged.
  • VLAN 12 should be able to communicate with the VLAN 10 only. Only the ports 10 and 12 are untagged.

I was expecting that the machine connected to VLAN 12 would know nothing about any devices connected to VLAN 11. However, when running Wireshark on 10.0.12.5 and doing an HTTP request from 10.0.10.5 to 10.0.11.5, I can see:

  • The actual HTTP requests from 10.0.10.5 to 10.0.11.5.
  • The TCP ACK and TCP FIN-ACK packets.

The packets sent by the machine connected to VLAN 11 are however not visible to the machine from VLAN 12.

What should I do in order for the packets targetting 10.0.11.5 to stop being visible from a machine belonging to VLAN 12?

Model: GS516TP|ProSafe 16 ports PoE Smart switch
Message 1 of 4

Accepted Solutions
schumaku
Guru

Re: How to prevent packets from being seen from devices which belong to other VLANs?

Honestly, both answers were based on the experience of several users as well as on own experimenting. I'm still confused why Netgear does have the UI allowing these configurations all over on the Smart Managed Plus and Pro, while adding complexity for the administration if truly not workable and supported. 

 

For your test - please ensure you are using IP addresses from a single subnet (I still suspect you might not as per my comments above). this is essential as there is no router, and the connections are within one single network.

View solution in original post

Message 4 of 4

All Replies
schumaku
Guru

Re: How to prevent packets from being seen from devices which belong to other VLANs?

By 802.1q definition, each VLAN is an independent network, and has it's own broadcast domain - and can't see or access any other VLAN.

 

What you are trying to achieve is a so called asymmetric L2 VLAN.

 

Ensure there is no membership on any port for VLAN 1 (empty).

 

The port 10 (VLAN 10) must be set to PVID 10.

The port 11 (VLAN 11) must be set to PVID 11.

The port 12 (VLAN 12) must be set to PVID 12.

 

If using three different IPv4 subnets like 10.0.x.x/24 no routing will happen. for such a set-up, all systems must be in the same IPv4 subnet. Said this, an kind of ARP requests or IPv4 broadcasts must be visible on all ports.

Message 2 of 4
MainMa
Aspirant

Re: How to prevent packets from being seen from devices which belong to other VLANs?

This is very much the configuration I have right now: no memberships on any port for VLAN 1, the three PVIDs are also set correctly for the three ports.

While searching for the solution, I found https://community.netgear.com/t5/Smart-Plus-and-Smart-Pro-Managed/GS308E-Smart-Managed-Plus-VLAN/td-..., which describes the exact same problem, and the answer seems to indicate that the asymmetric VLANs are not supported by GS308E (nor does GS108E, according to https://community.netgear.com/t5/Smart-Plus-and-Smart-Pro-Managed/GS108Ev3-Multi-Port-Based-VLAN-tec...). How do I know if they are supported by GS516TP?

Message 3 of 4
schumaku
Guru

Re: How to prevent packets from being seen from devices which belong to other VLANs?

Honestly, both answers were based on the experience of several users as well as on own experimenting. I'm still confused why Netgear does have the UI allowing these configurations all over on the Smart Managed Plus and Pro, while adding complexity for the administration if truly not workable and supported. 

 

For your test - please ensure you are using IP addresses from a single subnet (I still suspect you might not as per my comments above). this is essential as there is no router, and the connections are within one single network.

View solution in original post

Message 4 of 4
Top Contributors
Discussion stats
  • 3 replies
  • 626 views
  • 2 kudos
  • 2 in conversation
Announcements