Hopefully simple port-forwarding solution needed, single port

I'm running Fedora Core 4 as my base.  I don't know offhand what's installed as optional bits and pieces, but iptables --list outputs a blank list (which I assume means it's installed. ;)).

Okay, network topology.  I'm running a standard 'home lan' behind a wifi router, IP addresses 192.168.0.x, router does dhcp, nat, etc.  I have two PCs, one XP, one FC4.  The FC4 box has a second nic, connected via crossover to an embedded development box.  The primary nic is say on the local lan, the embedded box is via the secondary nic (ie, secondary 'hidden' network 10.0.0.x).

So, the FC4 box can ping/telnet the embedded box, but the windows box obviously can't.  I want to make it so that I can forward packets on one port (one particular port), pointing the XP box to the FC4 box, and having the FC4 box forward stuff along (and back) I guess making a NAT connection from XP -> embedded on that port.

I don't want to set up any further firewalling, filtering, etc.  The FC4 box is a fully-working network client, and no other functions/services should be disrupted.  i.e., I don't want to turn the FC4 box into a generalized NAT router/firewall for the embedded box subnet.  Just a 'tunnel' for the XP and embedded boxes to talk over a given port.  Use port 8888 for crafting an example.

I assume this should be one or two rules in iptables or other method, plus maybe one or two other commands to actually turn on iptables (or, again, whatever method) routing.  I'm a developer, have some concept of NAT, et al, but haven't found a simple solution -- everything is making a linux box into a full firewall/router.

Set at 250 points to start, but I'll kick this up to 500 points if I got a working solution today (that is, I get a solution, and implement it and it works..). ;)

LVL 17
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Actually, you probably want to use ssh to tunnel, rather than iptables.  Especially if you only need say ssh or one other service.

This article: http://www.oreillynet.com/pub/a/wireless/2001/02/23/wep.html - although ostensibly about wireless, shows you what you need to do.

xinetd can do what you need

edit "/etc/xinbet.conf"

# service name /etc/services
# e.g.: myservice  8888/tcp
service myservice
        disable = no
        flags = reuse
        socket_type = stream
        wait = no
        user = nobody
        redirect = 9999
        only_from =
        log_on_failure += USERID
        log_on_success += PID HOST EXIT DURATION

and activate the xinetd daemon in /etc/init.d
Gabriel OrozcoSolution ArchitectCommented:
add this in your rc.local file:

#this enables forward so packets can traverse the firewall:
echo "1" > /proc/sys/net/ipv4/ip_forward
#this rule does the DNAT thing (what you asked for assuming eth0=LAN and eth1=crossover to box):
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 8888 -j DNAT --to-destination

#if this is not working because the embebbed box does not have the linux one as its default gatewaty, then
# you need to masquerade internally, so add this rule to make things "fully transparent":
iptables -t nat -A POSTROUTING -p tcp --dport 8888 -o eth1 -j MASQUERADE

1.- I assume your FC4 box already can connect to the embebbed box
2.- I assume you had no other rules in your FC4 box, so all defaults are "ACCEPT"

Happy Linuxing

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

davebytesAuthor Commented:
Thanks for the responses so far.

bstrauss3: interesting approach, tunneling via ssh.  didn't seem to immediately work for me, and it requires that the XP box be running an ssh connection (which I happen to do, but people I work likely don't...).  not counting it out yet...

DonConsolio: hmmm.  that seems like a pretty simple approach.  unforunately, I tried it and wasn't seeming to work.  starting to make me wonder if this custom app/protocol is set up properly on the embedded box (I'm looking into that...).  But certainly seems the most promising, given that the fowarding service can be encapsulated into one file, dropped into xinetd.d, and 'just work' if everything else is correct. ;)  btw, the 'modified' thing I tried was:

service myservice
        disable         = no
        flags           = reuse
        socket_type     = stream
        protocol        = tcp
        user            = root
        wait            = no
        port            = 7876
        redirect        = 7876
        log_on_failure  += USERID
        log_on_success  += PID HOST EXIT DURATION

... seemed that setting the protocol is useful (since I know it is tcp), and setting the port is required (since 'myservice' isn't in services...).  anyway, again, I need to see if my embedded box is working correctly, as I would have thought that would 'just work'...

Redimido: that was basically what I had thought I could do.  but here's my problem:
- I do that, and type iptables --list, and don't see the rules (I assume I should).  In fact, PREROUTING and POSTROUTING aren't listed as default chains (it lists FORWARD/INPUT/OUTPUT).  I tried to create them as new chains (don't think I should have to, but tried), and they show up without any rules -- I assume the rules should show up when I do a --list command.
- I found a reference on the net to forwarding port 80 external to port 8080 on an internal box.  That had some addition FORWARD commands, so I added them to my rc.local.  lo and behold, THEY show up in the --list, but the two NAT commands don't still.  weird.
- as to your questions, yes, I can ping and telnet into the embedded box, and yes, I'm not otherwise using iptables already.
- so... this method doesn't seem to be even getting initialized for me.  Though, like xinetd approach, seems it would 'just work' if everything was correct.

I'm going to go back and verify with others that the custom protocol is set up and working on my embedded box (assuming there's an easy way to do that...), and then I can at least quickly re-enable the xinetd service and see if that works.

I've upped the points to 500 so I can split if needed.


PRE and POST routing are NOT part of the filter chain, but rather part of mangle:

# iptables -t mangle -L -vn

This article: http://www.linuxnetmag.com/en/issue9/m9iptables1.html has this diagram: http://www.linuxnetmag.com/share/issue9/iptables3.jpg which shows how the tables all fit together!

davebytesAuthor Commented:
actually, this article had an even better diagram... ;)

