I have a similar switch. Can you post a screen capture of the VLAN config on the switch. It's not obvious from the Netgear instructions that the port going to the Untangle needs to be Untagged.
Printable View
I have a similar switch. Can you post a screen capture of the VLAN config on the switch. It's not obvious from the Netgear instructions that the port going to the Untangle needs to be Untagged.
Yeah... China knock off mode VLANs, everything is backwards. PVID is the tag on the frames as they leave a port, and TRUNC ports are often not TRUNC'd but instead made a member of every VLAN.
Not what I actually want to do, however I did try the suggestion of turning on NAT on both VLAN's.
The result, no difference..., I can still access devices on the 192.168.10.x network from either VLAN 192.168.20.x and 192.168.30.x, really don't understand whats going on now....
I would look closer at what you're testing against, because Windows firewall and the like will disable non-local subnet access. A software firewall on either VLAN member you're testing against could cause this.
Have you tried testing against the IP address Untangle has on the afflicted VLAN's ip network?
OK, I think this is wrong, i.e. The port going to Untangle has to be tagged.Quote:
Originally Posted by jcoffin
This is my understanding of what tagged and untagged ports do, as well as port PVID assignments.
If a port is UNTAGGED and is a member of a VLAN then tagged traffic which is routed over that port its untagged before forwarding. i.e. If the switch receives tagged traffic for the VLAN of which it is a member, it will untag the packets before routing them on. These will be the ports on the switch connected to devices which DO NOT understand 802.1Q tagging.
When traffic is received on an untagged port such as this i.e. from devices which do not understand tagging, then a tag must be added to this incoming traffic. This is done by assigning a PVID to the port which will be the number of the VLAN of which it is a member.
If a port is TAGGED and is a member of a VLAN then tagged traffic which is routed over this port is unaltered. These will be ports on the switch connected to devices which DO understand tagging and what to do with it.
So, take my very simple network :
1) Nothing understands tagging apart from the Switch and Untangle
2) Therefor the TRUNK port connected from the Switch to Untangle needs to be TAGGED for the additional VLANS, otherwise the tags would be stripped off by the switch and Untangle would think they were from the main untagged LAN
3) Any ports not connected to Untangle need to be UNTAGGED because those devices do not understand tagging.
4) Any untagged VLAN ports need a PVID assignment so that traffic they receive can be tagged with the appropiate VLAN ID before being routed to untangle.
These are what I believe to be some misconceptions (some of which I had when I started this process)
1) Tagged ports add the tag of the VLAN they are members to traffic they receive. This is not the case. If the port is Tagged it means it will not alter any tags it sees.
2) Untagged ports don't do anything. This is not the case. Untagged ports will remove tags from traffic before forwarding.
[Bracing for Flames] Like I said at the start, this is my understanding of how this all words, and I am more than happy to be corrected.
PS. As an experiment I did try all possible combinations of tagged and untagged ports with the only effect being to stop everything working with particular arrangements of ports consistent with what I described above.
You won't get any flames from me, because to be honest all of this goes up in smoke as soon as you change vendors. In my experience there is Cisco, and other large vendors way of doing things... and then there's the China junk way, which is on all of the less expensive equipment. The latter is backwards... but typically if you have something configured incorrectly layer 2 doesn't work, so layer 3 doesn't work. This doesn't create a unidirectional communications problem, it's always a bidirectional problem.
Which is why I'm leaning away from the VLAN configuration being your issue. That is, unless you've got something very wrong, which is why you have to walk through each interface one at a time and map where things are going, and make sure things are actually going there.
This is mostly correct. The monkey wrench is your default VLAN1. The default VLAN is always passed through a trunk untagged. So you can set your trunk port to be a tagged or untagged member of VLAN1 and it will still pass as untagged. Because of this I prefer to not use the default VLAN at my house. This way all the traffic going into Untangle is tagged. I even disable the trunk interface into Untangle (yes you can disable the interface and the sub-interfaces which you set the VLANs up on will still work in Untangle).Quote:
Originally Posted by tescophil
But that being said, the way you have described your setup sounds correct. Maybe some screen shots of your Untangle network setup could help out here?
I have a ticket in with support for this, so rather than post endless screen shots of my network config, I think the support team can just login and take a look around....
TAlso, sky-knight, I believe that PVID's are use to tag frames as they enter the port not leave it, eg. traffic coming from a device that does not understand VLAN tagging needs to be tagged when it comes into the port, and not when its going from the port to the device.
Here is how I have my Netgear switch setup. Untangle is connected to to port 1. VLAN device is on port 16.
Attachment 9256
You are correct, but I've had switches use the PVID configuration to determine the default tag associated with frames leaving the port too. The Cisco standard is to use that setting to determine what VLAN to put untagged traffic on as it enters the port.Quote:
Originally Posted by tescophil
As I said before, some switches are backwards, PVID is in, and VLAN TAG is out.
But again I don't think that's your problem because if layer 2 was goofed up, nothing would work on the misconfigured port.
