Solved: NAT configuration issue cisco 2621

juanalejo · ‎10-05-2009

Hello,

I'm using NAT with overload to translate IP adresses from a small office into an IP adress from the main office. The connection from the branch office with the main office is OK and the NAT is working, but the connection between main office and small office doesn't work. I think that is due to the reponse packets are being translate when they are travelling through the inside interface. How can I resolve this issue?

Richard Burts · ‎10-06-2009

Juan

While Oussama makes some interesting points I believe that the fundamental problem is different than what he describes. NAT as you are doing it (which is actually PAT since you are translating multiple inside addresses to a single outside address) creates an entry in the translate table when it sees outgoing traffic from the inside interface. This allows an inside host to initiate traffic and when an outside host responds there is an entry to translate back to the correct inside address.

But PAT does not support traffic initiated from an outside host (at the main office) to reach a remote host (at the branch office) since it does not know what entry in the translate table to use.

Perhaps another way to look at this issue is that if the inside host has address 192.168.1.5 the host at the main office does not have any route to get to that address and there may not be any entry in the translate table for that address (and even if there were an existing translate entry, how would the main office host know what it was?).

So if you have a requirement for main office hosts to initiate traffic to the branch office hosts then you will need some different solution. In some cases it is possible to not translate traffic from the remote office going to the main office and provide a routing entry at the main office for the remote office network, and just translate for traffic from the branch that is going outside of the enterprise network. Perhaps that could work for you?

HTH

Rick

HTH

Rick

View solution in original post

Jon Marshall · ‎10-05-2009

Juan

It's not clear from your description what the problem is. Could you do a quick diagram and post any relevant configs so we can help you.

Jon

juanalejo · ‎10-06-2009

Hi Jon,

First of all, I'm sorry about my English, because it's not very good.

I've made a quick diagram of my situation. The problem is that I must make NAT in the main router because it's necessary that the source IP of the packages which are comming from the branch office are 172.21.60.48, but also I need to access to the branch office from the main office and it doesn't work.

Thank you.

ohassairi · ‎10-06-2009

this normal.

suppose one PC (172.21.60.1) from main office try to connect to one PC (192.168.1.5) in remote. the first packet will reach the remote PC but when the remote PC will answer the NAT will occur so 172.21.60.1 will see the response coming from 172.21.60.48.

the solution is: try to modify the ACL. if you need NAT for only one kind of traffic (web, telnet,...) so add these protocols to the ACL. doing so will not trigger the NAT when HO contact remote office

Richard Burts · ‎10-06-2009

Juan

While Oussama makes some interesting points I believe that the fundamental problem is different than what he describes. NAT as you are doing it (which is actually PAT since you are translating multiple inside addresses to a single outside address) creates an entry in the translate table when it sees outgoing traffic from the inside interface. This allows an inside host to initiate traffic and when an outside host responds there is an entry to translate back to the correct inside address.

But PAT does not support traffic initiated from an outside host (at the main office) to reach a remote host (at the branch office) since it does not know what entry in the translate table to use.

Perhaps another way to look at this issue is that if the inside host has address 192.168.1.5 the host at the main office does not have any route to get to that address and there may not be any entry in the translate table for that address (and even if there were an existing translate entry, how would the main office host know what it was?).

So if you have a requirement for main office hosts to initiate traffic to the branch office hosts then you will need some different solution. In some cases it is possible to not translate traffic from the remote office going to the main office and provide a routing entry at the main office for the remote office network, and just translate for traffic from the branch that is going outside of the enterprise network. Perhaps that could work for you?

HTH

Rick

HTH

Rick

juanalejo · ‎10-06-2009

Hello,

You are right, if I only translate the traffic from the branch to outside of my enterprise network I can access from the main office to the remote office.

I've used the extended ACL:

access-list 101 ip 192.168.1.0 0.0.0.255 DESTINATION DESTINATION-WILDCARD

Thank you very much for your help.

Regards,

Juan.

Richard Burts · ‎10-06-2009

Juan

I am glad that my suggestion pointed you toward a solution and that you now have it working satisfactorily. If the problem is solved then perhaps you can use the check box to indicate that the issue is resolved. This will help other users in the forum to know that they can read about the issue and will find a solution for the issue.

HTH

Rick

HTH

Rick