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 192.168.0.66 on the local lan, the embedded box is 10.0.0.101 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..). ;)
-d
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
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 = 10.11.12.13 9999
only_from = 10.0.0.0/16
log_on_failure += USERID
log_on_success += PID HOST EXIT DURATION
}
and activate the xinetd daemon in /etc/init.d
add this in your rc.local file:
#this enables forward so packets can traverse the firewall:
echo "1" > /proc/sys/net/ipv4/ip_forw
#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 10.0.0.101:8888
#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
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 = 10.0.0.101 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.
-d
This article: http://www.linuxnetmag.com
-----Burton
actually, this article had an even better diagram... ;)
http://www.siliconvalleycc
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 0.0.0.0/0 0.0.0.0/0 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 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:7876 to:10.0.0.101:7876
==========================
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...).
-d
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...
-----Burton
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. ;)
-d
> 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:
#!/bin/sh
while true
do
read line
echo "$line"
done
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_forw
iptables -t nat -I PREROUTING -i eth0 -p tcp --dport 8888 -j DNAT --to-destination 10.0.0.101:8888
iptables -t nat -I POSTROUTING -p tcp --dport 8888 -o eth1 -j SNAT --to-source 10.0.0.1
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 10.0.0.0 network (e.g. 10.0.0.200) to the XP-box. Then enable proxy-arp:
echo "1" > /proc/sys/net/ipv4/ip_forw
echo 1 > /proc/sys/net/ipv4/conf/et
echo 1 > /proc/sys/net/ipv4/conf/et
ip route del 10.0.0.0/24 dev eth0
ip route del 10.0.0.0/24 dev eth1
ip route add 10.0.0.200 dev eth0
ip route add 10.0.0.0/24 dev eth1
Cheers,
-XoF-
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...).
Thanks!
-d
Business Accounts
Answer for Membership
by: bstrauss3Posted on 2006-04-18 at 08:51:47ID: 16479156
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/
-----Burton