Same subnet, but running specific clients through a separate gateway?
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.
Same subnet, but running specific clients through a separate gateway?
I have been given the task of building an "internet kill switch". This is for a single computer lab in a building with many other clients. All computers (lab or otherwise) need complete access to the entire subnet all the time. This means that I can't just hit a power switch for the lab hub. To make matters worse, there is no way to isolate the clients physically from the network at all.
My original idea was to route all traffic through a Linux box. I'd have a mechanism to switch between 2 iptables profiles. One would allow all traffic through (we have another firewall, no need to make this too complex) and one would block all traffic except that going to the local subnet (10.0.0.0/24).
As I can't physically isolate the clients, I was considering just pointing them to this Linux box, and have it act as the internet gateway. But, some people told me that I may have to use something like proxy-arp or bridging to have the route repeat the subnet. Would the fact that their still physically linked fix this? Or do I still have to do something like this. There is only 1 ethernet connection on the machine, because there is only 1 network, so bridging could not work.
Also, you may just recommend I make an IP or MAC based Firewall for the internet itself. Unfortunately, this solution is also not available.
Here is a little diagram:
Current:
Internet --- Network + Lab (10.0.0.0/24)
What I want:
Network (10.0.0.0/24) ----- Lab (10.0.0.0/24)
|_Firewall/Gateway (10.0.0.2)
Not available options:
Internet --- Firewall --- Network / Lab
Internet --- Network --- Firewall --- Lab.
Its a very weird situation, and I can use all the help I can get. Thanks in advance!
~ ATrain.
Ideally you have a seperate vlan which holds that client, you didn't say anything about the switch you're using, but you don't need two nics to do routing, one is fine. if you can, just configure an 802.1q trunk between that box and a suitably intelligent switch. if you can't do vlan's, you can still just put two seperate networks on one nic regardless, e.g. 10.0.0.0/24 and 192.168.0.0/24 and then just route through it, that'd work fine, no need to mess with proxy arps or anythign that messy...
I'm not sure how well these windows boxes will handle being on a separate subnet from the PDC, but I can always give it a try. And no, the switches don't have any useful features.
But the general consensus is that for them to go through the gateway, but to be on the same subnet, I'll need to set up a proxy arp? Any advice into how to go about doing that? Can I just enable the kernel option, or is there any other configuration I have to do as well?
there would be no need for a proxy arp at all. if you set that machines gw to be the linux box then it has no idea where the packets go after that, but you would need to do a nat on the linux box to retain some form of sanity.
"there would be no need for a proxy arp at all. if you set that machines gw to be the linux box then it has no idea where the packets go after that, but you would need to do a nat on the linux box to retain some form of sanity."
Assuming I just set them to gw, without nat, what would happen exactly? would data still get through, in both directions? When you say that they it has no idea where the packets go after that, what do you mean by that exactly?
Also, is there any alternative solutions that would work well and be easier to implement than this. I might be able to get off with just pointing all the lab computers to this for dns, because I doubt many of the users will memorize Google's ip :P
without a nat you would have asymmetric routing. outbound data would go via the gateway but as it would still have a source address on the local network, the responses would go directly to the box from the real gateway. This isn't *great* design, but asymmetric routing isn't that bad, and very very common in more complex internet routing environments. It's only if you go through a stateful device, e.g. a firewall, would you come unstuck, as it'd only se half a conversation and complain.
That should be fine. I don't think blocking incoming traffic is to important, once they cant send data out it should be fine. The clients are plugged into a dumb switch, I don't think it will care how the data is being routed.
well you wouldn't really want iptables at all. either the box routes or it doesn't, so if you just send an "echo 0 > /proc/sys/net/ipv4/ip_forward" then it will stop routing anything instantly. you cuold do it with iptables if you wanted, but wouldn't actually be needed.
I do want to iptables. It still has to route local network traffic when internet is disabled. Thats why "iptables -A FORWARD -d 10.0.0.0/255 -j ALLOW" is there. Otherwise, all traffic would be stopped, and that doesn't help.
Well, I thought that if you set the default gateway, then all traffic should be routed through that if possible. If traffic was coming in from other locations, it would be accepted, but for requests out of the network, it would try this gateway before the default router.
BTW: The client computers in this case are Windows boxes, I don't know if that makes a difference or not. I've never monkeyed with this kind of stuff back when I was a windows user 3.5 years ago. But they only have 1 field for gateway.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.