seems to indicate that PRE and POST can be rules in 'nat' or 'mangle'.  the rules you gave me were -t nat.

running "iptables -t nat -L -vn" results in:
Chain OUTPUT (policy ACCEPT 5 packets, 502 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 7 packets, 694 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  tcp  --  *      eth1             tcp dpt:7876

Chain PREROUTING (policy ACCEPT 2 packets, 126 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  eth0   *             tcp dpt:7876 to:

Aside from the src/dst fields being unset (which I'm guessing I could add to the commands if needed), the rest of the output looks correct for the rules given.

I'll let you know as soon as I can test/prove the embedded box is set up and working correctly (which, since it was handed to me I assume it should be, but...).

I like that diagram too!  The flow of nat and mangle is clear, it's the usages that aren't... The reason those diagrams are important is that in Linux  2.4 kernel, packets could hit TWO places in the 'filter' chain and it wasn't always clear where to put rules for what purpose.  With 2.6 there's only ONE place, but it's easy to get confused.

FWIW, (ideally) the nat table is used only for Network Address Translation and the mangle table for changing packet contents (TOS, etc.) but as you have found they're VERY useful for a lot of other purposes.

Personally?  I really like using mangle for blacklist/blackhole - it's just too nice to be able to do it fast, early and dirty...

davebytesAuthor Commented:
BTW, I've been trying netstat -l on my embedded box, and I'm not actually seeing a listening port waiting for the connection -- so there's obviously something else wrong on my system (which I've been told should be working!) that I need to fix before I can properly test the approaches.  I'll keep y'all posted. ;)

Gabriel OrozcoSolution ArchitectCommented:
if your embedded box has its system depending upon inetd or xinetd, then you will never see a port listening. it's inetd the one that will launch the program once a packet arrives on the port.

good luck
davebytesAuthor Commented:
right.  no, it's a custom application which should be opening a listening port, but doesn't seem to.  I'm trying to verify with a coworker that netstat does indeed show it waiting.

> if your embedded box has its system depending upon inetd or xinetd, then you will never see a port listening.

Hmm, IMHO not correct. When a service is started by inetd, this does not mean, that this service has no listen socket. A pop3-daemon started by inetd for example needs a listen socket on port 110 anyway - it's just that this socket isn't bound by the pop3d, but by (x)inetd. This concept just centralizes the basic IP operations and makes development of network services much easier, since you do not have to care about all that IP-related stuff. Example:

while true
  read line
  echo "$line"

Save this snippet as echo.sh. Configure it as service in inetd.conf, bind it to e.g. port 10000. Telnet on that port and - voila - you have a full functional echo service.
As you can see, the code above doesn't do any socket operations, so the listen socket has to be bound by inetd.

Back to the basic problem:

> iptables -t nat -A POSTROUTING -p tcp --dport 8888 -o eth1 -j MASQUERADE

MASQUERADE is not the best choosen target in this case, SNAT is to be preferred here, since we have static IPs.
Depending on the default policy, it furthermore might be necessary to allow the forwarded packets in the FORWARD chain.
So the complete ruleset would look like that:

echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -I PREROUTING -i eth0 -p tcp --dport 8888 -j DNAT --to-destination
iptables -t nat -I POSTROUTING -p tcp --dport 8888 -o eth1 -j SNAT --to-source
iptables -I FORWARD -p tcp -i eth0 -o eth1 --dport 8888 -j ACCEPT

A completely different approach:
Assign a second IP Address out of the network (e.g. to the XP-box. Then enable proxy-arp:

echo "1" > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp
ip route del dev eth0
ip route del dev eth1
ip route add dev eth0
ip route add dev eth1


Gabriel OrozcoSolution ArchitectCommented:

XoF: you're right. it's inet the one will show listening at the port =) not his program.

for the MASQUERADE thing: I didn't know wat the ip on the embedded side can be. Besides masquerade is just good when ip's are static.

proxy arp solution is good too ;-)
> for the MASQUERADE thing: I didn't know wat the ip on the embedded side can be

I assumed that reason for your decision to use MASQUERADE when I reached the point to insert an IP-Address in the SNAT rule...;)
davebytesAuthor Commented:
Hey all -

I appreciate the various approaches/inputs.  I tried to spread points around a bit, based on how close the solution was to what I was looking for.  I never did get the remote service up and running properly, so figured best to close this given the answers are all 'within bounds' of what I needed (will need...).


It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Networking

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.