Find the answer to your Linux question:
Results 1 to 5 of 5
I've managed to confirm that I can reach my home network via ssh from a remote location through my SMC Barricade when it is directly connected to the desktop machine ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jul 2006
    Posts
    36

    port forwarding - two routers - Tomato firmware


    I've managed to confirm that I can reach my home network via ssh from a remote location through my SMC Barricade when it is directly connected to the desktop machine but when the second router is put back into the chain ssh requests time out .The second router is a Linksys WRT 54GL running the Tomato firmware.

    The chain looks like this:
    ISP's router (bridged) --> Barricade -->WRT54GL-->desktop

    The Barricade has port 22 forwarded to the Linksys' WAN address and it in turn forwards to the desktop address.

    It appears that it is a setting on the Linksys firmware that is preventing the remote connection.
    I've looked through the various settings many times but cannot see anything that would cause the problem.

    Is there anyone familiar with Tomato who might enlighten me?

  2. #2
    Linux Engineer Kloschüssel's Avatar
    Join Date
    Oct 2005
    Location
    Italy
    Posts
    773
    dunno about the wrt having any bug or so, but it should definitly work. my chain at home looks like:

    ISP router (bridged) <==forward+masquerade==> wrt54 <==forward+masquerade==> server / pc / laptop

    so there is not much difference to yours in there.

    1] if you are not able to configure the wrt thingy correctly, you may consider to flash the wrt with openwrt / whiterussion and you have full control over it using iptables.

    2] check all configurations if you set up the forward routing properly (both directions must be ok)

    3] have you set up distinct subnets for each of those?

  3. #3
    Just Joined!
    Join Date
    Jul 2006
    Posts
    36
    Quote Originally Posted by Kloschüssel View Post
    dunno about the wrt having any bug or so, but it should definitly work. my chain at home looks like:

    ISP router (bridged) <==forward+masquerade==> wrt54 <==forward+masquerade==> server / pc / laptop

    so there is not much difference to yours in there.
    The firmware has been around for several years so I think it's not a bug, just my lack of understanding of the Tomato configuration.
    1] if you are not able to configure the wrt thingy correctly, you may consider to flash the wrt with openwrt / whiterussion and you have full control over it using iptables.
    I consider it a challenge to get Tomato working - so I'll stick with it for now.

    2] check all configurations if you set up the forward routing properly (both directions must be ok)
    I was given a link to a page that shows hot to set up port forwarding for many different routers, but of course the page for the wrt only shows the stock firmware instructions but they didn't mention "masquerade", this is something new to me. That page shows only how to make the path for the incoming packets.
    It seems logical to me that since both routers know the way to the internet, packets going from the desktop ought to be able to find their way back to my laptop at the remote location once the incoming path is defined and the ssh connection is made - no?

    If I understand you, you're saying the wrt must have a forwarding path back to and through the Barricade to the cloud?

    When I try ssh remotely (outside my LAN) it times out which seems to tell me - I think - that the request is not getting through the first router - the Barricade, and it's not being refused, it's just not connecting, as if there are no forwarding rules set up.

    Of course I've used the WAN and LAN addresses to the desktop address, eg. the Barricade's WAN address forwards to the WRT's WAN address, the the WRT's LAN address to the Desktop internal IP.

    I am also unclear about testing the connection - I was told that I should be able to test it from inside my LAN by sshing to the Barricade's WAN address but another blog I found on the subject says I must be on a different network for it to work.

    3] have you set up distinct subnets for each of those?
    Yes, the machines connected to the wrt have 192.168.1.x addresses - those connected to the Barricade have 192.168.2.x - so that's done. I can ping the 2.x machines and both routers from the 1.x machines.

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Engineer Kloschüssel's Avatar
    Join Date
    Oct 2005
    Location
    Italy
    Posts
    773
    Aaaalright. This could become a long story.

    First of all, the second forum is right. Usually packets from inside the lan are not routed outside and then back inside again, but are immediately picked up by the router if he is the receiver of the packet. So what happens if you're inside the lan? You're not actually going through the firewall rules that apply to the outside world, but the ones you set up for the inside world (i found that netgear sometimes refer to it as inbound / outbound traffic).

    Now to the forwarding .. ehm .. first of all you must set the router to accept the packets. This you do by telling him to accept packets from i.e. port 22 and not dropping them like it does for all other ports. In iptables this would be a new entry in the input chain. Basically it accepts all packets that came over the wan interface and should be transferred to the host you want. The actual destination is put by the second step below.

    Code:
    iptables -A INPUT -i $WAN_INTERFACE -p tcp --dport 22 -d 192.168.1.2 -j ACCEPT
    Then as second step you must tell him how the packet should be transferred. For the connecting client it would be rather confusing to connect to a host and receiving the reply from another host that hides behind that host. So this basically is what masquerading does. A host receives a packet, translates it as if was his own request and sends it to the lan server and the response from the lan server is translated back and sent to the origin. I hope this is not too much confusing.

    iptables does these operations in the prerouting chain:
    Code:
    iptables -t nat -A PREROUTING -i $WAN_INTERFACE -p tcp --dport 22 -j DNAT --to 192.168.1.2:22
    Basically incoming traffic that was accepted previously at port 22 is translated and sent to 192.168.1.2 on port 22.

    All commands I have written here are just out of my head, no guarantee they actually work. Use
    Code:
    iptables -L
    to list all chains and rules to get to the correct chain names.

    Greetings

  6. #5
    Just Joined!
    Join Date
    Jul 2006
    Posts
    36
    Quote Originally Posted by Kloschüssel View Post
    Aaaalright. This could become a long story.

    First of all, the second forum is right. Usually packets from inside the lan are not routed outside and then back inside again, but are immediately picked up by the router if he is the receiver of the packet.
    This is as I thought.

    Now to the forwarding .. ehm .. first of all you must set the router to accept the packets. ~*~*~*~snip*~*~*~*~
    I'm reading up on iptables and will see what happens.
    Thanks for the input!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •