Advertise on Bikeforums.net



User Tag List

Results 1 to 8 of 8
  1. #1
    Portland Fred banerjek's Avatar
    Join Date
    Oct 2005
    My Bikes
    Custom Winter, Challenge Seiran SL, Fuji Team Pro, Cattrike Road/Velokit, РOS hybrid
    Posts
    10,560
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Any iptables wizards out there?

    I have 3 machines to work with:

    1) machine A (windows box running client program)
    2) machine B (linux box trusted by all machines)
    3) machine C (proprietary system that trusts B but not A)

    I need A to send data to port 5500 on C and receive all communications back. Can someone take a look at my first stab and tell me if I'm in the right ballpark?

    iptables -t NAT -A PREROUTING -s A -d B--dport 5500 -j DNAT --to-destination C:5500
    iptables -t NAT -A POSTROUTING -s C -d B --dport 5500 -j SNAT --to-source A

    I've never had to NAT before, so I'm trying to wrap my mind around this. Thanks

  2. #2
    Senior Member DannoXYZ's Avatar
    Join Date
    Jul 2005
    Location
    Saratoga, CA
    Posts
    11,507
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Does your LINUX machine-B have two NICs? One's connected to machine-A and the other to machine-B? And machine-A and machine-B are not connected to each other?

  3. #3
    T-Shirt Guy ehidle's Avatar
    Join Date
    Jul 2008
    Location
    Lansdale, PA
    My Bikes
    2005 Fuji Team Issue, 2007 Fuji SL-1
    Posts
    464
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You'd be better off with an SSH tunnel if you can tolerate the authentication step.

    Set up a tunnel from the Windows box to Linux Box B using Putty. In the putty options, set up an SSH tunnel using a $LOCAL_PORT you can use and for the destination use the IP address of box C and the port. Check "Local" for the tunnel destination.

    When you log in to box B using Putty, you connect to locahost:$LOCAL_PORT and box B will forward that to $IP_OF_CORT_OF_C that you chose for the tunnel. C will think the request is coming from B, not A, and B will forward any responses through the tunnel to A.

    Since it sounds like you're doing something untoward, you also have less chance of getting caught because there are no config files on B that will show that you're breaching the security of C using A, except maybe disabling box B's sshd reporting to /var/log/secure, but that in itself isn't proof. That's a "configuration error."
    Yellow + Blue Jerseys!

    Get your Cranky T-Shirt!
    Men's
    and Women's designs available

  4. #4
    Portland Fred banerjek's Avatar
    Join Date
    Oct 2005
    My Bikes
    Custom Winter, Challenge Seiran SL, Fuji Team Pro, Cattrike Road/Velokit, РOS hybrid
    Posts
    10,560
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Physically, these machines are many miles apart. Basically, I'm just trying to proxy a connection. I have no physical access to boxes A or C, nor can I log into either.

    Box A is controlled by a user far away from me, and box C is controlled by an institution, so the only thing I can control other than box B is to ask the user who has box A to make slight config tweaks to his software client.

  5. #5
    don't try this at home. rm -rf's Avatar
    Join Date
    Jan 2006
    Location
    N. KY
    Posts
    2,702
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Is your Box B the firewall machine for your location, or is it inside in your local network?

    Does A connect to B? If so, and B isn't the firewall, your firewall device will need to "port forward" the 5500 port to your machine's IP address. You can connect out to any IP, but they can't initiate a connection to you without modifying the firewall settings. Even with the incoming connection forwarded to your machine, you still need an iptables entry to allow that connection to occur.

    So then, if your port is open and listening for connections to forward, anybody on the internet can connect and forward. Either the firewall port forward or your iptable rule needs to limit which IP address can make the connection. I've done this to transfer streams of data between my server and our webserver, but I restrict the remote machine to be their static IP address only. Anyone else trying to connect sees the port is closed.

    Really, you need putty.exe for windows to use ssh to authenticate the A machine, like ehidle said.

    Like ehidle, I don't see why C can't trust A directly. The traffic from A to C will appear to come from your machine. Is that going to be OK when the network admin sees the active connections A-B and B-C? This sounds like proxies that people use to get around their filtered internet connections.


    To forward A's incoming to C, try using netcat to listen and forward: examples.

    For troubleshooting if you have problems:
    nmap -p 5500 1.2.3.4 where 1.2.3.4 is your public IP address, to see if the port is open to be connected to.

    tcpdump -p 5500 to watch all the packets on that port within your own machine.

    tcpdump -p 5500 -s 1500 -w somefilename to collect the raw packets,
    then
    open the file in wireshark to view them. (or collect them directly in wireshark)

    Wireshark is great.
    Last edited by rm -rf; 11-23-08 at 07:46 PM.

  6. #6
    Portland Fred banerjek's Avatar
    Join Date
    Oct 2005
    My Bikes
    Custom Winter, Challenge Seiran SL, Fuji Team Pro, Cattrike Road/Velokit, РOS hybrid
    Posts
    10,560
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by rm -rf View Post
    Is your Box B the firewall machine for your location, or is it inside in your local network?
    It's inside the local network, but the machines on this particular network have public IPs. The firewall allows connections between A and B on port 500 so A has no trouble reaching B.

    Quote Originally Posted by rm -rf View Post
    So then, if your port is open and listening for connections to forward, anybody on the internet can connect and forward. Either the firewall port forward or your iptable rule needs to limit which IP address can make the connection.
    This is the idea.

    Quote Originally Posted by rm -rf View Post
    Really, you need putty.exe for windows to use ssh to authenticate the A machine, like ehidle said.

    Like ehidle, I don't see why C can't trust A directly.
    Running putty on A is not a problem. However, the program that A needs to run just opens raw sockets so it can't run on top of that connection. In an ideal world, C would trust A. However, the bureaucracy at C is terrible, and the technical people there are neither good nor responsive. If we work the system, we can get C to trust A, but we will run out of time on our project first.

    Quote Originally Posted by rm -rf View Post
    The traffic from A to C will appear to come from your machine. Is that going to be OK when the network admin sees the active connections A-B and B-C? This sounds like proxies that people use to get around their filtered internet connections.
    That is OK. I have a very good working relationship with our local people. I try to keep them informed of what I'm up to, and they've always let me do what I want.

    Quote Originally Posted by rm -rf View Post
    To forward A's incoming to C, try using netcat to listen and forward: examples.
    I hadn't thought of using netcat -- thanks for the tip. I might experiment with it a bit. The only problem I can see is that A needs to be able to see messages that C sends, and it isn't clear to me how that will work.

    B has no gui, so I'll have to stick with tcpdump. However, I'm pretty comfortable with that.

  7. #7
    don't try this at home. rm -rf's Avatar
    Join Date
    Jan 2006
    Location
    N. KY
    Posts
    2,702
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    tcpdump -- you can copy the saved file to another linux or windows machine and run wireshark there, if needed.

    I don't use netcat much, but the forward should work in both directions automatically. It's easy to try, anyway.

    These are tcp ports, not udp ports, correct? You can use putty to forward a localhost port on the A machine. So they connect to 5500 on localhost, then putty forwards it to your B machine. Generate a public keypair instead of using passwords, and it won't need to stop to ask for a password when started at A. Then only machines with the key can get in to your B machine.

    UDP is a lot more complicated to forward, since it's packets need to be converted to TCP and back in order to get to the C machine.

  8. #8
    Portland Fred banerjek's Avatar
    Join Date
    Oct 2005
    My Bikes
    Custom Winter, Challenge Seiran SL, Fuji Team Pro, Cattrike Road/Velokit, РOS hybrid
    Posts
    10,560
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by rm -rf View Post
    I don't use netcat much, but the forward should work in both directions automatically. It's easy to try, anyway.

    These are tcp ports, not udp ports, correct? You can use putty to forward a localhost port on the A machine. So they connect to 5500 on localhost, then putty forwards it to your B machine. Generate a public keypair instead of using passwords, and it won't need to stop to ask for a password when started at A. Then only machines with the key can get in to your B machine.
    Ahh -- this sounds like it may be the ticket. These are tcp ports. I might use this method for other things too. I like the simplicity and the improved security.

Posting Permissions

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