📜 ⬆️ ⬇️

Instructions for forwarding ports on Juniper SRX

With this article I plan to open a series of manuals for the Juniper SRX series. If it will be useful to someone, I will be very happy. And do not hesitate to ask questions.

I will note that everything written below will most likely be suitable for any other model of Juniper routers (due to their slogan “One Junos”, that is, one operating system for all hardware). This article is based on the official English manual for setting up NAT, taken from here: www.juniper.net/us/en/local/pdf/app-notes/3500151-en.pdf .

So, port forwarding. Or scientifically, destination NAT. Here it is necessary to make one small note. Some admins are accustomed under the word NAT to understand the source NAT, with all the consequences. And not even the source NAT, but one of its varieties - PAT. But we must understand the differences between different types of nat. Here I will not go into the theory, everything is written quite clearly on Wikipedia. I want to make only one explanation: NAT is just a substitution of addresses, nothing more. If you understand the essence of this technology differently, you are wrong. This technology does not do anything more than replace one address in the header of an IP packet with another. And there is nothing initially terrible and terrible in it. Accordingly, if we are talking about destination NAT, then we are talking about the substitution of the destination address. Consider an example:


')
Suppose we have an internal service (web server, address 10.1.1.100), which we want to make accessible from the outside to our external address (1.2.3.4 port 80). We write:
root@jsrx# edit security nat destination
This way we got into the destination NAT configuration section. First you need to create an address entry (pool) of our web server.
root@jsrx# set pool web-server address 10.1.1.100 port 80
Next, create a rule-set, i.e. Code of Destination Nata:
root@jsrx# set rule-set DNAT from zone untrust
Thereby we say that this set of rules works for packages that come from the untrust zone, i.e. in our case from the Internet. In this example, everything is fine, but sometimes it may be necessary to specify which particular interface the packets for this set of rules should come from. In this case, the phrase from zone untrust should be replaced with from interface ge-0/0/0 (as in our example). You can also specify the source of the routing-instance packet packets, but this is a more rare case, we will not think about it.
This rule-set must be filled with the necessary rules:
root@jsrx# set rule-set DNAT rule dnat_for_web match destination-address 1.2.3.4
root@jsrx# set rule-set DNAT rule dnat_for_web match destination-port 80
root@jsrx# set rule-set DNAT rule dnat_for_web then destination-nat pool web-server
In the first line, we indicate our external IP-address to which clients will knock. In the second line, we specify the external port, and in the third - the actual pool itself, which we described at the beginning.
If everything is left as it is, then nothing will work. Because you need to create an access policy to our web server:
root@jsrx# top edit security address-book global
root@jsrx# set address web_server 10.1.1.100
root@jsrx# top edit security policies from-zone untrust to-zone trust
root@jsrx# set policy web_access match source-address any
root@jsrx# set policy web_access match destination-address web_server
root@jsrx# set policy web_access match application any
root@jsrx# set policy web_access then permit
Do
root@jsrx# commit check
then if everything went ok
root@jsrx# commit
This completes the destination NAT'a, everything is quite simple. The final config is shown below:
  root @ jsrx # show security nat destination
 pool web-server {
     address 10.1.1.100/32 port 80;
 }
 rule-set DNAT {
     from zone untrust;
     rule dnat_for_web {
         match {
             destination-address 1.2.3.4/32;
             destination-port 80;
         }
         then {
             destination-nat pool web-server;
         }
     }
 }
 root @ jsrx # show security address-book global
 address web_server 10.1.1.100/32;

 root @ jsrx # show security policies from-zone to-zone trust
 policy web_access {
     match {
         source-address any;
         destination-address web_server;
         application any;
     }
     then {
         permit;
     }
 }


Several valuable additions.
1. For each port to be forwarded, you must write these rules (policies need to be written only for new servers being added). Unable to forward a range of ports with one command. A pity, sometimes you want.
If you desperately need to forward dofig and more ports, it may be worth looking in the direction of Static NAT.
2. Rules names should not be repeated within the entire NAT configuration. If you start repeating, then commit check will curse the names of the rules.
3. Names of rules, rulebooks, pools, etc. You can write any at your discretion. In my case, these are DNAT, web server, dnat_for_web, etc.
4. You can view the counting of forwarding trips from the operating mode using the command:
root@jsrx> show security nat destination rule _
The Translation hits line will show the number of times the triggering has been activated. Very handy diagnostic tool Nata. Such a moment: destination NAT'a rules are processed BEFORE checking for compliance with policies. Therefore, if you see by the meter that forwarding is triggered, but there is no access, it is worth checking the policies. Most likely, you just forgot to add something there.
5. If you are confused by the string match application any in the policy config, then you are right. In an amicable way, for security reasons, it is necessary to enter the name of a specific application (that is, the port) that will be used by external clients. You can write match application junos-http for the web server. I will write more about applications in Junos OS later.

As you can see, the procedure for creating a callback is pretty simple, but it also has its own nuances. Thank you all for your attention, I will be very happy with any questions.

Source: https://habr.com/ru/post/166637/


All Articles