port forwarding

[townsend]

I have two ISPs feeding two separate LANS. One has a commercial router with internal network address of 192.168.2.0 while the other has a linux router with internal network address of 192.168.0.0

I have several pieces of equipment on the 192.168.0.0 network that use a web-based interface to access and operate. Normally I access this equipment from a node also on 192.168.0.0. However, I have a requirement to access the equipment from outside. Since the outgoing connection uses a VPN service, I can't get in that way.

A few years ago I set up a small computer to bridge between 192.168.2.0 and 192.168.0.0 ... it has interfaces 192.168.2.75 and 192.168.0.3 and I've got port forwarding on port 3333 on the commercial router to get me to that box from a specific IP out in the world. I can't set things up to get all the way to machines on the 192.168.0 network, but I don't have to - I just get into that box, and I can ssh to the hosts on that network since the box has an interface on that network.

However, my needs have changed, and ssh won't do. I need to get directly to these units on port 80 now. The trouble I  have is that I can set everything up so that incoming packets from the outside world make it to the equipment, but won't come back out the correct way. I believe this is because the default router for them is 192.168.0.1 and they would have to use 192.168.0.3 to get back out the way the incoming packets got in.

By the way, I am forwarding incoming ports using the scheme of port xxxyy where xxx is the last octet of the local LAN IP number of the desired host and yy is 80. So for example, to reach the web interface of host 192.168.0.160, I would ask in the browse for publicIP:10680 and the commercial router nats this into 192.168.2.75:10680 ... When it arrives at that destination, 192.168.2.75 further nats it into 192.168.0.160:80.

Now the problem is that when 192.168.0.160 tries to respond, it uses its default gateway of 192.168.0.1 and the packet goes out with the wrong ip number stamped on it and proceeds out the VPN where it disappears. I tried to put a static host route to the originating external remote host's IP number to route it back to 192.168.0.3, but that doesn't seem to do the job.

Any suggestions?

[deanwebb]

I'm thinking a reverse proxy setup might be the thing. The pieces to the puzzle would be the cloud login and the local server, both which would be provided by the cloud proxy vendor. Create routes such that the reverse proxy can use the same path for inbound/outbound.

Would that work?

[townsend]

Thanks for the feedback. After my post, I thought of trying that approach, but having no experience with proxy servers, I was flying by the seat of my pants. I installed something called "squid", but I couldn't get it working. I was attempting to set all this up before I left on vacation (tomorrow) so I'd have a secure way of checking on my equipment while gone. But alas, I guess I'm out of time. I probably ALMOST had it solved, but its too late now. Maybe I can sort it out in time for my next vacation. In the meantime, I have my daughter dropping by each day to check on the equipment.
-gt-

[townsend]

I also thought of something else that I attempted to work - maybe you can comment on it. I tried setting up the commercial router to port forward remote desktop to a laptop through WiFi, with an Ethernet cable connecting it to the equipment LAN. All the pieces worked separately, but not together. I could access the equipment via browser with the Ethernet connected, and I could remote desktop into it from afar via the WiFi, but only if the Ethernet was disconnected. As soon as the Ethernet was plugged in, the remote desktop connection froze up. I suspect that the laptop was preferring the Ethernet as the default route whenever it was available, meaning that remote desktop packets were still arriving via WiFi, but exiting the laptop the wrong way when the Ethernet was available. Is there a simple way in Windows to tell it NOT to use the Ethernet as a route? And is there a way to make that persistent?
-gt-

[townsend]

Woohoo!!!!! I got it ready and working JUST in time! All I did was change the metric on the WiFi route to 1 from 35.  The metric on the Ethernet was 25, so it was preferred. This solved the problem completely. So, I've got a solution while I'm on vacation. Given that it is changed in adapter settings, I guess it will persist a reboot.
-gt-

[deanwebb]

Great to see you got it solved!