On 09/10/07 07:18, vinod K D wrote:
My gateway has two network interfaces: eth0 & eth1.
eth0 (192.168.1.1) is connected to public network and eth1 (10.0.1.1)
is connected to LAN.
MyServer, which is in the LAN, has ip 10.0.1.2.
Ok, reasonable enough.
I created a virtual interface eth0:0 (192.168.1.2) in the gateway.
Using ipvsadm, I can route the packets, destined for this IP address
and a port, to myServer.
And in myServer, I enabled ip_forwarding and assigned 192.168.1.2 for
the loopback interface. So my server application receives and serves
the packets properly.
I'm surprised that having the 192.168.1.2 address on the loopback
interface is working as expected at all as the kernel will usually
protect the loopback interface from any thing not local to the system.
The problem is in the return path. (Remember the packets have source
addres 192.168.1.2). While they reach the gateway, the packets are
being dropped.
*nod* You will indeed have some reverse path issues to work out.
(I think, the reason is nothing but the address 192.168.1.2 is
assigned to the gateway. Hence router assumes the packets are
traversing though a loop.)
*nod*
I can't use masquerading, because I need to get the source &
destination IPs of the packets.
Ok...
I have to ask, why does your server have a private class C address on
its external interface? Either you are doing something weird and your
external is not external to the internet or you are already in a
situation where the packets have been modified as you are trying to
avoid. I'm just saying / opening the door for an answer.
Can anyone suggest a way to redirect packets from an interface to
another (ie, eth1 to eth0) without making any change in the packet
header.
Why redirect the packets at all. Why not let the packets come in
directly to the router?
I'd suggest that you turn your router in to a bridging router. I.e.
bridge traffic to / from 192.168.1.2 through eth0 and eth1 while routing
192.168.1.1 traffic for your LAN? This way your server would have
192.168.1.2 bound to its NIC and be able to reply directly to the world
with out any problem at all. If you are worried about not having a
firewall, you can easily do either EBTables (layer 2) or IPTables (layer
3) on the bridged (layer 2) traffic so your system will still be protected.
Do some light reading of section 7 of the following page:
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html#section7 I think
this will help depict what I'm talking about.
PS: The latest versions of netfilter doen't have inbuilt ipt_ROUTE
module. Else my life would be cool.
Grant. . . .
