/proc/.../ip_forward and own interfaces

my router has:
   kernel 2.4.18
   eth0 10.0.1.1 netmask 255.255.255.0
   eth1 10.0.2.1 netmask 255.255.255.0
   echo 0 > /proc/sys/net/ipv4/ip_forward
   netroutes (with above netmasks) for both nets

Now I can see 10.0.2.1 from any 10.0.1.x . Something I don't want, for obvious reason :-)

How can I tell the kernel (/proc/sys/net/...) not to route its own IPs?
Even following does not help:
  iptables -F FORWARD
  iptables -P FORWARD DROP
LVL 51
ahoffmannAsked:
Who is Participating?
 
MFCRichConnect With a Mentor Commented:
iptables -I INPUT -i eth0 -d 10.0.2.1 -j DROP

No forwarding is involved when a packet comes in on one interface destined for another interface on the same machine.
0
 
ahoffmannAuthor Commented:
thanks MFCRich,
this is a workaround, I'll leave the question open to see if someone knows more about:

> No forwarding is involved when a packet comes in on one interface destined for another interface on the same machine.
0
 
The--CaptainCommented:
I'm not sure why you're calling it a workaround - the behaviour of the linux kernel (using iptables) has fundamentally changed from the way you expect it to work - the docs say that now packets will not traverse all three chains before being delivered locally.  Period.  Therefore, I think MFC Rich's solution is the only one (or at least the most straightforward) that you're going to find.  I vote for pts for MFCRich.

I can see why the developers did this - it presumably saves a ton of time not to have to check those rules, nor invoke all the commensurate code involved with 'forwarding'.  If you had a RFC1918 LAN that accessed services on a machine in tha same LAN via it's additional public IP, you would appreciate the speed increase, methinks.  If you don't want this new 'feature', MFCRich's solution works quite nicely (and presumably does *not* take much more time than checking if forwarding is denied)

Cheers,
-Jon

0
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

 
ahoffmannAuthor Commented:
Jon voted for this solution. I'll agree ;-)

Jon, I thought using the packetfilter is a workaround, 'cause I was searching for kernel-based (TCP/IP stack) solution. The netfilter is part of the 2.4 kernel, so this is a "kernel-based" solution too.

It's just curious, 'cause I've not seen other Unixs behave this way.
I'm willing to share the point if you can point me to the description of this behaviour in the the Linux docs. I'm really interested in a detailed description 'cause I think this is something you *have* to know when building firewalls.
0
 
The--CaptainCommented:
You make a good point about this being part of netfilter - one wonders what behaviour the old ipchains module would exhibit...

You gotta gimme a bit to come up with that reference - I came across it when looking over a bunch of docs for some VPN work I was doing - I found it interesting at the time but didn't give much thought to actual integration implications until I saw your question and thought "So *that's* what they were talking about in those docs I saw".  One of the reasons I didn't vote for myself for pts is because I don't have the reference immediately handy.  Now that I think about it, it was surely in the context of VPN - someone was complaining that they could only ping the VPN server over the IPSEC tunnel, and was referred to the docs that mention that xplicit forwarding would need to be turned on, since only local delivery works without it (and I'm pretty sure they were talking about that being new in 2.4).

Cheers,
-Jon

0
 
ahoffmannAuthor Commented:
hmm, in VPN context ..
I know what you mean: when using IPSEC (for example with FreeS/WAN, you remeber me?:), you cannot ping the remote endpoint of the tunnel, but anything behind.
This is a restriction in FreeS/WAN's implementation, not shure if i.g. for IPSEC (but think so).
This beahiour is kind of opposite to my question here, 'cause IPSEC restricts you to use the interface behind, while I want to avoid access to this interface behind.

But it's nice that you remember this discussion, I should have thought about it myself, 'cause I gave comments and suggestion to that question too ;-)
0
 
The--CaptainCommented:
I know what you're talking about wrt IPSEC, and that's not what I was talking about...  What I was talking about was the difficulty in diagnosing filter chains once the VPN is connected because the remote side can ping the VPN server's private IP and not have to endure the forwarding rulesets (sometimes causing the weird behaviour of [remote guy]: "I can ping your VPN server's private IP, but none of the other machines on that subnet...").  You'd see the same thing in any config that was setup with 2 different subnets on two different interfaces, regardless of whether there was a VPN or not...

Cheers,
-Jon

0
All Courses

From novice to tech pro — start learning today.