[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    [Fwd: IPF-FAQ]
From:       Phil Dibowitz <phil () ipom ! com>
Date:       2004-05-18 18:17:39
Message-ID: 40AA5343.7090307 () ipom ! com
[Download RAW message or body]


People seem to like sending me IPF questions... someone care to answer 
this one? I'm killer busy with work... I'll throw answers into a folder 
and read over the thread next time I update the FAQ to see if it should 
go in there.

-------- Original Message --------
Subject: IPF-FAQ
Date: Wed, 19 May 2004 01:25:47 +0800
From: Simon Rho <srho@juniper.net>
To: <phil@ipom.com>

Hello phil,

I am struggling to find fact regarding rdr configuration of ipnat.
Normally, the destination address translated by "rdr" keyword should 
flow to the same incoming interface to be reset to the original destination.
But is there any config to reset original destination address through 
*another* egress interface
For example.

incoming interface eth0(10.0.0.1:80) -> rdr(192.168.254.1:8080) -> 
kernel -> rdr(10.0.0.1:80) -> outgoing interface eth1

When the incoming interface and outgoingg interface are same, the rdr 
should be working well for recovering the original destination.
But in case that we need to use different outgoing interface for rdr, is 
there any config to implement this?

Thank you and regards,

/Simon Rho from Korea.

PS, I need this feature because I don't like to setup static route 
pointed to ip-in-ip tunnel incoming interface(for my application multi 
thousand of static route should be configured to ip-in-ip tunnel interface).








-- 
Phil Dibowitz                             phil@ipom.com
Freeware and Technical Pages              Insanity Palace of Metallica
http://www.phildev.net/                   http://www.ipom.com/

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
  - Benjamin Franklin, 1759


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]