TomatoUSB

I have enjoyed several months of good performance and excellent reliability from Toastman's versions of 1.28, but I have a problem that I am having a hard time resolving.

If an OpenVPN tunnel is in use and the "Redirect Internet traffic" box is NOT checked, inbound port forwarding works as expected. For example, a rule that forwards port 9100 on the outside, to 192.168.1.10 on the inside allows me to print from the Internet to the printer at that IP.

When the "Redirect Internet Traffic" box IS checked, however, port forwarding no longer works. I suppose that when the printer replies to TCP traffic, the reply is caught by the default route and sent to the tunnel rather than the Internet.

I cannot think of an easy solution to this. Anyone have any ideas?

First of all: why are you doing port forwarding to printer? once you have established a tunnel and also have "enabled the option to publish Lan" to the client, the routes are set.you can reach the printer as 192.168.1.10:9100 as opposed to <externalIP>:9100.

I used the printer only as an example. Fact is I need to use port forwarding from the Internet to my LAN, not from the other end of the OpenVPN tunnel.

Still looking for a way to use inbound port forwarding while the tunnel is in use.

i think people might need a better explanation of your usecase to suggest solutions:
a) if the only person who is going to access it from internet is YOU and you can establish a tunnel, then there are no issues.
b) why would you want to do portforward on your router(something you dont want to do unless absolutely necessary) when you can establish a tunnel?
c) also, i dont think the reply from the printer as explained by you would get caught and sent to tunnel. the default route on your routing table for NON LAN/TunnelIps would be to the internet.(your source Ip is an Internet IP address and not a tunnel address since you dont come through the tunnel)

Well either way, port forwarding does not currently work if the "Redirect Internet Traffic" box is checked. Whatever my use case, checking that box causes port forwarding to fail. If you really need me to justify mu use case, however:

I have a VPN tunnel established to forward all Internet traffic to a company that provides virus detection and content filtering services. All traffic is routed to them to benefit from that service.

I would also like to be able to access a baby monitor type webcam on my LAN from the Internet. I can access the camera if the "Redirect" box is not checked, but then Internet traffic does not go to my security provider. If I check the box, port forwarding no longer works.

I too would have expected that traffic that arrives from the Internet would go back to the Internet. Something is breaking it though. The most likely candidate is the default route that sends all traffic to the OpenVPN tunnel.

Steve: when you select the "Redirect Internet Traffic" box, ALL your traffic is going to go through tunnel gateway. None will reach your WAN address(Internet address) to be port forwarded.that's why it appears that port forwarding is not happening.

Note though there are other potential issues with using "Redirect internet traffic":
*
Many OpenVPN client machines connecting to the internet will periodically interact with a DHCP server to renew their IP address leases. The redirect-gateway option might prevent the client from reaching the local DHCP server (because DHCP messages would be routed over the VPN), causing it to lose its IP address lease
**

I ended up writing a script that uses multiple routing tables to create matching outbound rules for all inbound rules. Seems to be doing the job.

I ended up writing a script that uses multiple routing tables to create matching outbound rules for all inbound rules. Seems to be doing the job.

I must confess I got a bit curious about that script of yours… would you be able to share it with us?

Thanks!

I ended up writing a script that uses multiple routing tables to create matching outbound rules for all inbound rules. Seems to be doing the job.

Could you share the script? I have a similar issue. My ISP is evil; to get around them I use a VPN that also gives me a public IP. The VPN provider has all ports open. I've configured Tomato to allow remote admin access (purely to test inbound connections) on 8080; I've also set up two portforwards on port 9742 and 27272. All three of these do not work. However, remote SSH, on 2222, works.

I suspect this is because the port forward routing rules are set up to work with the WAN interface; whereas in my case they should be working with the OpenVPN tun11 interface.

I know nothing about iptables, apart from the fact that I get an instant headache trying to understand them. Is there a simple fix to this issue, or am I doomed to either having a VPN or my ports forwarded?