iptables: fake ip using DNAT and SNAT

[Bjørnar Libæk]

Is it possible to do the following with iptables:

Computer A runs iptables, and communicates with B. What I want is to
manipulate the IP address of B (using iptables at A), so that the
applications running on computer A only see a "fake" addres for B.

The job should not be difficult. When packets arrive at A matching B's
real ip address, replace source addres with the fake one. Whe packets
originating at A with the fake ip as destination address, replace it
with B's real address. (a simple one-to-one mapping).

The problem: SNAT (source address manipulation) is only performed in the
POSTROUTING chain, and DNAT (destination address manipulation) is only
performed in the PREROUTING chain. I guess what I want is the opposite?


Thanks for any help!

[Davide Bianchi]

Post by Bjørnar Libæk
Computer A runs iptables, and communicates with B. What I want is to
manipulate the IP address of B (using iptables at A), so that the
applications running on computer A only see a "fake" addres for B.

Ok, this is your solution, now explain your problem.

Davide

[Bjørnar Libæk]

Davide Bianchi wrote:

(...)

Post by Davide Bianchi
Ok, this is your solution, now explain your problem.

If you must know:) I'm using hamachi (http://www.hamachi.cc) to connect
computers to a "virtual lan". Hamachi assigns IP address out of the
5.0.0.0/8 address pool, but I want the computers in my virtual LAN to
have addresses in the same clas C subnet (because my application
requires it). The windows client for hamachi has an "aliasing" feature,
where you can map ip addresses and get the functionality I explained in
the previous post. The linux client doesn't have this feature, but I've
read in the hamachi discussion forum that iptables will probably do the
trick.
(http://forums.hamachi.cc/viewtopic.php?t=5676&highlight=aliasing+txt).
However, I've not yet seen the exact rules!!

Now, please get back to the topic:)

[Grant]

Post by Bjørnar Libæk
5.0.0.0/8 address pool, but I want the computers in my virtual LAN to

Non-allocated IPs should not be used for anything.

You have all of 10.0.0.0/8 to play in.

Grant.

[Bjørnar Libæk]

Post by Grant

Post by Bjørnar Libæk
5.0.0.0/8 address pool, but I want the computers in my virtual LAN to

Non-allocated IPs should not be used for anything.
You have all of 10.0.0.0/8 to play in.

Please direct your frustration to the hamachi developers, then:) To
their defence, hamachi *is* tunneling, and the 5.0.0.0 addresses are not
routed in the Internet. Bet you didn't know that:)

[Davide Bianchi]

Post by Bjørnar Libæk
If you must know:) I'm using hamachi (http://www.hamachi.cc) to connect
computers to a "virtual lan". Hamachi assigns IP address out of the
5.0.0.0/8 address pool

Ah-ehmmm... so, with about a dozen different VPN solutions, you are using
one that is broken... I mean, every VPN product I've seen so far allow you
to use whichever IP subnet/class you want for your VPN, this is the only
one I heard of that require HIS OWN fixed-unmutable ip class...

Post by Bjørnar Libæk
have addresses in the same clas C subnet (because my application
requires it). The windows client for hamachi has an "aliasing" feature,
where you can map ip addresses and get the functionality I explained in
the previous post. The linux client doesn't have this feature

Well, you could "fake it" by aliasing the IP you want to a network interface
and then force the routing throught the vpn link. As long as the machine
recognise the IP as his own and know how to route the packets it should be
ok. But the question remains: why try to fix something that is obviously
broken using workaround instead of using something that is not broken?

Davide

[Bjørnar Libæk]

Davide Bianchi wrote:

(...)

Post by Davide Bianchi
Ah-ehmmm... so, with about a dozen different VPN solutions, you are using
one that is broken... I mean, every VPN product I've seen so far allow you
to use whichever IP subnet/class you want for your VPN, this is the only
one I heard of that require HIS OWN fixed-unmutable ip class...

I agree, it would be nice to have the possibility to choose the address
range. The reason why I've chosen hamachi is the simple
"zero-configuration vpn" aswell as allowing secure p2p communication.
And it's free. No need to set up a vpn server, as there is a centralised
server hosted by hamachi. I'm sure we could have a long discussion on
whether this is a good solution or not, but please spare me:) I should
also mention that the linux version is 0.9.9.9, so classifying it as
"broken" may be unfair.

