Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have a scenerio were I need to limit some machines from other machines on the network for security reasons. Our current configuration has a layer 2 managed switch that provides connectivity for all of the workstations. I have created 2 VLANs on this switch so that the machines can't see each other. What I am trying to do is create a linux filtering bridge with VLAN Support. I got the bridging working between 2 NICs and am using ebtables to provide MAC address based filtering to allow one group access to all network resources and the other group access to only a few network resources. The problem is that I can't seem to get this working with 802.1q VLAN tagging.
The port on the switch that the linux bridge is connected to is sending tagged traffic for both VLAN 1 and VLAN 2 but for some reason I can't get the traffic to bridge. I used vconfig to add VLAN 1 and 2 to interface eth1 before bringing the interface to no avail. I also tried adding VLAN 1 and 2 to the bridge interface that I created which also did not work.
I guess what I am really looking for at this point is a way to take incoming 802.1Q traffic from the managed switch and dump it out on the unmanged network seqment (it contains test lab machines as well as the DHCP and local DNS server) as normal traffic while dropping attempts from the secured VLAN to access network resource they shouldn't have access to (they should have access to the DNS/DHCP server and one fileserver, the other group needs access to all of these plus all lab test machines).
Any suggestions would be greatly appreciated, since maybe I am going about this all wrong to begin with.
Shelby
Last edited by whirlpool78; 02-18-2005 at 09:47 AM.
When configuring vlan, the usual way is to address 2 differnet vlan in 2 different subnet.
Thus, you can't use a bridge to interconnect 2 vlan, you need a router (that's a layer 3 job).
I think you should :
On the switch : configure the interface to the linux box as a trunk for your 2 vlans
On the linux box :
Thus vlan1 (192.168.1.0/24) has full access to 192.168.3.0/24
vlan2 (192.168.1.0/24) can only access to 192.168.3.80
vlan1 and vlan2 cannot communicate
Don't forget to configure the different IPs of the linux box as the gateway for different machines...
I was actually afraid that was going to be the answer. I will just need to re-evaluate how I hand out IP addresses. This was one reason why I was hoping I could use a bridge.
My idea was that with a bridge the VLANS could continue to use the current DHCP configuration and the test network would appear like one big happy network from the view point of machines in the lab. Obviously from the view of workstations in the secured VLANs the view would be much different. Of course the problem becomes one of how does a bridge know which VLAN to drop incoming traffic into if the machines have IPs in each VLAN have IPs in the same range.
Currently we are using a network wide DHCP with 192.168.128.x with a mask of 255.255.248.0 mainly because the mask matches the IP setup that our IT department is using for production and they wanted us useing a predefined IP range. I can easilly split this range up into smaller subnets assuming that I can somehow come up with a method of handing out DHCP addresses to the different VLANs. Would there be a way to bind a DHCP Server to eth0.1 and eth0.2 handing out different IP ranges? I also need to make certain that absolutely no DHCP requests are answered on interface eth1 (this is the corporate production network and IT would have a fit if a rogue DHCP Server started answering IP requests).
I understand you would have prefered keeping a bridge config, but as you said, I'm not sure you can set a trunk interface in a bridge...
Quote:
the problem becomes one of how does a bridge know which VLAN to drop incoming traffic into if the machines have IPs in each VLAN have IPs in the same range
As a theorical problem, if the bridge members are eth0.1, eth0.2 and eth1, then the bridge instance should be able to differentiate mac address from any interface. As I never used vlan with Linux (I'm working with Cisco boxes), I just don't know how this is implemented...
As for the dhcp configuration, if it is run on the linux box, it will work quite easily : on the dhcpd.conf file, you _have_ to specify a subnet per IP defined on your machine. The IP given in the dhcp response depends on the IP of the interface from where the dhcp request came... so all should be well. If you've got problem concerning this, I've got a dhcpd.conf file with support for 3 different subnets (one with range address, one with "manual dhcp", and one with no address given), just ask and I'll mail it.
If the dhcp server is somewhere else, then you've got to route the dhcp requests on your linux box to the dhcp server.
I don't know how it works with Linux, but with Cisco router, the dhcp request is somewhat encapsuled in IP packet, and the dhcp server use the source IP address of this packet so as to know what range of address to choose for the dhcp reply. This is not Cisco proprietary, since it works with any kind of dhcp server.
If anybody's got some precisions on how this works, I'm intersted...
For all that may be interested, I was able to get my bridging working though I haven't finalized the filtering yet but for comepleteness I have included the script I have thus far here:
Code:
#Add the VLANs to the NIC
vconfig add eth0 1
vconfig add eth0 2
#Turn on ethernet header reording.
#I don't know if I need this but better safe than sorry and for the limited number of users I can take the performance hit
vconfig set_flag eth0.1 1 1
vconfig set_flag eth0.2 1 1
#turn the interfaces into promisc mode to see all traffic on the interface for bridging
ifconfig eth0 0.0.0.0 promisc
ifconfig eth0.1 0.0.0.0 promisc
ifconfig eth0.2 0.0.0.0 promisc
ifconfig eth1 0.0.0.0 promisc
#create the bridge
brctl addbr mybridge
#Add interfaces to the bridge
brctl addif mybridge eth1
brctl addif mybridge eth0.1
brctl addif mybridge eth0.2
#Bring the bridge interface up
ifconfig mybridge up
#Assing an IP to the bridge, this is mainly so that I can SSH into it to tweak settings
ifconfig mybridge 192.168.128.100 netmask 255.255.248.0
#Set up the default gateway
route add default gw 192.168.130.1
#Now define filtering rules
#I was using ebtables to do mac level filtering but since I get 2 virtual interfaces with the VLANs I can use iptables
#Don't allow the 2 VLANs to talk to each other
iptables -A INPUT -i eth0.2 -o eth0.1 -j DROP
iptables -A INPUT -i eth0.1 -o eth0.2 -j DROP
#Allow general lab traffic down the links regardless where it is headed
iptables -A INPUT -i eth1 -j ACCEPT
#Allow the Developers and QA access to whatever they want
iptables -A INPUT -i eth0.1 -o eth1 -j ACCEPT
#Limit Docs and Tech Support access to specific machines
iptables -A INPUT -i eth0.2 -o eth1 -d 192.168.130.1 -j ACCEPT #Router Access
iptables -A INPUT -i eth0.2 -o eth1 -d 192.168.130.2 -j ACCEPT #DNS/DHCP
iptables -A INPUT -i eth0.2 -o eth1 -d 192.168.129.1 -j ACCEPT #Build File Server
#Allow DHCP requests and ARP
iptables -A INPUT -i eth0.2 -o eth1 -d 255.255.255.255 -j ACCEPT #Allow broadcasts
iptables -A INPUT -i eth0.2 -o eth1 -d 192.168.135.255 -j ACCEPT #Allow subnet broadcasts
#Deny anything not previously defined
iptables -A INPUT -j DROP
I haven't completely tested all setups of this scenerio but it is working so far. My basic goal was to add some level of complexity to the ease in which our Docs people and Tech Support people can get access to our Developers machines or test machines in our QA lab. This seems to be working on a test basis but obviously VLANs are not a foolproof security tool so if a machine can get the MAC address of a different machine on a different VLAN, the switch itself may allow direct access thus the bridge filter rules wouldn't even come into play. I try to limit this by only allowing ARP requests (via broadcast) into a network segment were all traffic must flow through the bridge.
I think you've got a problem with your iptables rules :
they should be in the FORWARD chainand not in the INPUT. The INPUT chain controls what goes in your machine, whereas the FORWARD controls what gets through.
Since the default behaviour of forward must be ACCEPT, your config seems to work, but you're not filtering what you thought.
Thus in the ACCEPT chain, you just need a few things, like ssh, dhcp and the few protocols you're using for administration.
On the contrary, in the FORWARD chain you need to sepcify all packets going from a lan to the other.
Two more things : you must authorise traffic in both directions so that it works (-i eth0 -o eth1 and -i eth1 -o eth0). If you want only eth0 to talk to eth1, you can use :
iptables -A FORWARD -i eth0 -o eth1 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED -j ACCEPT
Oh yeah, thanks looks like i pasted the wrong file. I had tried it with the the INPUT chain originally and that didin't the way I wanted it to so I moved to using the FORWARD chain. I just checked and the file I had been editing on my workstation was still that old file, I guess that is what I get for editing the same file on 2 different boxes :-D . I will update the previous message to reflect my real configuration. I'm really glad you said something because I would hate to for someone to find this thread and try what is in the code just to have it not work.
Shanks for the heads up on the ESTABLISHED state setting I was wondering why things didn't seem to be coming together exactly as I had liked.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.