Hello,

I am trying to get a home network ridiculously secure for educational purposes. In the past I've seperated a few networks and created virtual interfaces on the internal eth0 network, I now have eth0, eth0:1 and eth0:2. These have clients with different subnets on it, 192.168.0.0/24 1.0/24 and 2.0/24. Now I have this cheap wifi accesspoint that supports vlan and multiple ssid and I'd like to make use of that to be able to isolate the traffic on the "guest" network so it can only reach the server and then on the server be able to control the traffic with iptables.

the network looks like:
Internet-----server----switch----accesspoint----trusted devices
-computer1 -guest devices
-computer2

Because the debian 6 server is able to cope with vlan tagged packets and because the accesspoint supports this I'd like to mix vlan tagged and untagged packets, this way my trusted computer1 is seperated from the guests not only by IP.

What I'd like to know is if it's possible to use both kinds of traffic on the unmanaged switch that doesn't support vlan tagging.

And if I'm right about the theory, would anyone on the guest wifi network be able to sniff any traffic from the trusted network if the trusted network is not tagged? I don't mind the trusted network being able to mess things up, therefore it's trusted.

thnx, Steven

If the switch is just dumb, then it will not see the 802.1q data in the tagged traffic, so it will be switched as if it were normal traffic, on MAC addresses as usual.

The traffic is no more or less sniffable than untagged data. It will be sent down that cable if the MAC address in the destination header in the frame is believed to be on the other end of it, tag or no tag. With a tagged switch that port will simply not be able to be used for the tagged traffic if not configured to be able to do so.

so I can just combine the traffic and make the debian side of this accept both untagged and tagged traffic?
the switch is a dumb gb switch, I also have a cisco 2950 that supports vlans to play with but it's only 100 mb and that is too much of a performance impact.
so I can just:
but then I think I'd have a conflict with the guests on the wired network that are now seperated from the rest by just an ipaddres and a static dhcp lease.

Your switches *SHOULD* be 802.1q capable, but in reality it doesn't matter when it comes to getting traffic through the device. If you have two tag aware servers connected to it, they can talk on a tagged interfaces as much as they can on an untagged one.

I'm not clear what this conflict is though, what's not making sense?

I want the 192.168.2.0/24 network to be usable on both the untagged interface and on the tagged interface for now.
this means dhcp should work on both.

And I really don't want to spend 100 euro on replacing a switch for one that supports vlan tagging so I can seperate the 2 wifi ssid's and to learn something about vlans.

OK, so if a DHCP request is broadcast without a tag when it hits the DHCP server from wifi, but is tagged if it came from a wired client on its eth0.2 interface, for example, then they would need to be received on the server by different interfaces, logical or physical. You're clearly getting a bit mucky in terms of proper design and happy accidents / hacks here. I have looked to do slightly similar things, and found that whilst the machine could receive easily enough on eth0 and eth0.2, however as they will have come to the same MAC address on the NIC, it can't intelligently know how to send a response back, probably always sending it out on eth0 only. You *MIGHT* have success if you were to add a physical NIC, and then bridge the eth0.2 to eth1 (eg) and put your 2 subnet address on the resulting br0 interface. Leaves a pretty bad taste though.