Old host only talks to LAN addresses, no port forward possible

Discussion in 'Tomato Firmware' started by arnoldus, Aug 7, 2013.

  1. arnoldus

    arnoldus Serious Server Member

    I have a security camera logging device from the 1990's. Somehow it is programmed to only talk to local LAN addresses.

    This means that I can get to it with an OpenVPN connection, but not with a simple WAN-LAN port forward. For other purposes the port forwards are working perfectly fine.

    As I want other people to be able to access it without too much hassle, and without giving them OpenVPN acces, I wonder what can be done to accomodate this?

    Can iptables somehow intermediate between this device and WAN? Are there any other solutions within Tomato (or the other distros?)

    My router is a WRT54GL running K24 Tomato RAF 093. I have also tried with a WRT54GL running the latest K26 Shibby, but to no avail.
  2. Monk E. Boy

    Monk E. Boy Network Guru Member

    The device probably doesn't have a default gateway set. Not saying there's a way to set the default gateway, but if you could, that would likely enable it to talk to non-local addresses.

    You could do it with OpenVPN and a configured TAP interface.

    You could setup port forwards to a PC or other system on the LAN and let them, via remote control of system, talk to the device.
  3. arnoldus

    arnoldus Serious Server Member

    It does have the correct default GW set, as well as correct subnet mask.
    At present I do use OpenVPN & TAP.
    I think that the firmware of the device is probably buggy in that regard, but that's what I've got to work with.

    I thought about a relaying solution, but the truth is that it would take me weeks to program something like that.
    Unless there are somewhat developed standard solutions for relaying under linux?
  4. koitsu

    koitsu Network Guru Member

    The issue here seems to be that the device in question requires the source address (of the incoming packet) to reside within the "LAN segment" (i.e. Port forwarding does not rewrite the source IP, only the destination IP. This is by design -- step back for a moment and think about this scenario and how you would go about solving it cleanly/easily:

    * Source IP: (client)
    * Source port: 42751 (client) -- this is normally randomised, so I just picked something
    * Your WAN IP:
    * Your LAN network:
    * Your camera's LAN IP:
    * Your camera's LAN port number: 33333

    Assume a port forward is set up to redirect to

    Here's what happens at the networking layer:

    1. Router sees inbound packet on WAN interface, coming from destined to
    2. iptables rules rewrite the destination IP to but leave the source IP alone
    3. Packet gets forwarded on to
    4. Camera device sees packet
    5. Camera ignores packet because source IP is not within network

    Now think about what would happen if you had a networking layer which rewrote the source IP. Instead, this would happen:

    1. Router sees inbound packet on WAN interface, coming from destined to
    2. iptables rules rewrite the destination IP to
    3. iptables rules rewrite the source IP to, say, (you would have to decide)
    4. Packet gets forwarded on to
    5. Camera device sees packet
    6. Camera responds to packet because source IP is within
    7. Camera's outbound packet details: coming from destined to

    Think about #7 for a little bit. How exactly do you expect a packet destined to a LAN address, i.e., to get "magically" sent across the Internet, destined to Answer: you can't.

    OpenVPN is complete and total overkill for this task. I do not know why everyone resorts to OpenVPN for this stuff -- it's a nightmare to manage/maintain unless you know exactly what you're doing and it opens you up to all kinds of security implications since essentially the client now has access to everything on your LAN. Uhhhhhh... yeah, NO THANKS.

    The most elegant and simple solution is to use an SSH port forward. You need an OpenSSH server running somewhere on your network that's Internet accessible (or has a TCP port forward set up to reach it, e.g. port forward of 2222 to This is how I used to access key devices like web-only managed switches and critical infrastructure within my own datacenter/co-location, as well at at my workplace, which had devices within reserved IP space (ex. The client then can open up in their web browser (or whatever -- custom applications will also work, but keep reading) (or some arbitrary port number -- pick one, it doesn't really matter) that then gets "forwarded" through the SSH server. This would also work with "custom programs" that talk to a device on the network, but the important thing is that it has to be TCP based -- SSH cannot forward other protocols. I can explain this in greater detail if need be, including how it works and all that (at the TCP level), but there is already tons upon tons of documentation online explaining how it works, diagrams, and all that. I can find you one if it's confusing.

    I will note that the SSH server built-in to Tomato, I think, has this capability -- HOWEVER, you wouldn't want someone SSH'ing into your router anyway -- this is extremely dangerous, even if they don't have root, as most things on these routers are globally readable, they are not treated with the same security respect as a UNIX server. You could run OpenSSH for Windows if you wanted, etc. and just make a generic account that has access to virtually nothing on the filesystem, yadda yadda.

    SSH really is the best way to solve this as long as the device uses TCP.
  5. arnoldus

    arnoldus Serious Server Member

    Thanks for your elaborate reply koitsu.

    I have OpenVPN for other network and device administrations tasks, not only for this.

    I understand the problem, which is why the relaying idea is interesting.

    I did a packet analysis, unfortunately the video payload is (understandeably) sent with UDP.Found an undocumented option that transmits almost everything in TCP.
    The protocol is something proprietary (fed through the proprietary software, or through an IE plugin).

    However, I found that the linux programs netcat & socat could help in relaying this kind of UDP traffic.
    I will look into this, and feedback here if I can get it working properly.

    If there are other ideas on how to tackle UDP redirection, please shoot.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice