Reply To: multinat planned? and why using bind?

Forums Network Management ZeroShell multinat planned? and why using bind? Reply To: multinat planned? and why using bind?


MultiNAT is quite simple. It allows the use of multiple public IP addresses on the WAN interface with each IP address or an IP:protocol/port to be mapped to internal hosts.

One situation that it is often used with is a DMZ or mapping to internal hosts. An example may make it clear. If the WAN interface has a /29 allocated, allowing for network, broadcast and upstream router there will be 5 addresses available. 1 would be taken by the ZS box and used as its public interface. This also becomes the address that you SNAT with when masquerading the internal network. 4 addresses remain idle.

You may decide that you would like to use a separate address for mail server. Maybe you have two mail servers with one as a backup MX and need a unique IP address. Possibly you want to keep VPN on different address to mail server. You may want a web server on another address. This situation needs multiple public addresses.

Each service is assigned a unique IP or an allocation of IP/protocol/port. The ZS box needs to respond for each of the public addresses on the WAN interface. This is done by proxyARP or alias IP on the WAN i/f – as long as the ZS responds to the ARP request for the additional IP to the upstream router and delivers the packets into the input or forward chain. The ZS then performs Destination NAT (DNAT) on the address packet and sends the packet to the correct internal or DMZ server.

On Linux it is easy. ProxyARP or address alias can be used. I prefer the alias and I just assign additional addresses to the WAN interface. When the packet is received it is processed and has dest address translated by using the DNAT option in IPTables. The connection tracker then works and tracks the translation so the reverse translation (SNAT) is applied on egress reply packets. The packet then enters the forward chain and the routing system will egress on the correct internal interface. IN the same way that conn_track manages the translation of reply packets for MASQ traffic it will manage the translation of reply packets for DNAT traffic.

Another application for this is the reverse where you may want an internal server to appear publicly on a different address to the rest of the LAN devices. Typically I would use this on mail servers where I need to ensure mail is sent from an MX and the relevant SPF TXT entries are in place to verify the sender.

I hope this makes some sense! I have tried it on ZS and it is quite easy to implement at console … just would be nice to add to web interface!