Two-way NAT (PAT) on Cisco IOS or NAT NVI
At the request of a colleague ( Fedia ), I collected my thoughts and decided to write an article about NAT NVI. It must be said that in general the translation of addresses on the router itself was considered many times, incl. in the article “ At the request of workers: Dual ISP on cisco routers without BGP ”. However, the inside source and outside source NAT mechanism described in it has some limitations.
Task 1.
In particular, consider the topology:
Formulation of the problem.
Required to broadcast on R0:
Since the interface address is one, PAT is naturally used.
Decision number 1.
Translations themselves are written for each case quite simply.
Now we need to specify for each interface participating in the broadcast, it is internal (inside) or external (outside) for translation. It seems everything is simple but bad luck: the fa 0/1 interface will need to be done simultaneously inside and outside. What is impossible, since each interface can be either inside or outside.
Solving this problem with the help of classic NAT is possible only with serious tricks.
The first solution is to use PBR (policy based routing) technology. The idea is as follows:
Boundary conditions Here let me make a few reservations.
First, I would like to note that such a trick is not always possible. The fact is that PBR works earlier than inside-to-outside NAT (see the Cisco article: Package Processing Order "In Complex Configurations"). In the case of outside-to-inside NAT, this is not true, i.e. NAT rules are checked first.
Secondly, we create excessive load on the router, because Sending packets through PBR always loads the processor.
Those. the solution, although not beyond the scope of classic NAT, stands on very frail props.
')
Decision number 2 .
Now, actually, let's come to the version, because of which this article was written.
Cisco NVI NAT technology (or it is often called ip nat enable) allows us not to worry about marking interfaces as inside or outside. We simply label them as included in NAT with the command
And we write the unified rules. In particular for our case, these rules will differ only in the absence of the word inside:
And the router itself understands, when receiving a packet on an interface, to expose this packet to direct or reverse broadcast, and what is the direction of this broadcast.
Naturally, such “automatics” requires a much more careful assignment of “interesting” traffic for broadcasting, since if one describes it too superficially, one can get an unpredictable number of broadcasts in both directions.
However, the described topology is quite rare in real networks. As a rule, it is required for small providers. And therefore, now I would like to describe the solution to a more vital task.
Task 2.
Formulation of the problem.
It often happens that for some requests from the outside, we would like to present “requesters” as some internal address.
Consider the topology
Conditions of the problem:
Analysis .
Obviously, the classic static PAT is not appropriate in this case, since when requested from the Internet, it will only change the address and port of destination (c 172.16.1.5:22 to 192.168.1.2:22), leaving the source (any address from the Internet) unchanged. Then the response from the SRV will go through the default gateway, i.e. via R2 to the Internet.
We need the answer to be returned in the same way - via R1, i.e. so that the client connecting to the server receives a response from the same global address to which he applied. For this, it would be nice to submit hosts referring to 172.16.1.5:22 as some internal address, for example 192.168.0.201, then the answer to this address will be routed from R2 through the local network to R1 and only then to the Internet.
It would seem that you can use outside source NAT for this, but there is one catch in cisco IOS: outside source NAT cannot be PAT, that is, works at the network level and translates the address to the address. This forces us to translate into a pool. And the number of such simultaneous broadcasts is limited by the capacity of the pool.
Since the number of addresses on the Internet exceeds any pre-defined pool, and the server can be very visited, this solution is not very suitable for us.
Decision.
Refer to Cisco NVI. Since the direction of translation is no longer set on the interfaces, we can make several direct PAT translations:
1. Broadcast for access to the Internet of our hosts:
2. Broadcast for port forwarding:
In other words, we combined two dynamic PAT translations and one static.
Of course, this article does not pretend to every possible disclosure of Cisco NVI NAT capabilities; nevertheless, it can be useful to those who often use NAT in their topologies and do not want to limit themselves to the capabilities of classic NAT.
PS Thanks to Fedia for inviting, joining the community and just for being able to write this opus :)
Podkopaev Ilya, instructor
Task 1.
In particular, consider the topology:
Formulation of the problem.
Required to broadcast on R0:
- 1. addresses for R2 (10.0.2.0/24) - to the fa 0/0 interface, when accessing R1
- 2. addresses for R3 (10.0.3.0/24) - to the fa 0/1 interface, when accessing R2
Since the interface address is one, PAT is naturally used.
Decision number 1.
Translations themselves are written for each case quite simply.
Router(config)# access-list 101 permit ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255
Router(config)# ip nat inside source list 101 interface fa 0/0 overloadRouter(config)# access-list 102 permit ip 10.0.3.0 0.0.0.255 10.0.2.0 0.0.0.255
Router(config)# ip nat inside source list 102 interface fa 0/1 overloadNow we need to specify for each interface participating in the broadcast, it is internal (inside) or external (outside) for translation. It seems everything is simple but bad luck: the fa 0/1 interface will need to be done simultaneously inside and outside. What is impossible, since each interface can be either inside or outside.
Solving this problem with the help of classic NAT is possible only with serious tricks.
The first solution is to use PBR (policy based routing) technology. The idea is as follows:
- 1. Configure fa 0/1 for R0 as outside.
- 2. Create a virtual interface (loopback) lo0 with some address on R0 and enable ip nat inside on it.
- 3. Redirect traffic from fa 0/1 to lo0, if this traffic is to be transmitted to fa 0/0 interface.
Boundary conditions Here let me make a few reservations.
First, I would like to note that such a trick is not always possible. The fact is that PBR works earlier than inside-to-outside NAT (see the Cisco article: Package Processing Order "In Complex Configurations"). In the case of outside-to-inside NAT, this is not true, i.e. NAT rules are checked first.
Secondly, we create excessive load on the router, because Sending packets through PBR always loads the processor.
Those. the solution, although not beyond the scope of classic NAT, stands on very frail props.
')
Decision number 2 .
Now, actually, let's come to the version, because of which this article was written.
Cisco NVI NAT technology (or it is often called ip nat enable) allows us not to worry about marking interfaces as inside or outside. We simply label them as included in NAT with the command
Router(config-if)# ip nat enableAnd we write the unified rules. In particular for our case, these rules will differ only in the absence of the word inside:
Router(config)# access-list 101 permit ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255
Router(config)# access-list 102 permit ip 10.0.3.0 0.0.0.255 10.0.2.0 0.0.0.255
Router(config)# ip nat source list 101 interface fa 0/0 overload
Router(config)# ip nat source list 102 interface fa 0/1 overloadAnd the router itself understands, when receiving a packet on an interface, to expose this packet to direct or reverse broadcast, and what is the direction of this broadcast.
Naturally, such “automatics” requires a much more careful assignment of “interesting” traffic for broadcasting, since if one describes it too superficially, one can get an unpredictable number of broadcasts in both directions.
However, the described topology is quite rare in real networks. As a rule, it is required for small providers. And therefore, now I would like to describe the solution to a more vital task.
Task 2.
Formulation of the problem.
It often happens that for some requests from the outside, we would like to present “requesters” as some internal address.
Consider the topology
Conditions of the problem:
- 1. On R1, for hosts from the 192.168.0.0/24 network, the PAT is configured at 172.16.1.5.
- 2. On SRV1, the default gateway is R2.
- 3. It is necessary to forward the SSH port (22) to the server on R1.
Analysis .
Obviously, the classic static PAT is not appropriate in this case, since when requested from the Internet, it will only change the address and port of destination (c 172.16.1.5:22 to 192.168.1.2:22), leaving the source (any address from the Internet) unchanged. Then the response from the SRV will go through the default gateway, i.e. via R2 to the Internet.
We need the answer to be returned in the same way - via R1, i.e. so that the client connecting to the server receives a response from the same global address to which he applied. For this, it would be nice to submit hosts referring to 172.16.1.5:22 as some internal address, for example 192.168.0.201, then the answer to this address will be routed from R2 through the local network to R1 and only then to the Internet.
It would seem that you can use outside source NAT for this, but there is one catch in cisco IOS: outside source NAT cannot be PAT, that is, works at the network level and translates the address to the address. This forces us to translate into a pool. And the number of such simultaneous broadcasts is limited by the capacity of the pool.
Since the number of addresses on the Internet exceeds any pre-defined pool, and the server can be very visited, this solution is not very suitable for us.
Decision.
Refer to Cisco NVI. Since the direction of translation is no longer set on the interfaces, we can make several direct PAT translations:
1. Broadcast for access to the Internet of our hosts:
Router(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any
Router(config)# ip nat source list 100 interface fa0/0 overload2. Broadcast for port forwarding:
ip nat source static tcp 192.168.1.2 22 172.16.1.5 22 extendable
3. Translation of addresses of various requesting hosts to the internal address 192.168.0.201Router(config)# access-list 101 permit tcp any host 172.16.1.5 eq 22
Router(config)# ip nat pool SERV_PAT 192.168.0.201 192.168.0.201 prefix-length 24
Router(config)# ip nat source list 101 pool SERV_PAT overloadIn other words, we combined two dynamic PAT translations and one static.
Of course, this article does not pretend to every possible disclosure of Cisco NVI NAT capabilities; nevertheless, it can be useful to those who often use NAT in their topologies and do not want to limit themselves to the capabilities of classic NAT.
PS Thanks to Fedia for inviting, joining the community and just for being able to write this opus :)
Podkopaev Ilya, instructor
Source: https://habr.com/ru/post/84060/
All Articles