(...)

Post by Davide Bianchi
But the question remains: why try to fix something that is obviously
broken using workaround instead of using something that is not broken?

Well, if you could point me to some alternative solution, I'd be
gratefull, but it should be as easy to setup as hamachi. I don't think
you can:)

[Davide Bianchi]

Post by Bjørnar Libæk
also mention that the linux version is 0.9.9.9, so classifying it as
"broken" may be unfair.

In my world, everything that doesn't do what I want, they way I want,
is classified as "does not work" (addition: "for me").

Post by Bjørnar Libæk
Well, if you could point me to some alternative solution, I'd be
gratefull, but it should be as easy to setup as hamachi. I don't think
you can:)

Well... it all boils down to what you mean for "easy". I had no trouble
in setting up OpenVPN, or Freeswan or Cipe... but if hamachi is so good
for you...

Maybe you should ask their developers. Frankly, I can't see how mangling
iptable could fix your problem. I hope (for you) that someone could prove
me wrong.

Davide

[Bjørnar Libæk]

Post by Davide Bianchi
Well... it all boils down to what you mean for "easy". I had no trouble
in setting up OpenVPN, or Freeswan or Cipe... but if hamachi is so good
for you...

I have little/no experience setting up vpns, but as I understand,
generally you have a server and client(s) configuration. All data
packets are routed through the server. With hamachi, there is no server
in the same sence. Direct tunnels are set up between every peer in the
network. This is efficient if you need peer to peer communication. What
I mean with "easy" is:

*install client
*start client
*enter network name
*enter nework password.

This is done on all clients, no server to configure. All clients can
communicate as if they where connected to the same LAN.

Post by Davide Bianchi
Maybe you should ask their developers. Frankly, I can't see how mangling
iptable could fix your problem. I hope (for you) that someone could prove
me wrong.

I have asked them, but I'm impatient:)

[Bjørnar Libæk]

Davide Bianchi wrote:

(...)

Post by Davide Bianchi
Well, you could "fake it" by aliasing the IP you want to a network interface
and then force the routing throught the vpn link. As long as the machine
recognise the IP as his own and know how to route the packets it should be
ok.

Thanks, but I'm not sure what you mean. By "aliasing the the IP" to a
network interface, you mean at computer B? This is not an option.
Computer B (and all other peers) should not be aware of the aliasing.
Maybe I totally missunderstand what you're saying..

At computer A, there is a virtual interface ham0, which is the tunnel
endpoint.

[Davide Bianchi]

Post by Bjørnar Libæk
Thanks, but I'm not sure what you mean. By "aliasing the the IP" to a
network interface, you mean at computer B? This is not an option.
Computer B (and all other peers) should not be aware of the aliasing.
Maybe I totally missunderstand what you're saying..

Hummm... then I don't see how you could trick one in thinking that the
others has a different IP without telling to the others. Even if you can
mangle the ip table the machine that is supposed to receive the packets
will discard them or route them away because it won't recognize them
as 'his own'. But maybe someone else has a different idea.

Davide

[Bjørnar Libæk]

Post by Davide Bianchi
Hummm... then I don't see how you could trick one in thinking that the
others has a different IP without telling to the others. Even if you can
mangle the ip table the machine that is supposed to receive the packets
will discard them or route them away because it won't recognize them
as 'his own'. But maybe someone else has a different idea.

The thing is, that computer B will always send and receive packets with
its real IP address. The fake address is only visible to the application
at computer A. The problem you describe regarding recognizing it's own
address will never occure.

Let's walk through this:
Computer B sends a packet to A using its real address as source address.
The packet is forwarded through the tunnel, and finally received at the
ham0 interface at computer A. Now, before this packet reaches the
application at A, I want it to change the *source* address of the packet
to say, B_fake. (A natural place to do this would be in the PREROUTING
chain.) The application will receive the packet, imagening that it was
sent by computer with address B_fake.

When application at A now wants to send a packet to B (beleiving that
B's address is B_fake), it sends a packet with destination address
B_fake. Now, what I want is that B_fake is replaced with the real
address of B before being forwarded to the ham0 interface. A natural
place to do this is in the POSTROUTING chain. The packet sent through
the tunnel will be destined to B's real address, and B will accept it.

So this would work:) (and it certainly works in the windows client of
hamachi) My question is if iptables has these capabilities or not?? If
not, I will certainly bug the developers of hamachi about this, asking
them to include the aliasing feature in the linux client also. (I
suppose bugging the developers of iptables is less fruitful:)

