0

I have a VLAN setup through a switch to act as a trunk. Sending tagged VLAN packets to their respective ports as untagged. On these are various devices that all require the same IP on the same subnet - 192.168.1.1/24. On the Linux host I have all the VLAN interfaces setup, and assigning an IP in the same subnet for each one of those will result in having access to 192.168.1.1 one at a time. So I know the connection at this point works.

What I need to do now is have a way to communicate with these devices on the different VLANs at the same time without changing the IP scheme of the devices. What would be ideal is to have something like 192.168.110.1 traffic go to 192.168.1.1 over VLAN 110, 192.168.120.1 to 192.168.1.1 over VLAN 120, and so on. How would I go about creating this scenario, or is it even possible without having some interim layer 3 device between the two points?

My initial thinking was that I would need a virtual interface to act as the "LAN" client, letting the VLAN interface act as a "gateway", and then just forward ports after that point. It just seems it should be less complicated than that.

(Note: This would be a closed private network with no external access whatsoever. Security doesn't need to exist, the paths just need to work.)

2 Answers 2

2

Unfortunately, it does seem like a VM is the only thing, which is okay. I have decided to use X forwarding and basically run a small VM just to isolate the network from the host machine. Works wonders, and there's not much performance lost with Linux KVM or even Virtual Box. Good times.

0

If I understand correct, you want to plug in multiple devices with the exact same IP (example: 192.168.1.1/24) into different VLANs so that you can manage them without having to change IP addresses. I am also going to assume that you want to use the Linux host to manage the networking tricks, and will use a separate management host as the source for connecting to the 192.168.1.1 machines.

This is a tricky setup since the same IPs are on multiple broadcast domains. However I think it should be possible using iproute2 and policy routing. Each VLAN will need its own route table (defined in /etc/iproute2/rt_tables). Using an overlay as you described is a good idea. For each overlay subnet (eg 192.168.110.1), use an iptables PREROUTING entry in the mangle table to tag the packet with a fwmark.

You might also need to do some ARP filtering with arptables just to make sure no ARP packet goes the wrong way.

Take a look at the the LARTC for some examples. The following commands are based on roughly similiar projects we've done, but I haven't actually tried it. You will need to experiment a bit. This assumes that you want to connect to 192.168.1.1 from another machine and not the Linux "router on a stick" box itself.

# give a useful name to the table number
# max table number is 255.
echo "110 vlan110" >> /etc/iproute2/rt_tables

# disable route path filtering
for i in /proc/sys/net/ipv4/*/rt_tables; do
 echo 0 > $i; done
fi
iptables -t mangle -A PREROUTING -d 192.168.110.0/24 -j MARK --set-mark 1 # set mark
ip rule add fwmark 1 table vlan110 # match on existing mark
ip route add 192.168.1.0/24 dev eth0.110 # force connected network to this interface
iptables -t nat -A PREROUTING -d 192.168.110.0/24 -j DNAT --to 192.168.1.1  # NAT overlay
2
  • You're understanding what I want to do with one exception: the Linux box, itself, is the one that will need the access. Unfortunately I do not get the luxury of having it act as just a router for everything. So I get one Linux box, a managed switch, and the devices on the end. Nothing else. What you're suggesting seems like a good start. I'll play around with it more in the morning and see what I can make work based off this for now. Oct 30, 2011 at 6:24
  • Let me know how it goes, I'm always interested in this kind of thing. I'm not really sure how to do these tricks originating from the same host doing the NAT. Logically, the PREROUTING rules still stay the same in the mangle, but I'm not sure if the NAT trick will work. What I would maybe do is look at running a virtual server (eg OpenVZ container or KVM) with bridging, to help simplify the routing. If the info I provided was useful, please vote/score accordingly :-) Nov 1, 2011 at 18:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .