Take the 2-minute tour ×

I have the following setup -

Verizon Fios Router - WAN - Public IP Address Verizon Fios Router - LAN -

This connects directly to an internal Linux Router -

Internal Router Linux - eth0 - Internal Router Linux - eth1 -

The problem I am having is if a request originates from the 10.10.10.x network or the network to the public IP address the request gets lost somewhere in networking land.

The linux router is on the internet directly via the DMZ feature of the Fios router.

I think I'm just missing a basic route command but I'm not sure where to go next.

The reason any of this matters is I am trying to run the VNC-Java client on the linux router to connect to the vncserver that is running directly on the same machine. When the java client goes to connect it tries to connect to the external IP address which the linux router really has no idea about because it believes it's

I suppose there is another solution... And that's tell the tightvnc java client to connect to the host but I can't find where exactly to set that either.

Regular VNC client works fine but I would like to avoid having to have the client software.

Thoughts / Suggestions? Am I just out of luck due to the one to one nat?

share|improve this question
It sounds like you have two different problems: 1) packets from either internal network can't reach the public internet, and 2) your Java VNC cilent can't connect to - you are probably accessing through a browser from outside the network so it can't access anyway. The first is a routing issue, the second is a configuration issue with your Java VNC web page. Please describe which you want to solve. –  Guss Aug 26 '09 at 17:45
Would love to solve the routing issue first. Why can't machines on the internal network talk to the external IP address. Shouldn't the traffic flow out the internal router to the external router and back in? Or can I just snag them before they leave the internal router? –  jchawk Aug 26 '09 at 17:59

2 Answers 2

up vote 1 down vote accepted

Regarding the routing issue, because your internal network uses non-routable IP addrsses (private), then your linux router must "masquerade" them when they go out through the external IP address (which is also non-routable, but your Linux router need not know that - the Cisco can handle that part).

Something simple like

iptables -t nat -I 1 POSTROUTING -s -o eth0 -j MASQURADE

should do the trick. If you can tell me what distribution you are using on the Linux router then I can give better instructions on how to set it up permanently as part of your Linux router's network setup.

Also please make sure that you have ip_forwarding enabled - check the output of sysctl net.ipv4.ip_forward : it should say "1"

share|improve this answer
Well simple Masquarding is already working fine. I am accomplishing this via - up /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE In the /etc/network/interfaces file. The problem is my internal machines cannot access the public IP address which is one to one nat'd to eth0 on the linux box. They can however access anywhere else on the internet. Thoughts? –  jchawk Aug 26 '09 at 18:23
The problem is probably that you masquerade everything going through eth0 while you should only need to masquerade IP addresses that are not mappable on eth0 (i.e. the internal network). Because you masquerade everything, packets from going to also get mangled and its probably not a good idea. –  Guss Aug 26 '09 at 18:27
Guss thanks, I'll try adjusting the statement and see if it has any effect. –  jchawk Aug 26 '09 at 18:52
While I agree cleaning this rule up is a good idea, it has not cleaned up the problem of not being able to access the external IP from the internal lan. –  jchawk Aug 26 '09 at 19:07
You probably have some other rule that breaks this - can I see the output of iptables-save ? –  Guss Aug 26 '09 at 23:24

In addition to Guss' answer (which is correct) you will also need to make sure that all your computers have the correct default gateways configured. For the computers on the 10.10.10.x subnet this is probably For all computers on the 192.168.1.x subnet this is probably (at least this is what I am reading from your post).

Normally these would be set through DHCP. If you don't use DHCP, you will have to set these values (and their corresponding subnet masks) manually.

share|improve this answer

Your Answer


