tomato Configuring Tomato for stopping leaks/policy routing/port forwards

[PsychoWolf 16]

Step 1:

First configure the Tomato VPN client (I am using Shibby's AIO build 134, but any of the recent VPN builds that have policy based routing included should work) so that all traffic is sent through the VPN and ensure that works. Once that is working, you can continue. Getting that working is outside the scope of this guide, and a good guide can be found here.

 

Step 2:

On the 'Advanced' tab of the VPN client, check the Ignore Redirect Gateway (route-nopull) option and on the Routing Policy tab, check the Redirect Through VPN option, and add the devices you want to redirect through the VPN. In my case, I added Source IP 192.168.1.120, as this is the only client on my LAN I want to be routed through the VPN.

 

Once that's done, ensure the VPN client is running and see if you have internet access through the tunnel for the specified client. I use ipleak.net to test. You will likely notice that while your IP address is that of the VPN, DNS is still being served by whichever DNS servers your router has configured. This is normal, and is solved in step 3.

 

Step 3:

On the Advanced -> DHCP/DNS tab, in the advanced configuration:

# Create a tag for clients to use a specific DNS server
dhcp-option=tag:vpn,option:dns-server,10.30.0.1

# Tell these clients when they connect to use the VPN tag
dhcp-host=XX:XX:XX:XX:XX:XX,set:vpn,hostnameyouwanttouse,192.168.1.120

The XX:XX:XX:XX:XX:XX above is the MAC address of your device's network interface. You can find this easily on the Status -> Device List tab. This line is essentially assigning static DHCP for the client with the MAC address specified.

 

This tells all clients tagged as 'vpn' to use 10.30.0.1 as their DNS server. Disconnect your client that you wish to route through the VPN and reconnect it so that it renews the DHCP lease. You may also need to flush the DNS on the client. On Windows this is done from a command prompt run as administrator and typing:

ipconfig /flushdns

Note: I am connecting to air on port 2018 to make QoS rules easier, so that's why you see 10.30.0.1 for the DNS server. Use whichever Air DNS server is appropriate for your connection.

 

Step 4:

Now, in Administration -> Scripts -> Firewall add the following:

iptables -t nat -I PREROUTING -i br0 -s 192.168.1.120 -p udp --dport 53 -j DNAT --to 10.30.0.1
iptables -t nat -I PREROUTING -i br0 -s 192.168.1.120 -p tcp --dport 53 -j DNAT --to 10.30.0.1

iptables -I FORWARD ! -o tun11 -s 192.168.1.120 -j DROP

The first two lines prevent the specified client from specifying their own DNS servers, so if this is an issue for you, these rules will make sure the client always uses Air's DNS server. The third line prevents ANY traffic from that client using anything other than the VPN interface "tun11".

 

Note: tun11 is the interface Tomato creates for VPN Client 1. If you use VPN Client 2 use tun12 instead.

 

Routing an entire bridge:

To take this a step further I also created an entire bridge (br1) on a different subnet (172.16.0.1/24), and a virtual wireless network on that bridge that 100% uses the VPN tunnel. The rules for an entire subnet are a little different. Configuring additional bridges and virtual wireless access points in Tomato is outside the scope of this guide.

 

Again, in the VPN Client Policy Routing tab, add the "Source IP" and enter 172.16.0.0/24, then in Advanced -> DHCP/DNS:

dhcp-option=tag:br1,option:dns-server,10.30.0.1

This tells all clients that connect to br1 to use 10.30.0.1 as their DNS server. Tomato, by default, tags the clients with the bridge they are connected to, so that's all that is required to tell clients on that bridge to use a different DNS server.

 

Then in the Firewall:

iptables -t nat -I PREROUTING -i br1 -p udp --dport 53 -j DNAT --to 10.30.0.1
iptables -t nat -I PREROUTING -i br1 -p tcp --dport 53 -j DNAT --to 10.30.0.1
iptables -t nat -I POSTROUTING -s 172.16.0.1/255.255.255.0 -o tun11 -j MASQUERADE
iptables -I FORWARD -i br1 -o tun11 -j ACCEPT
iptables -I FORWARD -i tun11 -o br1 -j ACCEPT
iptables -I FORWARD ! -o tun11 -s 172.16.0.1/255.255.255.0 -j DROP

Again, the first two lines prevent clients from specifying their own DNS servers. The next three lines are required, as Tomato's VPN client doesn't automatically add them for bridges other than br0. Without these, no traffic will move between br3 and tun11 (and hence, you will not get a connection). The last line prevents all traffic on br1 if the VPN is down.

 

Port Forwarding:

This is straight from AirVPN's FAQ, copied here for completeness. To forward ports to clients, four firewall rules are required for each port you wish to forward. Here I am forwarding port 12345 (both UDP and TCP) to my one VPN'd client on my main LAN.:

iptables -I FORWARD -i tun11 -p udp -d 192.168.1.120 --dport 12345 -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.120 --dport 12345 -j ACCEPT
iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 12345 -j DNAT --to-destination 192.168.1.120
iptables -t nat -I PREROUTING -i tun11 -p udp --dport 12345 -j DNAT --to-destination 192.168.1.120

 

Preventing leaks on the main LAN when not using policy routing:

If you are not interested in policy based routing, and just want to prevent leaks while routing all traffic through the VPN, make sure you check Redirect Internet traffic in the VPN Client Advanced tab and then the following firewall rules:

iptables -t nat -I PREROUTING -i br0 -p udp --dport 53 -j DNAT --to 10.30.0.1
iptables -t nat -I PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to 10.30.0.1
iptables -I FORWARD ! -o tun11 -s 192.168.1.1/255.255.255.0 -j DROP

The above is completely untested by me as I don't want to route my main LAN (other than a single client) over the VPN. It may cause connectivity issues with the router itself if the tunnel goes down. If someone does test, please come back here and report your results!

 

I hope this guide helps anyone wishing to use Tomato's VPN client to get connected and if you run in to any trouble, I am happy to try and help solve the issue.

 

Troubleshooting:

If something isn't working and you've entered everything correctly, I've found that rebooting the client you want routed through the VPN or restarting the VPN client can help. Also, rebooting the router will flush out anything left over between configuration steps and can sometimes solve problems. You can also rebuild the firewall rules in Tomato by going to the Tools->System Commands tab in the interface, and sending service firewall restart. If these don't help, double check that everything is configured appropriately.

[njuskalonjusko 0]

Thank you very much for this detailed and useful guide.

 

I have a problem accessing tomato web interface since upgrading from shibby's 128 to any newer release.

 

Port forwarding router's port (using iptables) doesn't work any more as it used to work on 128. All other devices port forward fine using the same set of rules. Tried forwarding both local access port and remote port but neither didn't work. I wonder what has been changed in tomato, apart from policy based routing which I kept off in gui and inherited iptables/firewall script from 128.

 

Tried also posting this on linksysinfo.org but haven't got a response yet.

[PsychoWolf 16]

What version did you upgrade to? I know in 133/134 if coming from something older, a complete NVRAM wipe is required as a LOT of internal variables changes. I think it's in the release notes for 133.

RELEASE] 133

Attention: You have to erase nvram after upgrade!!

[njuskalonjusko 0]

 

What version did you upgrade to? I know in 133/134 if coming from something older, a complete NVRAM wipe is required as a LOT of internal variables changes. I think it's in the release notes for 133.

RELEASE] 133

Attention: You have to erase nvram after upgrade!!

I always clear NVRAM on before and after upgrade.

 

I tried upgrading 128 -> 132 and 128 -> 134.

 

With Openvpn client disabled I can access the router on remote port (>128), but with vpn enabled not (port forwarded but not accessible from Airvpn). 

 

I wonder whether this has anything to do with this:

 

[RELEASE] 129
K26ARM
– IPset
* update to 6.24 – attention! This version has different kernel modules and different syntax of command. If you are using IPSet, you have to fix your scripts.

[PsychoWolf 16]

I apologize for the late reply here.

 

Are you using your own firewall script for policy based routing? If so, I won't be of much help I'm afraid. My guide is meant to use the later versions of Tomato that include it and (for me at least) it works with much more ease than the various script methods I've seen posted elsewhere.

 

I used to use an up/down script to mark traffic as well, but it's been a long time and I don't remember if it had IPSET in it (I think it did though). I suspect that if your script is using IPSET as well and you may need to modify it to suit the new syntax.

 

I highly recommend the gui now though, as it's been able to handle everything I've wanted to do without any trouble.

[njuskalonjusko 0]

Hello, the script and IPSET syntax I used is the same as you wrote in your Port Forwarding section. I'm out of ideas for the moment and will stay with v. 128 for the time being.

[PsychoWolf 16]

Are you forwarding to your external IP or your internal IP for the router's web interface? I'm wondering if there's something new that prevents the tun11 interface from communicating with the router's external interface...

 

Try adding something like:

 

 

iptables -I FORWARD -i vlan2 -o tun11 -j ACCEPT
iptables -I FORWARD -i tun11 -o vlan2 -j ACCEPT
 

to the firewall.

 

I've never tried to access my router remotely through the VPN, so this is new territory for me.

[njuskalonjusko 0]

Thanks, I already downgraded to 128, will try your suggestion as soon as I get a chance and will report back.

[Mikeyy 49]

Thank you for nice tutorial, it will help!

 

On your own example, if you would like to portforward port 5000 via WAN to your VPN 192.168.1.120, how would you acomplish that?

 

Lets say your WAN (external IP) is 80.x.x.x and you AirVPN external IP is 213.x.x.x.

I want to access 8.x.x.x:5000 which is via GUI port fowarded to internal 192.168.1.120 which is only allowed to reply via VPN.

 

How to make replys from 192.168.1.120 go via WAN when port 5000 is used?

 

Hope you understood me.

[PsychoWolf 16]

Thank you for nice tutorial, it will help!

 

On your own example, if you would like to portforward port 5000 via WAN to your VPN 192.168.1.120, how would you acomplish that?

 

Lets say your WAN (external IP) is 80.x.x.x and you AirVPN external IP is 213.x.x.x.

I want to access 8.x.x.x:5000 which is via GUI port fowarded to internal 192.168.1.120 which is only allowed to reply via VPN.

 

How to make replys from 192.168.1.120 go via WAN when port 5000 is used?

 

Hope you understood me.

 

So you want traffic on port 5000 use your ISP connection and not the VPN, but all other traffic to use the VPN?

 

I'm not sure it's possible with just the GUI, and besides I think that would cause a leak as your real IP could be revealed.

[Mikeyy 49]

Nope, with GUI it isn't possible. I can use Redirect through VPN to force that LAN IP to use VPN, but I can't mark port 5000 to use my ISP IP (WAN) on same machine.

 

I need this for my Synology NAS, which has all traffic routed through VPN, but when I want to access it via mobile apps (DS Download, DS Pictures, DS Files, DS Cloud Station) or desktop apps (Cloud Station Client), I need to access it via regular internet and regular IP, not VPN.

[PsychoWolf 16]

Nope, with GUI it isn't possible. I can use Redirect through VPN to force that LAN IP to use VPN, but I can't mark port 5000 to use my ISP IP (WAN) on same machine.

 

I need this for my Synology NAS, which has all traffic routed through VPN, but when I want to access it via mobile apps (DS Download, DS Pictures, DS Files, DS Cloud Station) or desktop apps (Cloud Station Client), I need to access it via regular internet and regular IP, not VPN.

 

Why not use Air's port forwarding and access it via the VPN as well?

[Mikeyy 49]

Tried that few years ago. I think that problem what that I couldn't have same external and internal port, and in some programs I couldn't change port.

[PsychoWolf 16]

Tried that few years ago. I think that problem what that I couldn't have same external and internal port, and in some programs I couldn't change port.

 

Sorry I don't have any other ideas for you. 

[apofis 0]

It's probably actually better to use the DNSCrypt since you have Tamato anyways

[Flx 76]

Hello, the script and IPSET syntax I used is the same as you wrote in your Port Forwarding section. I'm out of ideas for the moment and will stay with v. 128 for the time being.

FIREWALL RULES SET FOR tun11 and tun12.

----------tun11------------------------------------

iptables -I FORWARD -i br0 -o tun11 -j ACCEPT

iptables -I FORWARD -i tun11 -o br0 -j ACCEPT

iptables -I FORWARD -i br0 -o vlan2 -j DROP

iptables -I FORWARD -i br0 -o ppp0 -j DROP

iptables -I INPUT -i tun11 -j REJECT

iptables -t nat -A POSTROUTING -o tun11 -j MASQUERADE

--------------tun12-------------------------------

iptables -I FORWARD -i br0 -o tun12 -j ACCEPT

iptables -I FORWARD -i tun12 -o br0 -j ACCEPT

iptables -I FORWARD -i br0 -o vlan2 -j DROP

iptables -I FORWARD -i br0 -o ppp0 -j DROP

iptables -I INPUT -i tun12 -j REJECT

iptables -t nat -A POSTROUTING -o tun12 -j MASQUERADE

---------------tun12-------------------------------

With the above firewall rules set not a problem since.

Regards,

Flx