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 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
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
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Ah
PRE and POST routing are NOT part of the filter chain, but rather part of mangle:
# iptables -t mangle -L -vn
-----Burton
PRE and POST routing are NOT part of the filter chain, but rather part of mangle:
# iptables -t mangle -L -vn
-----Burton
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!
-----Burton
-----Burton
ASKER
actually, this article had an even better diagram... ;)
http://www.siliconvalleyccie.com/linux-hn/iptables-intro.htm
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
http://www.siliconvalleyccie.com/linux-hn/iptables-intro.htm
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
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
ASKER
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
-d
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
good luck
ASKER
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.
-d
-d
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hello
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 ;-)
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...;)
I assumed that reason for your decision to use MASQUERADE when I reached the point to insert an IP-Address in the SNAT rule...;)
ASKER
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
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
ASKER
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