Archive for the ‘VLAN’ tag

Reaching multiple instances of the same IP address  

Posted at 7:01 pm in Uncategorized

A friend recently presented me with the following challenge: Configure a system through which several appliances, all of them having an identical, non-routable, default IP configuration, can be reached simultaneously. All appliances are preconfigured with an IP address of and they had no routing configuration enabled. Yet they should all be reachable over the Internet. The diagram below shows the basic infrastructure.

For the server (the nice grey cabinet to the left) to reach all those systems at the same time, a VLAN setup was required, so we set up a VLAN trunk to a nearby switch. Then the different appliances were connected to different un-tagged switch ports in dedicated VLANs – the first appliance was connected to a switch port in VLAN 10, the next to a switch port in VLAN 11, etc. Corresponding VLAN interfaces were configured on the server, and a local IP address was configured on each. To keep a minimum level of sanity, I configured the VLAN interface on vlan10 as, while vlan11 got, etc. To avoid too much confusion on the switch, I also set the MAC address on each VLAN interface to distinct values.

Next step was to configure correct IP routing using iproute2:
# VLAN 10
/sbin/ip link add link eth1 name eth1.10 type vlan id 10
/sbin/ip link set dev eth1.10 down
/sbin/ip link set dev eth1.10 address 00:04:de:ad:be:10
/sbin/ip link set dev eth1.10 up
/sbin/ip addr add local brd dev eth1.10
/sbin/ip route add dev eth1.10 proto kernel scope link src table 10
/sbin/ip rule add from lookup 10 prio 1010
# VLAN 11
/sbin/ip link add link eth1 name eth1.11 type vlan id 11
/sbin/ip link set dev eth1.11 down
/sbin/ip link set dev eth1.11 address 00:04:de:ad:be:11
/sbin/ip link set dev eth1.11 up
/sbin/ip addr add local brd dev eth1.11
/sbin/ip route add dev eth1.11 proto kernel scope link src table 11
/sbin/ip rule add from lookup 11 prio 1011

At this point I could reach the different appliances from the different source IPs:
# ping -I -c1
PING ( from : 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=0.119 ms

Snooping with tcpdump on the different VLAN interfaces, also showing the MAC addresses, confirmed that the pings were reaching the correct appliance.

Then I set up corresponding IP addresses on the outside interface (eth0). The address matches the device in VLAN 10, matches VLAN 11 and so on. The outside IP addresses are official IP addresses, but I’ve changed them to protect the innocent.

/sbin/ip addr add local dev eth0
/sbin/ip rule add to fwmark 10 table 10
/sbin/ip rule add fwmark 10 lookup 10
/sbin/ip addr add local dev eth0
/sbin/ip rule add to fwmark 11 table 11
/sbin/ip rule add fwmark 11 lookup 11

To make sure the packets were being identified correctly all the way through, they were tagged upon reaching the outside interface, based on the IP on which they arrived.

So far so good, now it was time for iptables to show its powers:
# VLAN 10
/sbin/iptables -t mangle -A PREROUTING -i eth0 -d -j MARK --set-mark 10
/sbin/iptables -t nat -A PREROUTING -i eth0 -d -j DNAT --to-destination
/sbin/iptables -A FORWARD -m mark --mark 10 -j ACCEPT
/sbin/iptables -t nat -A POSTROUTING -m mark --mark 10 -j SNAT --to-source
# VLAN 11
/sbin/iptables -t mangle -A PREROUTING -i eth0 -d -j MARK --set-mark 11
/sbin/iptables -t nat -A PREROUTING -i eth0 -d -j DNAT --to-destination
/sbin/iptables -A FORWARD -m mark --mark 11 -j ACCEPT
/sbin/iptables -t nat -A POSTROUTING -m mark --mark 11 -j SNAT --to-source

The above commands maps the outside addresses on eth0 to the corresponding VLANs on the inside. Note that every incoming packet is destination NATed (DNAT) to while they are being source NATed (SNAT) based on the VLAN to which they are mapped. As the appliances were not able to route traffic, all communication had to look like it happened on the local network only.

Now I expected to be able to access each appliance from the outside, but it turned out that only one appliance could be reached. tcpdumping on each VLAN interface confirmed that traffic from the outside reached each appliance, and the appliance responded, but the response never came all the way back. This was rather puzzling as nothing appeared in any log. However, my colleagues reminded me about rp_filter, which dropped weird traffic without logging anything. Thus, the key that unlocked everything was this:
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1.10/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1.11/rp_filter

And voila – from the outside world, we were able to reach every single appliance on the inside, all with the same unroutable RFC1918 address.

Written by bjorn on February 24th, 2011

Tagged with , , , , ,

VLAN woes  

Posted at 5:30 pm in Uncategorized

I’ve been planning to do this for a long time and now I’m finally there. My home network now consists of two virtual host servers (one Xen and one KVM) and a firewall between them, all nodes understanding VLANs. On top of this, add a small but powerful Linksys switch and a Linksys wireless access point running OpenWRT Kamikaze 8.09 (RC1). Among other things, this setup should facilitate testing Munin and other stuff without breaking the current functionality too much.

I got great help from this article on tweaking VLANs on the Xen host, and this article on VLANs with kvm. Thanks!

Written by bjorn on January 9th, 2009

Tagged with , , , ,