Do not assign 10.10.4.5 to ANY interface on the router. Then you should be able to fix the routing so that the pings work. NAT does not require any of the referenced IP addresses to be present on the router. As long as the packets are being routed into the NAT box, NAT will happily inspect the IP headers of every packet. If the headers match one of the NAT rules, then the NAT code will modify the header for you. -Aaron On Mon, 23 Aug 2004, Josan Kadett wrote: > Well the exact error message received is this; > > "invalid argument" > > Not even the simple ping utility is able to send a request to an IP which is > exactly the same as a address of a local interface. Even if I specify which > interface the ping will use with -I option, that fails (above error > message). So when ping does not work, it is impossible for NAT to work as I > presume. > > Perhaps there is something to do with the routing table, you could test the > following to see if anything could be done; > > - Assign an IP to a virtual interface which actually exists on the physical > network > - Use ping -I "interface ID" command to ping that real node [it will fail] > - Try to delete the default routing table created when the virtual interface > is turned on > - Use the ping utility again to see if anything changes > > I have not managed to delete that default routing table since it seems to be > hardcoded there... I am not sure this can ever be achieved, but it is a > real-life issue, and might repeat in different scenarios. > > -----Original Message----- > From: asterr [mailto:asterr@pobox.com] > Sent: Monday, August 23, 2004 5:41 AM > To: Josan Kadett > Cc: linux-net@vger.kernel.org > Subject: RE: Very unusual NAT configuration... > > Do not assign IP address A to any interface on the router machine. > Also, make sure that the route tables will send traffic for 10.10.4.5 out > the appropriate interface (eth2). > > Example: > > router:eth0 = 10.10.5.10 > router:eth1 = 2.2.2.1 --> 2.2.2.5 > router:eth2 = 10.0.0.2 --> 10.10.4.5 > > NAT: > > src: any, dst: 10.10.4.5, int: eth0 --> src: orig, dst: 2.2.2.5 > > > FLOW: > > 1. some client sends packet to 10.10.4.5 > 2. outside world routes packet to router:eth0 > 3. NAT rule translates packet destination to 2.2.2.5 > 4. router sends packet to 2.2.2.5 > 5. 2.2.2.5 sends packet back to router:eth1 > 6. NAT rule does not match -- restricted to eth0 > 7. router sends packet out eth2 to 10.10.4.5 based on routing tables > > The return traffic could either go back through the proxy (if 2.2.2.5 > changes the source IP). Or the return traffic could go directly back to > the external client. > > I have done similar setups regularly, just not on linux. However, I do > not see any reason why linux could not handle this. > > > > > > - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
