Bilateral NAT (PAT) on Cisco IOS or NAT NVI
At the request of a colleague ( Fedia ), I gathered my thoughts and decided to write an article about NAT NVI. I must say that in general, the translation of addresses on the router has been considered many times, including 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.
Problem 1.
In particular, we consider the topology:
Statement of the problem.
It is required to broadcast on R0:
Since the interface address is one, PAT is naturally used.
Decision number 1.
Broadcasts themselves are written for each case quite simply. Now, we need to specify for each interface participating in the translation, is it internal (inside) or external (outside) for translation. Everything seems to be simple, but here's the problem: the fa 0/1 interface will need to be done both inside and outside. Which is impossible, since each interface can be either inside or outside. To solve such a problem with the help of classical 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 I allow myself to make a few reservations.
Firstly, I would like to draw attention to the fact that such a trick is not always possible. The fact is that PBR is triggered earlier than inside-to-outside NAT (see the Cisco article: Packet Processing Procedure “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 an excessive load on the router, because sending packets through PBR always loads the processor.
Those. the solution, although not beyond the scope of classical NAT, stands on very frail props.
Decision number 2 .
Now, in fact, let's get to that option, 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 mark them as being included in NAT using the command
And write unified rules. In particular, for our case, these rules will differ only in the absence of the word inside: And the router itself understands, upon receiving a packet on the interface, expose this packet to direct or reverse broadcast, and what direction this broadcast has. Naturally, such “automation” requires a much more careful setting of “interesting” traffic for broadcasting, because if you describe it too superficially, you can get an unpredictable number of broadcasts in both directions.
Nevertheless, the described topology is quite rare in real networks. As a rule, it is required by small providers. And therefore, now I would like to describe the solution to a more vital task.
Task 2.
Statement of the problem.
It often happens that for some requests from outside we would like to introduce the "requestors" as some internal address.
Consider the topology of the
problem conditions:
Analysis .
Obviously, the classic static PAT in this case is not suitable, because upon a request from the Internet, it will only change the address and destination port (from 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 come back in the same way - through R1, i.e. so that the client connecting to the server receives a response from the same global address to which it addressed. To do this, it would be nice to imagine the hosts accessing 172.16.1.5:22 as some internal address, for example, 192.168.0.201, then the answer to this address will go by routing 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, i.e. works at the network level and translates the address to the address. This forces us to broadcast to 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 predetermined pool, and the server can be very visited, this solution is not suitable for us.
Decision.
Let's turn to Cisco NVI. Since the direction of broadcasting is no longer specified on the interfaces, we can do several direct PAT-broadcasts:
1. Broadcast for accessing the Internet of our hosts: 2. Broadcast for port forwarding:
Problem 1.
In particular, we consider the topology:
Statement of the problem.
It is required to broadcast on R0:
- 1. addresses for R2 (10.0.2.0/24) - to the interface fa 0/0, when accessing R1
- 2. addresses for R3 (10.0.3.0/24) - in the interface fa 0/1, when accessing R2
Since the interface address is one, PAT is naturally used.
Decision number 1.
Broadcasts themselves are written for each case quite simply. Now, we need to specify for each interface participating in the translation, is it internal (inside) or external (outside) for translation. Everything seems to be simple, but here's the problem: the fa 0/1 interface will need to be done both inside and outside. Which is impossible, since each interface can be either inside or outside. To solve such a problem with the help of classical NAT is possible only with serious tricks. The first solution is to use PBR (policy based routing) technology. The idea is as follows:
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 overload- 1. Set fa 0/1 at R0 as outside.
- 2. Create on R0 a virtual interface (loopback) lo0 with some address and enable ip nat inside on it.
- 3. Redirect traffic from fa 0/1 to lo0 if this traffic needs to be translated into the fa 0/0 interface.
Boundary conditions . Here I allow myself to make a few reservations.
Firstly, I would like to draw attention to the fact that such a trick is not always possible. The fact is that PBR is triggered earlier than inside-to-outside NAT (see the Cisco article: Packet Processing Procedure “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 an excessive load on the router, because sending packets through PBR always loads the processor.
Those. the solution, although not beyond the scope of classical NAT, stands on very frail props.
Decision number 2 .
Now, in fact, let's get to that option, 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 mark them as being included in NAT using the command
Router(config-if)# ip nat enableAnd write unified rules. In particular, for our case, these rules will differ only in the absence of the word inside: And the router itself understands, upon receiving a packet on the interface, expose this packet to direct or reverse broadcast, and what direction this broadcast has. Naturally, such “automation” requires a much more careful setting of “interesting” traffic for broadcasting, because if you describe it too superficially, you can get an unpredictable number of broadcasts in both directions.
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 overloadNevertheless, the described topology is quite rare in real networks. As a rule, it is required by small providers. And therefore, now I would like to describe the solution to a more vital task.
Task 2.
Statement of the problem.
It often happens that for some requests from outside we would like to introduce the "requestors" as some internal address.
Consider the topology of the
problem conditions:
- 1. On R1, for hosts from the 192.168.0.0/24 network, PAT is configured to the address 172.16.1.5.
- 2. On SRV1, the default gateway is set to R2.
- 3. It is necessary to forward the SSH port (22) to the server on R1.
Analysis .
Obviously, the classic static PAT in this case is not suitable, because upon a request from the Internet, it will only change the address and destination port (from 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 come back in the same way - through R1, i.e. so that the client connecting to the server receives a response from the same global address to which it addressed. To do this, it would be nice to imagine the hosts accessing 172.16.1.5:22 as some internal address, for example, 192.168.0.201, then the answer to this address will go by routing 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, i.e. works at the network level and translates the address to the address. This forces us to broadcast to 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 predetermined pool, and the server can be very visited, this solution is not suitable for us.
Decision.
Let's turn to Cisco NVI. Since the direction of broadcasting is no longer specified on the interfaces, we can do several direct PAT-broadcasts:
1. Broadcast for accessing the Internet of our hosts: 2. Broadcast for port forwarding:
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 overloadip nat source static tcp 192.168.1.2 22 172.16.1.5 22 extendable
3. Translation of the addresses of all kinds of requesting hosts to the internal address 192.168.0.201
In other words, we combined two dynamic PAT translations and one static.
Of course, this article does not purport to reveal the full potential of Cisco NVI NAT, however, it may be useful to those who often use NAT in their topologies and do not want to limit themselves to the capabilities of classical NAT.
PS Thanks to Fedia for the invite, familiarization with the habrabschestvo and just for the fact that I could write this opus :)
Ilya Podkopaev, instructorRouter(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 overload