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