This is one super long post, but then knowing me and my minutely-detailed-posts, this shouldn’t come as a surprise.
I recently was asked to re-look at the Internet infrastructure of my condo estate and see how we could update it for fibre without too much costs. It was about 11 years old, making use of old 100BaseT equipment and still using an ADSL uplink, a real pain considering everyone was now on fibre. We had 5 wireless units around the estate, 2 user PCs and a network printer in the management office, a web server and 2 video cam servers to be fed from a single uplink. Now all these devices were already on their own internal vLANs on the old setup which I had put in place some time ago and there was absolutely nothing wrong with the internal setup. All we wanted at this point was to swap the ADSL uplink for a fibre uplink. The issue was that everything was configured through an extremely outdated 3Com core switch and with the new fibre setup, there was no replacement for this, neither was there any technical assistance rendered – all part of keeping things on the cheap (including asking me to design and set things up for free). Basically I wanted this:
Now the ONT and router were provided of course by the ISP, but we had no core switch, neither did we want to spend a couple of thousand on one. So the dilemma was how to get the functionality of a high end switch without spending that kind of money? Answer – don’t. Get a SOHO Layer 3 switch (your typical home cable router) which can be run with some of the more awesome 3rd party firmware like DD-WRT or OpenWRT and get all the functionality you need at a fraction of the price. The functionality I needed was pretty basic, One-To-One Network Address Translation (NAT), Virtual LAN (vLAN) support (didn’t need tagging) and a DHCP server. Now I had a bevy of choices, Tomato, DD-WRT or OpenWRT to name a few and I went with OpenWRT. I’m not a fan of Tomato’s UI and neither was I fond of the haughty attitudes of the DD-WRT developers and also since I had been a user of OpenWRT from it early implementations, I decided to stick with it.
So just a little education first – what exactly was the functionality I mentioned? I’m sure you’re all familiar enough with a DHCP server, thats what dishes out IP addresses automatically to the clients that connect to the network. What about One-To-One NAT and vLAN support and what is tagging (even though it wasn’t needed)?
Firstly, One-To-One NAT is mapping multiple public IPs to multiple private IPs. The common NAT that most of you folks do at home, is to map your public IP address and a port number to a private IP address and a port number. The reason you use port numbers is because you only have 1 public IP address and using different ports are a good way to share that 1 public IP with a host of services you want to run (which obviously run on different ports). When you have a couple of public IPs, you can afford to map the entire public IP to an entire private IP including all its ports. So for example, If I had public IP addresses, eg: 136.130.20.11 – 136.130.20.15 (5 public IPs) I could map each one of those addresses to machines on my private IP range:
136.130.20.11 -> 172.28.1.11
136.130.20.12 -> 172.28.2.12
136.130.20.13 -> 172.28.3.13
136.130.20.14 -> 172.28.9.14
136.130.20.15 -> 172.28.9.15
And when I access the public IP, say 136.130.20.12, it would route all traffic to my machine on my private network with the private IP, in this case, 172.28.2.12.
Now onto vLANs. The vLAN is a virtual LAN. It is a means of segregating a network into distinct network groups, separate of each other without using a physical switch/router. So with 1 switch, you could create a few vLANs and depending on how you configure things, they may or may not be able to see each other and pass data between each other.
If its tagged, it means all data passing through will be tagged with the vLAN’s id. Tagging is primarily used to pass vLAN data across different network devices in more complexed network setups, where, the (for example) the Human Resource vLAN may span different floors and offices and data would have to pass through several edge switches through which data from other vLANs also pass through. The tagging is a means of identifying the data so that it knows how to pass from switch to switch such that (for example) all the machines in the Human Resource vLAN can see and talk to each other.
Again as with my hotspot posts, I’m not going to detail installing OpenWRT, there are tonnes of guides out there and its really not rocket science.
Setting Up vLANs
Now there is already a vLAN setup going with the router, the hardware basically creates 2 vLANs, vLAN 1 for your internal LAN data and vLAN 2 for your WAN data (as far as OpenWRT is concerned anyway). These vLANs are tagged so the processor knows which packets belong to which network (LAN or WAN) and hence how to pass the data. Typically for a 4 port router its this:
What we are going to be doing is essentially adding to these vLANs. Also instead of having all (usually) 4 of your LAN ports on vLAN 1, we isolate the ports for different vLANs. So for example, I could have one vLAN for staff machines on port 1 (via a switch), another vLAN for video cameras on ports 2 and 3 and a third vLAN for wireless APs on port 4.
Open up your OpenWRT web UI, click on the ‘Network’ tab, then select the ‘Switch’ tab. You’ll see a graphic representation of the ports on your router. Don’t worry if you see more ports than your router actually has, some versions of OpenWRT don’t pick up the right number of ports. ‘Port 0’ is your WAN Port and ‘Port 1’ is the first of your LAN ports – work your way up from 1 with the number of ports your router has. The last port (CPU Port) is an internal port (not visible on the router) that links back to the processor. As shown in the figure above, its labelled as Port 5. If you had 8 LAN ports it would be Port 9 and so on. For any of the vLANs, this CPU port must be set as ‘tagged’ so the data is embedded with the vLAN id and hence the processor knows which vLAN the data passing through these ports belongs to.
For this post, the router in question is a 4 port router, so the LAN ports we will be looking at are ‘Port 1’ to ‘Port 4’.
You will notice at the start, under vLAN 1, ‘Port 1’ to ‘Port 4’ are all set as ‘untagged’, meaning they belong to the same vLAN and that data is not being tagged as it passes through them. We are going to:
– create 3 new vLANs (vLAN 102, vLAN 103 and vLAN 109)
– assign ‘Port 1’ to vLAN 102
– assign ‘Port 2’ and ‘Port 3’ to vLAN 103
– assign ‘Port 4’ to vLAN 109
– deassign all the LAN ports from vLAN 1
Operationally, this means:
– Click the ‘Add’ button and create 3 new vLANs vLAN 102, vLAN 103 and vLAN 109
– Under vLAN102 set ‘Port 1’ to ‘untagged’
– Under vLAN103 set ‘Port 2’ and ‘Port 3’ to ‘untagged’
– Under vLAN109 set ‘Port 4’ to ‘untagged’
– Change all the ‘untagged’ to ‘off’ for vLAN 1
‘Port 0’ will remain as ‘untagged’ on vLAN 2.
So looking at the above, you can see that I am actually keeping vLAN 1, but not assigning any ports to it. Fact is, the router’s LAN IP (typically 192.168.0.1 or 192.168.1.1, but in my estate’s setup 172.28.1.1) is on vLAN1 and, if you’re using a wireless router (which you most likely are), the wireless DHCP range will be on vLAN 1, so you should NOT reassign or delete vLAN1. In other words, even though there are no ports assigned to it, the router itself is still making use of vLAN 1.
Once you click ‘Save & Apply’ and if you are on a wire connected to any of the LAN ports, you’ll find yourself kicked off the network and without an IP address (we took all the ports of vLAN 1 remember?) The router’s DHCP service is only configured by default for vLAN 1. No ports assigned, means no IPs dished out. If you’re connected to the router via the wireless, then you’re ok (wireless is on vLAN 1 so you’ll still get an IP if you’re on wireless). For this reason, I suggest you configure the vLANs one by one, setting each one up individually then repeating the process for the remaining vLANs that you want setup, or at least leaving ONE port still on vLAN 1 for you to remain connected.
Assuming you’re still connected after the ‘Save & Apply’, if you go to the OpenWRT web UI, click on the ‘Network’ tab, then select the ‘Interface’ tab, you’ll see the virtual interfaces for each of the vLANs you created, on top of the default virtual interfaces for vLAN 1 (labled ‘LAN’) and vLAN 2 (labled ‘WAN’).
Now to configure the network, subnet, DHCP for the individual vLANs created. Firstly click on the ‘Edit’ button under the ‘Actions’ column of the vLAN to be configured. Now since each interface is going to act as the gateway for the vLAN, choose ‘Static address’ as the ‘Protocol’. Fill up the IPv4 information (IP, netmask) – this can be any network class and subnet segregation (I’m using a whole class B network with 256 IPs). Then select the gateway address, which will be the LAN address of the router, (in this case 172.28.1.1). To understand why this is so, you have to understand that your router is ultimately the one thats processing all the data and telling it how to go out to the internet/intranet and come back with whatever you want. So each vLAN interface will have to pass its data through the actual router (hence why you use its IP as your gateway).
After everything is configured for that particular vLAN, you’ll have something like this:
Next go to the ‘Firewall Settings’ tab and make sure the firewall zone is set for the vLANs as below.
This implies that all the vLANs will be able to see each other and communicate with each other. If you want complete vLAN isolation (where the vLANs have absolutely no communication between them), it can be set up under the custom firewall rules later.
Next we set up the DHCP service for the vLAN. Under the ‘DHCP Server’, ‘General Setup’ tab, make sure ‘Ignore interface’ is not checked. Set the starting IP and the number of IPs and the leastime for the IP (accept the defaults unless you have some special requirements). Under the ‘Advanced Settings’ tab, ensure ‘Dynamic DHCP’ is checked, then click on ‘Save & Apply’.
Now repeat the above for remaining vLANs created, using different IP ranges (for the case of my estate setup, 172.28.3.1/24 for vLAN 103 and 172.28.9.1/24 for vLAN 109).
This last step is optional. I did mention about adding vLAN isolation via the custom firewall rules. You can do this by going to the ‘Firewall’ tab and selecting ‘Custom Rules’, then add the following into the text area and click ‘Submit’:
iptables -I FORWARD -i vlan+ -o vlan+ -j DROP iptables -I FORWARD -i vlan+ -o vlan1 -j ACCEPT iptables -I FORWARD -i vlan1 -o vlan+ -j ACCEPT
This basically tells the firewall to drop any packets from any of the created vLANs that are trying to reach each other (first line) effectively killing all communications between the vLANs and achieving vLAN isolation. It then tells the firewall to allow any packets from the other vLANs to vLAN 1 (second line) or from vLAN1 (third line) to any of the other vLANs. This is to ensure data can go out from the router and come back in – remember, the router is the gateway for all the vLANs.
And thats that for the vLAN setup. If everything was done properly, you can plug in your laptop with the wire to each of the ports and see that it gets IP addresses on the IP ranges you specified. Plug in two machines to check the vLAN isolation – you shouldn’t be able to ping either machine from the other. Lastly check to see that your machines have internet access.
Configuring One-To-One NAT
This is relative simple, considering its all cutting and pasting of network config commands and firewall rules.
To assign an IP address to the WAN interface, you simple issue an ‘ifconfig’ command for that interface.
ifconfig <interface> <IP> <subnet mask> broadcast <broadcast address>
If you look at your ‘Interfaces’ tab under ‘Network’, you can see that your WAN interface is designated ‘eth0.2’. You can actually get this information by issuing the following command at a command line for the router (if you’ve enabled SSH – Google it if you don’t know how to):
/sbin/uci -p/var/state get network.wan.ifname
That will also return you ‘eth0.2’. So to assign an IP address of say 136.130.20.11 (for example with netmask 255.255.255.0, broadcast 136.130.20.0) to the WAN interface do:
ifconfig eth0.2 136.130.20.11 255.255.255.0 broadcast 136.1130.20.0
If you have multiple IPs to assign to the WAN interface you do:
ifconfig eth0.2:1 136.130.20.11 255.255.255.0 broadcast 136.130.20.0 ifconfig eth0.2:2 136.130.20.12 255.255.255.0 broadcast 136.130.20.0 ifconfig eth0.2:3 136.130.20.13 255.255.255.0 broadcast 136.130.20.0 ifconfig eth0.2:4 136.130.20.14 255.255.255.0 broadcast 136.130.20.0 ifconfig eth0.2:5 136.130.20.15 255.255.255.0 broadcast 136.130.20.0
This is called ‘plumbing the interface’ (like branching pipes from a main pipe, hence the ‘plumb’ reference). You can put this into a shell script format and add it to the router’s local start up section so that it runs at every boot. Click on ‘System’ and select the ‘Startup’ tab and scroll to the ‘Local Startup’ section at the bottom and add the following into the text area and click ‘Submit’:
IFNUM=0 STARTOCT=11 ENDOCT=15 WANSFX="136.130.20" NETMSK="255.255.255.0" BRDCST="136.130.20.0" WANIF=`/sbin/uci -p/var/state get network.wan.ifname` for i in `seq $STARTOCT $ENDOCT` do IFNUM=`expr $IFNUM + 1` ifconfig $WANIF:$IFNUM $WANSFX.$i $NETMSK broadcast $BRDCST done
This auto detects the WAN interface name (might not always be ‘eth0.2’) and loops through the last octect of the IPs, plumbing the interface with the IPs.
So now your WAN interface will accept all traffic for any of the above addresses. The next part will be to configure the firewall rules to forward the data for the IPs to the right private IPs. Nothing more than adding stuff to the ‘Custom Rules’ under the ‘Firewall’ section again. Copy the following code and alter the WAN IPs and LAN IPs (which the WAN IPs are supposed to point to) for every public to private NAT you have:
iptables -t nat -I PREROUTING -d <PUBLIC-IP> -j DNAT --to <PRIVATE-IP> iptables -t nat -I POSTROUTING -s <PRIVATE IP> -j SNAT --to <PUBLIC-IP> iptables -I FORWARD -d <PRIVATE-IP> -j ACCEPT
This basically routes all packets from the public IP to the private IP (first line) and all packets from the private IP to the public IP (second line) and forwards all TCP/UDP packates for all port numbers of the public IP to the same port number on the private IP (third line). This is kind of a “allow all through” situation. If you want only forward certain ports, then specify the ports to allow. For example, to allow SSH and HTTP traffic, forward only packes for ports 22 and 80:
iptables -I FORWARD -d <PRIVATE-IP> -p tcp --dport 22 -j ACCEPT iptables -I FORWARD -d <PRIVATE-IP> -p tcp --dport 80 -j ACCEPT
A complete working example (the one I gave up top about 136.130.20.12 pointing to 172.28.2.12 via NAT) allowing only SSH and HTTP traffic would be:
# WAN 136.130.20.12 -> LAN 172.28.2.12 iptables -t nat -I PREROUTING -d 136.130.20.12 -j DNAT --to 172.28.2.12 iptables -t nat -I POSTROUTING -s 172.28.2.12 -j SNAT --to 136.130.20.12 iptables -I FORWARD -d 172.28.2.12 -p tcp --dport 22 -j ACCEPT iptables -I FORWARD -d 172.28.2.12 -p tcp --dport 80 -j ACCEPT
Do this for every WAN IP pointing to an private IP and then click ‘Submit’ and after that you should have the translation working fine.
And that folks, is how you do vLANs and One-To-One NAT without spending thousands.
References:
– One-To-One NAT
– vLAN Detached Networks
Comments (0)