SNAT many-to-many


#1

Dear members.

I have some problems with NAT , especially the many-to-many function.

Does anybody knows how to dynamically NAT multiple addresses from IN interface to a large pool on the OUT interface without define all those translated addresses on the OUT interface ?

I have read the Vyatta manual (and test the system) and it seems to be the only solution to achieve this goal, but in my case there is to much addresses to define on the interface and it’s not very practical. I choose to test VyOS, but the problem remain the same…

Thanks in advance.
(sorry for my English, i’m french.)


#2

VyOS supports many-to-many NAT out of the box for pools of same size:

 source {
        rule 10 {
            outbound-interface eth0
            source {
                address 192.168.5.0/28
            }
            translation {
                address 192.168.3.128/28
            }
        }
    }

If you need to translate pools of different size (say, /24 network to /28 network) then try to comment lines 306-310 in /opt/vyatta/share/perl5/Vyatta/SrcNatRule.pm to remove subnets match check:

#    if (!($outside_addr_mask == $src_addr_mask)) {
#      return ("\nsource address should be a subnet with the same network prefix as translation address" .
#              "\nwhen translation address is defined with a prefix for static network mapping "
#              , undef);
#    }

Iptables rule looks ok without this check, but I haven’t tried it in work, so keep a backup of original file :slight_smile:

And AFAIR iptables NAT will make unique src<->dst IP address pair for every connections, even if there were previous entries with same source address.

UP: it seems that it should work without sources modification for different pools if you specify translation address as a range:

 source {
                address 192.168.5.0/24
            }
 translation {
                address 192.168.3.128-192.168.3.223
            }

The iptables rule seems to be ok:

SNAT       all  --  192.168.5.0/24       anywhere             /* SRC-NAT-10 */ to:192.168.3.128-192.168.3.223

#3

Hi Valentin, thanks for your response.

I’ve already tried this NAT rule, and the translation works.
In fact, addresses pool from the IN interface are translated to addresses pool on the OUT interface but connections cannot be established because of a ARP non response on the OUT interface. It seems that I have to manually define all translated addresses on the OUT interface but maybe someone knows how to bypass it. I’ve also tried the “set interfaces ethernet ethx ip enable-proxy-arp” command with the same result (no ARP response).


#4

Sure, someone has to reply to ARP.

Looking to Cisco’s IOS, they’re adding aliases to NAT interface to solve this problem by default (user can disable this behaviour by specifying no-alias option to NAT rule, but I’ve never seen this keyword in use).

It’s not a problem to add such behavior to VyOS, but I’m in doubt that NAT submodule shall add or remove any address aliases, because it will make implicit relationships between different parts of OS and it’ll become a little bit tricky to make things consistent especially for PPP-like interfaces.

I think the clever algorithm will be:

  1. User defines address ranges with a commands like this:
# Address range assignment
# Here mask is specified only once to make sure that range belongs to subnet
set interface eth0 address 192.168.2.10-192.168.2.45/24

# Next range
set interface eth0 address 192.168.3.80-192.168.3.94/25

# And so on
  1. User defines source NAT translations as usual by:
nat source rule 10 translation 192.168.2.10-192.168.2.45

When he commits the changes, VyOS will parse interfaces block first and create necessary aliases. Next, it will add NAT rule.

This will work ok, but this solution has one “underwater stone”: all open services (ssh, dns, etc) at VyOS router will become implicitly open at ALL interface aliases by default, so user needs to setup listen-addresses correctly.

Any suggestions?


#5

Anyone find a solution for this?


#6

Solution for what problem? If Vyos is public facing, you always should use WAN_LOCAL firewall ruleset, protecting inner services.