_______________________________________________
computer A |
__________________ |
|POSTROUTING | |
______ | (swap addresses) | ______ |
|--->|__________________| --->| | |
App | ___________________ | ham0 | <---Tunnel---> B
______|<---|PREROUTING | <---|______| |
| (swap addresses) | |
|__________________| |
|
_______________________________________________|

------(B_fake)-----><--------------(B_real)--------------------


(really hope this figure is readable, because I spent much time on it)

[Robert Nichols]

In article <e0r3nu$rd2$***@orkan.itea.ntnu.no>,
=?ISO-8859-1?Q?Bj=F8rnar_Lib=E6k?= <***@gmail.com> wrote:
:Let's walk through this:
:Computer B sends a packet to A using its real address as source address.
:The packet is forwarded through the tunnel, and finally received at the
:ham0 interface at computer A. Now, before this packet reaches the
:application at A, I want it to change the *source* address of the packet
: to say, B_fake. (A natural place to do this would be in the PREROUTING
:chain.) The application will receive the packet, imagening that it was
:sent by computer with address B_fake.
:
:When application at A now wants to send a packet to B (beleiving that
:B's address is B_fake), it sends a packet with destination address
:B_fake. Now, what I want is that B_fake is replaced with the real
:address of B before being forwarded to the ham0 interface. A natural
:place to do this is in the POSTROUTING chain. The packet sent through
:the tunnel will be destined to B's real address, and B will accept it.
:
:So this would work:) (and it certainly works in the windows client of
:hamachi) My question is if iptables has these capabilities or not?? If
:not, I will certainly bug the developers of hamachi about this, asking
:them to include the aliasing feature in the linux client also. (I
:suppose bugging the developers of iptables is less fruitful:)
:
:________________________________________________
: computer A |
: __________________ |
: |POSTROUTING | |
:______ | (swap addresses) | ______ |
: |---->|__________________|--->| | |
:App | ___________________ | ham0 | <---Tunnel---> B
:______|<----|PREROUTING |<---|______| |
: | (swap addresses) | |
: |__________________| |
: |
:________________________________________________|
:
:------(B_fake)-----><--------------(B_real)--------------------
:
:
:(really hope this figure is readable, because I spent much time on it)

[I touched up the figure just a bit.]

For packets sent by A it's really not a big problem. You just need to
use a combination of iptables(8) and route(8). Do the DNAT translation
in PREROUTING, where it belongs. Then use the 'route' command to route
packets directed to the real address of B to the ham0 interface.

route add -host real.addr.of.B ham0

For connections originated by machine A the reverse translation will
happen automatically.

For connections originated by B to A, then you need to use the features
of policy routing do the SNAT processing. For info on policy routing
see the manpage for the ip(8) command. That's getting somewhat outside
my experience, so I can't be more specific.

[Bjørnar Libæk]

Post by Robert Nichols
For packets sent by A it's really not a big problem. You just need to
use a combination of iptables(8) and route(8). Do the DNAT translation
in PREROUTING, where it belongs. Then use the 'route' command to route
packets directed to the real address of B to the ham0 interface.
route add -host real.addr.of.B ham0
For connections originated by machine A the reverse translation will
happen automatically.

First of all, thanks:) But I still can make this work.. I'v done the
following at A:

[***@A]# iptables -A PREROUTING -t nat -d fake.addr.of.B -j DNAT
--to-destination real.addr.of.B

[***@A]# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT all -- anywhere fake.addr.of.B to:real.addr.of.B
(...)

[***@A]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
localnet * 255.255.255.128 U 0 0 0 eth0
5.0.0.0 * 255.0.0.0 U 0 0 0 ham0
default gw.x.x 0.0.0.0 UG 0 0 0 eth0


Then, I use two simple programs (talker.c and listener.c) [1] to do the
testing. listener.c runs at B, and listens on port 4950. When a packet
arrives, it prints the source ip address. talker.c runs at A, and sends
a udp packet to the host given as parameter on the command line.
When doing no nat'ing, this works fine. The outgoing packet shows up in
tcpdump (on A) like this:

11:24:37.821028 IP addr.of.A.33163 > real.addr.of.B.4950: UDP, length 6

However, when using the configuration above, and using the fake
address of B as input to talker.c, A sends out arp request on the fake
address. Then I add a "dummy" arp entry for the fake address, and now
the packet shows up like this:

11:45:29.223057 IP addr.of.A.33166 > fake.addr.of.B.4950: UDP, length 6

i.e, no address translation has been performed! (I assume translation
shuld be done *before* being captured by tcpdump??) Also, nothing is
received at B.

Post by Robert Nichols
For connections originated by B to A, then you need to use the features
of policy routing do the SNAT processing. For info on policy routing
see the manpage for the ip(8) command. That's getting somewhat outside
my experience, so I can't be more specific.

Thanks, I will look more into this later. I have however allready tried:

[***@A] ip rule add nat real.addr.of.B from fake.addr.of.B

but with no luck..


[1]
http://www.coding-zone.co.uk/cpp/articles/140101networkprogrammingv.shtml

[Robert Nichols]

In article <e0tfi4$2ea$***@orkan.itea.ntnu.no>,
=?ISO-8859-1?Q?Bj=F8rnar_Lib=E6k?= <***@gmail.com> wrote:
:
:First of all, thanks:) But I still can make this work.. I'v done the
:following at A:
:
:[***@A]# iptables -A PREROUTING -t nat -d fake.addr.of.B -j DNAT
:--to-destination real.addr.of.B
:
:[***@A]# iptables -t nat -L
:Chain PREROUTING (policy ACCEPT)
:target prot opt source destination
:DNAT all -- anywhere fake.addr.of.B to:real.addr.of.B
:(...)
:
:[***@A]# route
:Kernel IP routing table
:Destination Gateway Genmask Flags Metric Ref Use Iface
:localnet * 255.255.255.128 U 0 0 0 eth0
:5.0.0.0 * 255.0.0.0 U 0 0 0 ham0
:default gw.x.x 0.0.0.0 UG 0 0 0 eth0
:
:
:Then, I use two simple programs (talker.c and listener.c) [1] to do the
:testing. listener.c runs at B, and listens on port 4950. When a packet
:arrives, it prints the source ip address. talker.c runs at A, and sends
:a udp packet to the host given as parameter on the command line.
: When doing no nat'ing, this works fine. The outgoing packet shows up in
:tcpdump (on A) like this:
:
:11:24:37.821028 IP addr.of.A.33163 > real.addr.of.B.4950: UDP, length 6
:
: However, when using the configuration above, and using the fake
:address of B as input to talker.c, A sends out arp request on the fake
:address. Then I add a "dummy" arp entry for the fake address, and now
:the packet shows up like this:
:
:11:45:29.223057 IP addr.of.A.33166 > fake.addr.of.B.4950: UDP, length 6
:
:i.e, no address translation has been performed! (I assume translation
:shuld be done *before* being captured by tcpdump??) Also, nothing is
:received at B.

Oops!! We both made the same mistake. Packets that originate on the
local machine don't go through PREROUTING. You need to put that DNAT
rule in the OUTPUT chain:

iptables -t nat -A OUTPUT ...

If you haven't done so already, get Oskar Andreasson's excellent
Iptables Tutorial, available in several formats from

http://iptables-tutorial.frozentux.net/

:> For connections originated by B to A, then you need to use the features
:> of policy routing do the SNAT processing. For info on policy routing
:> see the manpage for the ip(8) command. That's getting somewhat outside
:> my experience, so I can't be more specific.
:>
:
:Thanks, I will look more into this later. I have however allready tried:
:
:[***@A] ip rule add nat real.addr.of.B from fake.addr.of.B
:
:but with no luck..

Did you run "ip route flush cache" after installing that rule? As I
said, this is getting into stuff I've never tried.

[Bjørnar Libæk]

Robert Nichols wrote:

(...)

Post by Robert Nichols
:--to-destination real.addr.of.B

(...)

Post by Robert Nichols
Oops!! We both made the same mistake. Packets that originate on the
local machine don't go through PREROUTING. You need to put that DNAT
iptables -t nat -A OUTPUT ...

You're abselutely correct! This works now:) But as you mention earlier,
only for connections initiated from A.

(...)

