multinat planned? and why using bind?

Home Page Forums Network Management ZeroShell multinat planned? and why using bind?

This topic contains 1 reply, has 0 voices, and was last updated by  lj2012 11 years, 4 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #40788

    lj2012
    Member

    Hi there,

    Just wondering – are there any plans to implement MultiNat in ZS? It would be a nice feature blasting a lot of Cisco (pix) Systems away in our installations…

    And why is ZS, a multifunctional platform equipped with bind? I was just thinking of using some form of dnsmasq – there is practically nothing bind can do and dnsmasq can’t – AND, quite interesting for a lot of us, dnsmasq combines the dhcp with the dns…

    Of course there is in the zeroshell thing an enourmous variety in the use of it – the use of ZS in our datacenter on an hp Proliant server is quite controversy with the use of ZS here at our office on a 1Ghz VIA processor – the LinITX device mentioned in a previous post… But still, both of them would do a fine job offering dnsmasq i’m sure.

    Anyway, if you were in doubt, do it, otherwise, leave it. But I would love it!

    Regards,
    Lennert . –

    #45919

    imported_fulvio
    Participant

    Please, could you tell me what MultiNAT means? Why do you use it on the Cisco PIX Systems?

    I don’t know dnsmasq. The Bind configured in Zeroshell use as backend Database the OpenLDAP server. Is dnsmasq able to extract the zone information by using the LDAP protocol?
    If the Bind DNS is configured to accept dynamic updates, it can be updated by the dhcp server when it assigns the leases.

    Regards
    Fulvio

    #45920

    tucker
    Member

    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!

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.