This post represents the solution and explanation for quiz-3. Have a look at it to understand the problem.
NAT on Cisco IOS can be pretty frustrating sometimes ☻ and it may take time and practice to master it.
Let's consider Company ABC with internal network 192.168.1.0/24 and a /31 public IP (155.1.23.2) assigned to the external interface of its border router R2 (fa0/1). In order to have access to internet, PAT (Port Address Translation) is configured on the border router, overloading entire internal network into the public external interface IP address.
The following tests are performed from R1 (192.168.1.1):
- "
ping 3.3.3.3" - see the first translation on R2 in picture below - "
telnet 3.3.3.3" - see the 2nd translation on R2 below - "
telnet 3.3.3.3 12345" - see the 3rd translation
As the quiz says, your users try to connect to external partner 3.3.3.3 on port 12345, the PAT translation occurs on R2 (see translation table and the "debug ip nat detailed"):
R1#telnet 3.3.3.3 12345 Trying 3.3.3.3, 12345 ...% Connection timed out; remote host not responding R2# *Mar 1 00:44:02.151: NAT*:i: tcp (192.168.1.1, 18714) -> (3.3.3.3, 12345) [39406] *Mar 1 00:44:02.151: NAT*:s=192.168.1.1->155.1.23.2 , d=3.3.3.3 [39406] R2# *Mar 1 00:44:06.147: NAT*: i: tcp (192.168.1.1, 18714) -> (3.3.3.3, 12345) [39406] *Mar 1 00:44:06.147: NAT*: s=192.168.1.1->155.1.23.2, d=3.3.3.3 [39406] R2# *Mar 1 00:44:14.143: NAT*: i: tcp (192.168.1.1, 18714) -> (3.3.3.3, 12345) [39406] *Mar 1 00:44:14.143: NAT*: s=192.168.1.1->155.1.23.2, d=3.3.3.3 [39406] R2#sh ip nat trans Pro Inside global Inside local Outside local Outside global tcp155.1.23.2:18714 192.168.1.1:18714 3.3.3.3:12345 3.3.3.3:12345
but the ISP (R3) does not allow TCP port 12345 (seen also in the debug on R2: there's only small "i" and there's no "o")
R3 *Mar 1 00:44:00.895:%SEC-6-IPACCESSLOGP: list ACL_LOG denied tcp 155.1.23.2(18714) ->3.3.3.3(12345) , 1 pack
Now comes the part when we do mistakes: we have to configure the outgoing traffic towards partner server 3.3.3.3 on destination port 12345 to be translated to destination port 8080 (allowed by ISP). Most of us will use this logic:
<<outgoing traffic = traffic from inside to outside ... so I will use ip nat inside source ...>>
which, unfortunately, is not doing what we want because ip nat inside source translates source IPs and ports for traffic received on inside interface, while in our case we want to translate destination port !!
My piece of advise: consider that you always translate sources (there are exceptions, but forget about them for now) then most of the times when you have to translate a destination IP or port, look at the problem from the opposite direction:
- if you have to change the destination IP and/or port when going from inside to outside, then use
ip nat outside source ... - if you have to change the destination IP and/or port when going from outside to inside, then use
ip nat inside source ...
|
NOTES
|
Please note that this logic "works" because static NAT is bi-directional ☺ !; |
So, in this quiz, you have to translate the destination port for traffic going from internal clients (on inside) to partner server (on outside).
Solution for the quiz
Again, we perform the same tests from R1: "ping 3.3.3.3" , "telnet 3.3.3.3" and "telnet 3.3.3.3 12345". This time all of them are successfull (notice the "Open" reply for the telnet on port 12345, meaning that TCP is established):
R1#telnet 3.3.3.3 12345 Trying 3.3.3.3,12345 ... Open R2(config)#do sh ip nat transl Pro Inside global Inside local Outside local Outside global tcp --- --- 3.3.3.3:12345 3.3.3.3:8080 tcp 155.1.23.2:44060 192.168.1.1:440603.3.3.3:12345 3.3.3.3:8080 icmp 155.1.23.2:16 192.168.1.1:16 3.3.3.3:16 3.3.3.3:16 tcp 155.1.23.2:46177 192.168.1.1:46177 3.3.3.3:23 3.3.3.3:23 R2(config)# R2(config)# *Mar 1 00:59:43.327: NAT*:i : tcp (192.168.1.1, 44060) ->(3.3.3.3, 12345) [14693] *Mar 1 00:59:43.327: NAT*: TCP s=44060,d=12345->8080 *Mar 1 00:59:43.327: NAT*: s=192.168.1.1->155.1.23.2, d=3.3.3.3 [14693] *Mar 1 00:59:43.375: NAT*:o :tcp (3.3.3.3, 8080) -> (155.1.23.2, 44060) [42254] *Mar 1 00:59:43.375: NAT*: TCPs=8080->12345 , d=44060 *Mar 1 00:59:43.375: NAT*: s=3.3.3.3, d=155.1.23.2->192.168.1.1 [42254] *Mar 1 00:59:43.403: NAT*: i: tcp (192.168.1.1, 44060) -> (3.3.3.3, 12345) [14694] *Mar 1 00:59:43.407: NAT*: TCP s=44060, d=12345->8080 *Mar 1 00:59:43.407: NAT*: s=192.168.1.1->155.1.23.2, d=3.3.3.3 [14694] R3# *Mar 1 00:59:42.083: %SEC-6-IPACCESSLOGP: listACL_LOG permitted tcp 155.1.23.2(44060) -> 3.3.3.3(8080) , 1 packet R3# *Mar 1 01:02:51.783: %SEC-6-IPACCESSLOGDP: list ACL_LOG permitted icmp 155.1.23.2 -> 3.3.3.3 (8/0), 1 packet R3# *Mar 1 01:03:30.791: %SEC-6-IPACCESSLOGP: list ACL_LOG permitted tcp 155.1.23.2(46177) -> 3.3.3.3(23), 1 packet
Notice in the debug output that there is traffic/translations from both sides "i" and "o".
What if you have used ip nat inside source instead?
Let's simulate this. This type of translation is used when you have servers in the DMZ within private addressing space and you want to make them reachable from the internet.
For example: you accept HTTP traffic on the router's external IP address (155.1.23.2 port 80) and translate both destination IP and port to the real/private IP and port of the DMZ server:
Let's generate some traffic from Internet (R3 = ISP) towards the DMZ server:
R3#telnet 155.1.23.2 80 Trying155.1.23.2, 80 ... Open R2#sh ip nat trans Pro Inside global Inside local Outside local Outside global tcp --- --- 3.3.3.3:12345 3.3.3.3:8080tcp 155.1.23.2:80 192.168.1.33:8080 155.1.23.3:21841 155.1.23.3:21841 tcp 155.1.23.2:80 192.168.1.33:8080 --- --- *Mar 1 01:18:32.411: NAT*: o: tcp (155.1.23.3, 21841) ->(155.1.23.2, 80) [60062] *Mar 1 01:18:32.411: NAT*: TCP s=21841,d=80->8080 *Mar 1 01:18:32.411: NAT*: s=155.1.23.3,d=155.1.23.2->192.168.1.33 [60062] *Mar 1 01:18:32.447: NAT*: i: tcp (192.168.1.33, 8080) -> (155.1.23.3, 21841) [49] *Mar 1 01:18:32.447: NAT*: TCP s=8080->80, d=21841 *Mar 1 01:18:32.447: NAT*: s=192.168.1.33->155.1.23.2, d=155.1.23.3 [49]
In the end, here is the output of "show ip nat trans" on the border router when all this kind of traffic is generated. Take it as a practice exercise and try to identify what is each translation doing:
R2#sh ip nat trans Pro Inside global Inside local Outside local Outside global tcp --- --- 3.3.3.3:12345 3.3.3.3:8080 icmp 155.1.23.2:17 192.168.1.1:17 3.3.3.3:17 3.3.3.3:17 tcp 155.1.23.2:59833 192.168.1.1:59833 3.3.3.3:12345 3.3.3.3:8080 tcp 155.1.23.2:80 192.168.1.33:8080 155.1.23.3:21841 155.1.23.3:21841 tcp 155.1.23.2:80 192.168.1.33:8080 --- ---
Costi is a network and security engineer with over 10 years of experience in multi-vendor environments. He holds a CCIE Routing and Switching certification and is currently pursuing same expert-level certifications in other areas. He believes that the best way to learn and understand networking topics is to challenge yourself to fix different problems, production-wise or lab-type exams. He also enjoys teaching networking and security technologies, whevever there is an opportunity for it.
Comments
comments powered by Disqus