> > Think of a normal NAT gateway. You connect to a remote host, but you
> > send that packet to the gateway. The gateway changes the source IP
> > address and then forwards on the packet. This way altering ARP is not
> > necessary, because a real IP belonging to the machine is used for
> > outgoing traffic. The normal ARP process handles it all as usual.
>
> I am unsure how you use NAT to perform the entire network
> transformation of 192.168.0.X <-> 10.0.0.X.
It is partly NAT and partly routing:
Client Client
ping 192.168.110.10 ping 192.168.111.10
| |
+--------------------+--+
|
Router:
For 192.168.110.10: For 192.168.111.10:
v10@eth0 v11@eth0
10.0.0.10 10.0.0.11
| |
Device 1 Device 2
10.0.0.2 10.0.0.2
(ping from 10.0.0.10) (ping from 10.0.0.11)
> > If you do the same in your situation, then your 10.0.0.10 device will
> > need to see traffic coming from 10.0.0.X (whatever IPs you assign
> > v10@eth0 and v11@eth0). Because these IPs are in the same subnet, you
> > don't need to deal with ARP issues or routing the reverse traffic as
> > you would if you kept the 192.168.x source IP.
>
> I cannot do this, the packets should be outgoing to the device in the
> 10.0.0.X address.
> Hence I need a full transformation of addresses of both source and
> destination addresses.
Yes, this is what I have explained.
> > Then all you have to do is configure your machine so that any traffic
> > destined for 192.168.110.10 and .111.10 gets the target IP changed to
> > 10.0.0.2 and gets sent out the right interface, and when packets come
> > back from 10.0.0.2 the reverse IP translation happens as well.
>
> I will be happy to test a specific configuration if you have, I do not
> understand how to
> perform the reverse NAT as my interface is NATing the use of the
> network and not in
> the usual direction.
My solution is to use NAT in both directions. I am thinking these are
the steps:
1. Outgoing packets to 192.168.110.10 must go to v10@eth0 and have the
destination changed to 10.0.0.2. The source IP must be 10.0.0.10.
2. Incoming packets from 10.0.0.2 on v10@eth0 must have their source
IP changed to 192.168.110.10. The destination IP should be
whatever the original IP was.
3. Same again for v11@eth0 and 192.168.111.10.
I think you should be able to use DNAT rules to change the destination
IP, and SNAT rules to change the source IP. The only trick would be
getting packets for 192.168.110.10 sent to v10@eth0 (which has the IP
10.0.0.10/24). I am not sure whether adding a route would be enough,
or whether you would have to add an IP like 192.168.110.99/24 to that
interface to have the routing happen as intended.
> > I think you probably need both SNAT and DNAT rules to make this work.
> > The SNAT rule would take care of ensuring outgoing packets have a
> > source address of 10.0.0.X, while the DNAT rule would map the 192.x
> > target address to 10.0.0.2.
>
> This is not the configuration I look for... I look for a configuration
> of full network
> static NAT 192.168.0.X <-> 10.0.0.X [x=1->254].
So far you have only described a single device 10.0.0.2. Your original
question did not mention that you have 254 devices on the subnet!
> > I would try to use two different IPs for the VLAN interfaces, e.g.
> > 10.0.0.10 and 10.0.0.11, just to make things a bit simpler. If you use
> > the same IP you may then run into ARP issues, unless both VLAN
> > interfaces have the same MAC address.
>
> There is no issue of ARP in this case as each interface resides in a
> different VLAN.
The problem I describe is that if v10@eth0 and v11@eth0 have different
MAC addresses, but the same IP address, the Linux kernel may respond to
the ARP request with the MAC address of the wrong interface, since two
different interfaces with the same IP is not a normal situation.
Think of it like this: You have MAC address A for 10.0.0.5 (v10@eth0)
and MAC address B also for 10.0.0.5 (v11@eth0). An ARP request comes in
asking what the MAC address is for 10.0.0.5. Do you reply A or B?
The answer is different depending on which interface the request came
in on, and I am not sure whether the kernel cares about this. In the
past it did not, because you are supposed to have a different IP
address for every network interface.
Cheers,
Adam.
