One Bad Pixel
When a good pixel go bad.
«
»

Part 5: NAT Translation in Vyatta

Previous: Part 4: Adding Stateful Firewall to Vyatta
Hey guys, welcome back to part 5 in the series. Sorry for the super long delay, I tend to get busy and forget to finish up my personal blog.. Please do comment if you need specifics or just want to remind me to work on it, because I do get your comments forwarded to my mobile phone and it reminds me.

In this article, we are going to setup some NAT translations, both inbound and outbound, for our network. If you read Part 4 (recently, I updated it), you know that we have a DNS server and a WEB server in our lab network. We are going to add some inbound NAT (destination NAT) and outbound NAT (source NAT) to enable our DNS server to serve queries from the Interwebs, and we also want our WEB server to be functional on the Interwebs.

Before we get started, we need to discuss the order of interaction between firewalls and NAT, as mentioned in Part 4. As you may have noticed in that part, the firewalls are applied to the inside addresses of our servers, but obviously, the Internet is not using the private addresses. Since we hadn’t yet covered NAT, I saved this discussion for this part.

Vyatta NAT-Firewall Interaction

This diagram should help you figure out the order in which things are done, and what the addresses are going to be at a given time. DNAT (Destination NAT) is applied before routing as the packets are inbound to the router. SNAT (Source NAT) is applied just before the packets leave the router. Any routing or firewalls happen in between these processes, so you need to account for this when determining what address the process will “see” as the source or destination.

For many of you out there, you may be working with a router that has only 1 external address, so you will need to “overload” your NAT translations. I will discuss this first, but will then move on to what a larger environment will be dealing with, which is a block of addresses where you assign an address to each system that you will expose to the Internet. Note that while probably possible, doing inbound NAT to a DHCP address is not feasible (or manageable). I don’t know if there is a way in Vyatta to use a dynamic address as the destination for a NAT rule. I am assuming a static address for this article.

Example 1: We want to expose our DNS server and WEB server, using the same IP (as the router), to the Internet, using different ports.


edit nat destination
set rule 100 description "NAT inbound TCPUDP53 to DNS server"
set rule 100 destination address 10.1.1.2
set rule 100 destination port 53
set rule 100 inbound-interface eth0
set rule 100 protocol tcp_udp
set rule 100 translation address 172.16.0.5
#the following line is optional. If you wanted to change the port on the way though, 
#this is how you change it.  IE, port 3389->10000..
set rule 100 translation port 53

#now the WEB server
#http/https
set rule 110 description "NAT inbound TCP80,TCP443 to WEB server"
#note we use the same destination address
set rule 110 destination address 10.1.1.2 
#we specify multiple ports with port,port or a range with port-port.
#we can combine also, like port,port,port-port
#note, you can only use each port on the destination address ONCE!
set rule 110 destination port 80,443
set rule 110 inbound-interface eth0
set rule 110 protocol tcp
set rule 110 translation address 172.16.0.10
#rdp
set rule 111 description "NAT inbound TCP10000 to WEB server"
set rule 111 destination address 10.1.1.2
#we can use a non-standard port if we want
set rule 111 destination port 10000
set rule 111 inbound-interface eth0
set rule 111 protocol tcp
set rule 111 translation address 172.16.0.10
#then change to default RDP port so we dont need to reconfig server
set rule 111 translation port 3389
exit
commit
save

Since our previous example uses only a single overloaded address, there is little reason to do source NAT. All our traffic is being masqueraded as the router’s IP anyways because of the rule 999 we created earlier in the series. I will cover source NAT next, which you can adapt to this scenario if you really need to.

Now, we are going to modify our WAN from Part 3 to use a larger subnet, so that we can setup multiple NAT translations, and also setup the firewall for an additional WEB server.


#remove the /30
delete interfaces ethernet eth0 address 10.1.1.2/30
#add the /24 class-C subnet
set interfaces ethernet eth0 address 10.1.1.2/24
#add some additional addresses used for NAT
set interfaces ethernet eth0 address 10.1.1.3/24
set interfaces ethernet eth0 address 10.1.1.4/24
set interfaces ethernet eth0 address 10.1.1.5/24
commit

edit firewall name TO-LAN-IPV4
#we added a new webserver at 172.16.0.11
set rule 120 action accept
set rule 120 description "Allow HTTP/HTTPS to internal WEB2 server"
set rule 120 destination address 172.16.0.11
set rule 120 destination port 80,443
set rule 120 protocol tcp
#and allow RDP to our webserver but only from our office at 5.6.7.0/24
set rule 121 action accept
set rule 121 description "Allow RDP to internal WEB server from 5.6.7.0/24"
set rule 121 destination address 172.16.0.11
set rule 121 destination port 3389
set rule 121 protocol tcp
set rule 121 source address 5.6.7.0/24
exit
commit
save

Now that we have 4 addresses bound to our WAN interface, we can NAT translate each of them differently. While you can still setup your NAT specifying the ports, I prefer to assign each externally exposed server its own IP address and then use the firewall to control the traffic. This makes it much easier to expose additional ports later.


#dns server
set nat destination rule 200 description "NAT inbound to DNS server"
set nat destination rule 200 destination address 10.1.1.3
set nat destination rule 200 inbound-interface eth0
set nat destination rule 200 translation address 172.16.0.5

edit nat destination
#web server
set rule 210 description "NAT inbound to WEB server"
set rule 210 destination address 10.1.1.4
set rule 210 inbound-interface eth0
set rule 210 translation address 172.16.0.10
#web2 server
set rule 220 description "NAT inbound to WEB2 server"
set rule 220 destination address 10.1.1.5
set rule 220 inbound-interface eth0
set rule 220 translation address 172.16.0.11
exit

Notice I used both the long-form and shortened-edit form here, to show you how you can use either to save a lot of typing. For example, the following are all equivalent.


set nat destination rule 200 destination address 10.1.1.3
set nat destination rule 210 destination address 10.1.1.4

#is the same as
edit nat destination
set rule 200 destination address 10.1.1.3
set rule 210 destination address 10.1.1.4
exit 

#is the same as
edit nat destination rule 200
set destination address 10.1.1.3
#up moves up one level, so from "nat destination rule 200" to "nat destination"
up
#next edit command is relative to current level
edit rule 210
set destination address 10.1.1.4
#exit moves to top level, you can also use "top" for the same purpose
exit

Since we have translated multiple external addresses to their internal counterparts, we probably want traffic leaving these servers to look like it came from the proper address, rather than the primary address of the router (10.1.1.2), so we will create some SNAT (Source NAT) rules to do this. Note that the syntax is very similar, but we specify the source address rather than destination, and outbound-interface rather than inbound-interface. We can still use destination address if we want translations to apply only to traffic destined for a specific place, but this is more advanced and I am not going to cover that now.


edit nat source
#dns server
set rule 200 description "NAT outbound from DNS server"
set rule 200 source address 172.16.0.5
set rule 200 outbound-interface eth0
set rule 200 translation address 10.1.1.3
#web server
set rule 210 description "NAT outbound from WEB server"
set rule 210 source address 172.16.0.10
set rule 210 outbound-interface eth0
set rule 210 translation address 10.1.1.4
#web2 server
set rule 220 description "NAT outbound from WEB2 server"
set rule 220 source address 172.16.0.11
set rule 220 outbound-interface eth0
set rule 220 translation address 10.1.1.5
exit

Now we have a bunch of NAT translations to convert our public addresses to our private internal addresses. Unless you are using split-horizon DNS (where your internal nameserver replies with internal addresses, and your external nameserver replies with external addresses), you probably want to allow your internal hosts to access your webservers using the external addresses. Lets say, for example, that your DNS reports www.mydomain.com to be 10.1.1.4. Inside your network, however, your webserver is actually 172.16.0.10. In order to do this, we can do “hairpin NAT”. Because Vyatta is pretty fast this normally won’t pose much problem, but if you are using this in a larger environment, I definitely recommend split-horizon DNS so all the traffic doesn’t need to go through your router.


edit nat source
set rule 998 description "NAT internal to internal Hairpin"
#traffic is for internal address, and going out internal interface
set rule 998 destination address 172.16.0.0/24
set rule 998 outbound-interface eth1
#traffic is coming from internal address
set rule 998 source address 172.16.0.0/24
#hide original source and masquerade as router
set rule 998 translation address masquerade

Next: Part 6: Vyatta Firewall Groups

 

6 Responses for “Part 5: NAT Translation in Vyatta”

  1. Part 4: Adding Stateful Firewall to Vyatta | One Bad Pixel Says:

    […] Newest CommentsPart 5: NAT Translation | One Bad Pixel on Part 4: Adding Stateful Firewall to VyattaPart 2: Installing Vyatta Community 6.5R1 | One Bad […]

  2. Part 6: Vyatta Firewall Groups | One Bad Pixel Says:

    […] Part 5: NAT Translation in Vyatta | One Bad Pixel on Part 6: Vyatta Firewall Groups […]

  3. Vyatta Dynamic DNS and NAT translations | One Bad Pixel Says:

    […] Part 6: Vyatta Firewall Groups | One Bad Pixel on Part 5: NAT Translation in Vyatta […]

  4. Vyatta Dynamic DNS and NAT translations | One Bad Pixel Says:

    […] Vyatta Dynamic DNS and NAT translations | One Bad Pixel on Part 5: NAT Translation in Vyatta […]

  5. Chris Says:

    Hi

    I need you help.
    I have a router Vyatta as Router gateway for my network. There is web-server locate in LAN network.
    On my vyatta router I deploy NAT for Web-server through WAN IP for accessible from the Internet.
    But i wanna access web-server from LAN network by using WAN IP.
    I am trying NAT but it wasn’t working. Please help me for this case.
    Thanks you so much.!

  6. Jim Says:

    Yeah, you need to do “Hairpin NAT”, which requires 2 things.
    First, you need a destination NAT for traffic inbound from the LAN interface (for this example, lets assume LAN is eth1, x.x.x.x is the PUBLIC IP, and y.y.y.y is the internal ip)

    nat destination rule x description "NAT hairpin for webserver"
    nat destination rule x destination address x.x.x.x
    nat destination rule x inbound-interface eth1
    nat destination rule x translation address y.y.y.y
    

    Then, the magic of making this work is that you need to masquerade traffic from the LAN to the LAN to appear as though it came from the router, otherwise the webserver will try to reply to the client directly. This can be a blanket rule covering all hairpins, and must exist just before your masquerade that handles everything going out the WAN.

    nat source rule 900 description "NAT hairpin inside to inside"
    nat source rule 900 destination address y.y.y.0/24
    nat source rule 900 outbound-interface eth1
    nat source rule 900 source address y.y.y.0/24
    nat source rule 900 translation address masquerade
    

Leave a comment!