Post by Robert Nichols
:but with no luck..
Did you run "ip route flush cache" after installing that rule? As I
said, this is getting into stuff I've never tried.

No, I didn't, but I have now, and it still doesn't work. Also, after a
good night's sleep, I swapped the addresses in the command above. So the
following is what I have so far (which doesn't work):

[***@A] ip rule add nat fake.addr.of.B from real.addr.of.B
[***@A] ip route flush cache

I.e, the application receieves the real source address, so the
replacement never happens. Is there anyway to monitor the routing
decissions, or anyone has some debugging advice in this situation?

Another thing, the "ip rule add nat" command reports to be deprecated.
Why is this? Either, it's assumed that replacing the source address in
the input of a router is not necessary, or there should be an
alternative way to do this. As I understand, iptables is not an
alternative, because SNAT is only available in the POSTROUTING chain.

[Robert Nichols]

In article <e12lja$vfm$***@orkan.itea.ntnu.no>,
=?ISO-8859-1?Q?Bj=F8rnar_Lib=E6k?= <***@gmail.com> wrote:
:
:[***@A] ip rule add nat fake.addr.of.B from real.addr.of.B
:[***@A] ip route flush cache
:
:I.e, the application receieves the real source address, so the
:replacement never happens. Is there anyway to monitor the routing
:decissions, or anyone has some debugging advice in this situation?
:
:Another thing, the "ip rule add nat" command reports to be deprecated.
:Why is this? Either, it's assumed that replacing the source address in
:the input of a router is not necessary, or there should be an
:alternative way to do this. As I understand, iptables is not an
:alternative, because SNAT is only available in the POSTROUTING chain.

Looking at the manpage for ip(8) on my FC-5 machine, I see, "Warning:
Route NAT is no longer supported in Linux 2.6."

Thinking about this a bit, what bothers me is why packets arriving via
the ham0 tunnel haven't already had their source addresses translated to
one in the 5.0.0.0 network. If B thinks it is communicating with its
real address and you send back a reply to fake.addr.of.B, _something_
will have to translate that back to real.addr.of.B or else B won't
recognize the reply and associate it with the right connection.
Whatever is doing that translation should already have modified the
source address in the original packet received by A.

You can force the translation on machine A by routing packets out the
loopback interface (policy routing based on source of real.addr.of.B)
and doing the SNAT translation on the way out. Deliver them to the
local process when they come back in. But, unless you arrange for reply
packets to follow that same loop back, you're going to end up with two
half-open UNREPLIED conntrack entries. That's likely to make
communication unreliable, if it even works at all.

[Bjørnar Libæk]

Post by Robert Nichols
Route NAT is no longer supported in Linux 2.6."

Ok.. that's why. I guess I could do a reboot using my old 2.4 kernel.
But still, why removing this functionallity in 2.6? Beats me.

Post by Robert Nichols
Thinking about this a bit, what bothers me is why packets arriving via
the ham0 tunnel haven't already had their source addresses translated to
one in the 5.0.0.0 network. If B thinks it is communicating with its
real address and you send back a reply to fake.addr.of.B, _something_
will have to translate that back to real.addr.of.B or else B won't
recognize the reply and associate it with the right connection.
Whatever is doing that translation should already have modified the
source address in the original packet received by A.

No, I think maybe you forget about the concept of tunneling. Both real
and fake addresses are in the 5.0.0.0 network. When a packet is destined
to an address in this network, the packet is routed to the ham0 inteface
(as normal). This "interface" will then encrypt the content, and
encapsulate the original packet with a new IP header using the "really
real" routable ip addresses of the computers (eth0). No "translation"
necessary here, only adding and stripping IP headers.

Post by Robert Nichols
You can force the translation on machine A by routing packets out the
loopback interface (policy routing based on source of real.addr.of.B)
and doing the SNAT translation on the way out. Deliver them to the
local process when they come back in. But, unless you arrange for reply
packets to follow that same loop back, you're going to end up with two
half-open UNREPLIED conntrack entries. That's likely to make
communication unreliable, if it even works at all.

This is starting to get ugly, but I had to try:) Now there seems to bee
som issues about the source based routing. I created a new routing table
like this:

[***@A] echo "100 hamsrc" >> /etc/iproute2/rt_tables
[***@A] ip route add 5.0.0.0/8 dev lo table hamsrc

and added the source routing policy entry like this:

[***@A] ip rule add from real.addr.of.B table hamsrc
[***@A] ip route flush cache

finally, I added SNAT on POSTROUTING for lo interface

[***@A] iptables -A POSTROUTING -t nat -o lo -s real.addr.of.B -j SNAT
--to-source fake.addr.of.B

But the packet still arrives to the application without being SNAT'ed,
and "tcpdum -i lo" is quiet like a child on its mother's breast. Any
obvious mistakes here? And yes, /proc/sys/net/ipv4/ip_forward is '1'.

I will try the kernel 2.4 approach sometime soon, but I'm really
starting get tired of this whole matter..

[Andy Furniss]

Post by Bjørnar Libæk
I will try the kernel 2.4 approach sometime soon, but I'm really
starting get tired of this whole matter..

I can't tell you how to do it, but on 2.6 there is an iptables (may need
to patch - pom) target called ROUTE which may (or may not) help.

If you are going to try stateless nat in 2.4 there are examples IIRC on
Martin A Browns site linux-ip.net.

I would be trying just iptables on 2.6 or just stateless on 2.4 not a
mixture.

Andy.

[Robert Nichols]

In article <e15dj8$95c$***@orkan.itea.ntnu.no>,
=?ISO-8859-1?Q?Bj=F8rnar_Lib=E6k?= <***@gmail.com> wrote:
:Robert Nichols wrote:
:
:> Looking at the manpage for ip(8) on my FC-5 machine, I see, "Warning:
:> Route NAT is no longer supported in Linux 2.6."
:
:Ok.. that's why. I guess I could do a reboot using my old 2.4 kernel.
:But still, why removing this functionallity in 2.6? Beats me.
:
:> Thinking about this a bit, what bothers me is why packets arriving via
:> the ham0 tunnel haven't already had their source addresses translated to
:> one in the 5.0.0.0 network. If B thinks it is communicating with its
:> real address and you send back a reply to fake.addr.of.B, _something_
:> will have to translate that back to real.addr.of.B or else B won't
:> recognize the reply and associate it with the right connection.
:> Whatever is doing that translation should already have modified the
:> source address in the original packet received by A.
:
:No, I think maybe you forget about the concept of tunneling. Both real
:and fake addresses are in the 5.0.0.0 network. When a packet is destined
:to an address in this network, the packet is routed to the ham0 inteface
:(as normal). This "interface" will then encrypt the content, and
:encapsulate the original packet with a new IP header using the "really
:real" routable ip addresses of the computers (eth0). No "translation"
:necessary here, only adding and stripping IP headers.

The problem with not using actual IP address in these messages is that
it hides the information that the real address of B is in the ham0
tunnel. I was thinking it was not, and was guessing at what the heck
might be happening. Going back to the start of the thread I see that
the tunnel is really irrelevant to the problem.

:> You can force the translation on machine A by routing packets out the
:> loopback interface (policy routing based on source of real.addr.of.B)
:> and doing the SNAT translation on the way out. Deliver them to the
:> local process when they come back in. But, unless you arrange for reply
:> packets to follow that same loop back, you're going to end up with two
:> half-open UNREPLIED conntrack entries. That's likely to make
:> communication unreliable, if it even works at all.
:
:
:This is starting to get ugly, but I had to try:) Now there seems to bee
:som issues about the source based routing. I created a new routing table
:like this:
:
:[***@A] echo "100 hamsrc" >> /etc/iproute2/rt_tables
:[***@A] ip route add 5.0.0.0/8 dev lo table hamsrc
:
:and added the source routing policy entry like this:
:
:[***@A] ip rule add from real.addr.of.B table hamsrc
:[***@A] ip route flush cache
:
:finally, I added SNAT on POSTROUTING for lo interface
:
:[***@A] iptables -A POSTROUTING -t nat -o lo -s real.addr.of.B -j SNAT
:--to-source fake.addr.of.B
:
:But the packet still arrives to the application without being SNAT'ed,
:and "tcpdum -i lo" is quiet like a child on its mother's breast. Any
:obvious mistakes here? And yes, /proc/sys/net/ipv4/ip_forward is '1'.
:
:I will try the kernel 2.4 approach sometime soon, but I'm really
:starting get tired of this whole matter..

I'm giving up. This is beyond me.