[ale] DNAT magic

[Chris Fowler]

I'm trying to route packets to many different addresses via DNAT.  The 
target addresses
could have any address and are behind a device we install at the remote.

Here is an example setup:

*+--------------+    +--------------+
| Server       |----| PC           |
| 10.0.5.1     |eth0| 10.0.5.50    |
+--------------+    +--------------+
      | Tunnel (ppp)
+--------------+
| Device       |
| 10.0.5.2     |
+--------------+
      | eth0 172.30.100.0/24
+--------------+
| PBX          |
| 172.30.100.10|          
+--------------+


*On the server, I have this route 172.30.100.10/32 -> 10.0.5.2

On the device, I'm using MASQ on eth0.
The device does not see me at 10.0.5.1, It
will see me as the device.

The way I understand DNAT is that if I want to "assign"
10.0.5.3 to the PBX then I need to do this on the server

*ifconfig eth0:1 10.0.5.3
iptables -t nat -A PREROUTING  -i eth0 -d 10.0.5.3 -j DNAT 
--to-destination 172.30.100.10*

Am I right?

The only problem with this is that I may have 100s of our devices connected
via tunnels to remote networks so I could have eth0:1 ... eth0:512. 

I was hoping there was a way to not use the aliases and do this strictly
via routing.

If the eth0 on the server was 10.0.0.0/16 Then I could use 10.0.7.0/24 for
all the remote devices.
*
iptables -t nat -A PREROUTING  -i eth0 -d 10.0.7.1 -j DNAT 
--to-destination 172.30.100.10*

The benefit here is that if I use OpenVPN on the server to connect
via laptops(s) running Winders and push 10.0.0.0/16, then
they can have access to 100s of devices.  Will that work?
Do I really need a corresponding SNAT entry?  The PBX
is really behind an embedded Linux device.  Should it, instead
of the server, be the one where the DNAT rules are applied? 

Chris



-- 
Chris Fowler
OutPost Sentinel, LLC
Support @ SIP/support at pbx.opsdc.com
 or 678-804-8193
Email Support @ support at outpostsentinel.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20081022/cc7b53dc/attachment.html