Can’t figure out this NAT problem, I need help

solnsusie

Hi

I'm trying to configure this Dynamic NAT configuration on my Cisco router, but when I try to ping from a host on one of this inside local networks the ping is not working, it just not going out to other networks, the tracerout ends at the inside FA0/0 of the router, can anybody tell me what its wrong in this NAT Configuration, when I’m taking off the NAT configuration everything works great, and when I reconfigure it with this NAT configuration its getting stuck, so the problem is positive in this NAT configuration, can anybody please help me

thanks a lot


this is the setting on the router:



interface FastEthernet0/0
no ip address
duplex auto
speed auto

interface FastEthernet0/0.2
encapsulation dot1Q 2
ip address 192.168.1.1 255.255.255.248
ip nat inside
ip summary-address eigrp 1 192.168.1.0 255.255.255.248 5

interface FastEthernet0/0.3
encapsulation dot1Q 3
ip address 192.168.1.9 255.255.255.248
ip nat inside
ip summary-address eigrp 1 192.168.1.8 255.255.255.248 5

interface Serial1/0
ip address 10.1.1.1 255.255.255.252
ip nat outside

router eigrp 1
network 192.168.1.0 0.0.0.7
network 192.168.1.8 0.0.0.7
network 10.1.1.0 0.0.0.3
no auto-summary

ip nat pool dynat 193.168.1.50 193.168.1.100 netmask 255.255.255.128
ip nat inside source list 1 pool dynat

access-list 1 permit host 192.168.1.5
access-list 1 permit host 192.168.1.6
access-list 1 permit host 192.168.1.13
access-list 1 permit host 192.168.1.14

networker050184

Does the distant end have a route back to the 193 network you are translating to?

wrwarwick

networker050184 wrote: »

Does the distant end have a route back to the 193 network you are translating to?

This. I don't know how many times I've slammed my head on my desk only to realize that the packet didn't have a path to return on.

solnsusie

networker050184 wrote: »

Does the distant end have a route back to the 193 network you are translating to?

As I said, without the NAT configuration it works perfect!!! So it has a way back!

networker050184

solnsusie wrote: »

As I said, without the NAT configuration it works perfect!!! So it has a way back!

Yeah, but with the NAT config your IP packet is going to have a different source address. Again, does it have a way back for the 193 addresses or just the 192? I see you have the 192 in EIGRP, so unless you have some statics or a default I doubt you have a route back.

solnsusie

wrwarwick wrote: »

This. I don't know how many times I've slammed my head on my desk only to realize that the packet didn't have a path to return on.

As I said, without the NAT configuration it works perfect!!! So it has a way back!

Chipsch

solnsusie wrote: »

As I said, without the NAT configuration it works perfect!!! So it has a way back!

Exactly, without the NAT configuration it works perfect. Take a step back and look at your configuration. When you go out sourced from the 192.168.1.5 you are advertising those routes. You are changing the source address of the packet after it goes through NAT to 193.168.1.50 or so address. Networker050184 already hit the nail on the head with this.

solnsusie

networker050184 wrote: »

Yeah, but with the NAT config your IP packet is going to have a different source address. Again, does it have a way back for the 193 addresses or just the 192? I see you have the 192 in EIGRP, so unless you have some statics or a default I doubt you have a route back.

now I see what you are saying, and it make sense, but let me clarify if I understand it fully, what you say is that the router on the other end doesn’t have in his routing table any rout to 193! am I correct on this? so what I have to do is to add a route of the 193, am I correct?

and if it’s like this? how come it's not mentioned in any of my learning resources which includes Wendell Odom & Todd Lammle that we need to add such a route? now I see that its common sense, but still not everybody has such a brain to get it!!!!!

thanks a lot, i will get back to you to see if it’s working

solnsusie

Chipsch wrote: »

Exactly, without the NAT configuration it works perfect. Take a step back and look at your configuration. When you go out sourced from the 192.168.1.5 you are advertising those routes. You are changing the source address of the packet after it goes through NAT to 193.168.1.50 or so address. Networker050184 already hit the nail on the head with this.

like i just replied to Networker050184 it makes a lot of sense what he says, I’m going now to try it out, thanks a lot

solnsusie

networker050184 wrote: »

Yeah, but with the NAT config your IP packet is going to have a different source address. Again, does it have a way back for the 193 addresses or just the 192? I see you have the 192 in EIGRP, so unless you have some statics or a default I doubt you have a route back.

a quick question, do i creat a 193 route? or i creat a static route? i dont think a 193 route will work, since its not configured on any interface!!!

pham0329

Static routing would be fine. Your NAT IPs doesn't have to be assigned to an actual interface...or else you would have tens or hundreds of secondary IP addresses assigned.

solnsusie

pham0329 wrote: »

Static routing would be fine. Your NAT IPs doesn't have to be assigned to an actual interface...or else you would have tens or hundreds of secondary IP addresses assigned.

thanks a lot, i will try it out later, and i will get back to you!

solnsusie

pham0329 wrote: »

Static routing would be fine. Your NAT IPs doesn't have to be assigned to an actual interface...or else you would have tens or hundreds of secondary IP addresses assigned.

thanks, it works great, but its the hard way when i use a diffrent ip range for the inside global address then the original outgoing ip address, because i need to configure static routes on all router all the way back to this router, so to eliminate this i will have to use only the outgoing ip address for the inside global ip address.
any way, thanks a lot for all of you for your time to help me.

solnsusie

networker050184 wrote: »

Yeah, but with the NAT config your IP packet is going to have a different source address. Again, does it have a way back for the 193 addresses or just the 192? I see you have the 192 in EIGRP, so unless you have some statics or a default I doubt you have a route back.

thanks, it works great, but its the hard way when i use a diffrent ip range for the inside global address then the original outgoing ip address, because i need to configure static routes on all router all the way back to the source router, so to eliminate this i will have to use only the original source outgoing ip address for the inside global ip address.
any way, thanks a lot for all of you for your time to help me.

networker050184

solnsusie wrote: »

thanks, it works great, but its the hard way when i use a diffrent ip range for the inside global address then the original outgoing ip address, because i need to configure static routes on all router all the way back to the source router, so to eliminate this i will have to use only the original source outgoing ip address for the inside global ip address.
any way, thanks a lot for all of you for your time to help me.

In the real world you aren't going to log into every router across the internet and put static routes in place. Hopefully you have BGP running, or your provider is announcing for you. You can simulate this in the lab also, but its a bit ahead of you I believe. For now, static routes are probably your easiest. Either that or on the originating router put a static to null and advertise it into EIGRP. That's probably a bit ahead of your knowledge level also though.

solnsusie

networker050184 wrote: »

Either that or on the originating router put a static to null and advertise it into EIGRP. That's probably a bit ahead of your knowledge level also though.

what do you mean with "static to null"? maybe I know what it is, I know about a null0 route in the eigrp routing table, is this what you are referring to?,

networker050184

solnsusie wrote: »

what do you mean with "static to null"? maybe I know what it is, I know about a null0 route in the eigrp routing table, is this what you are referring to?,

I'm talking about a static route to null0 and then redistribute static into EIGRP.

solnsusie

networker050184 wrote: »

I'm talking about a static route to null0 and then redistribute static into EIGRP.

i have no idea what it is, and how to do it, im now allmost done with CCNA, and i didnt sew anything like such a configuration, do i need to know it for the CCNA? if not, i will look it up at Google, so i will know how to do it,

thanks a lot

networker050184

No, I don't think that is anything you need to know for the CCNA. Just keep in mind that there is MUCH more to the world of networking than whats covered in the CCNA.

pham0329

I remember studying for the CCNA and thinking to myself "this isn't so bad..."...then you get the CCNP, and you find out how little you actually know...

jamesp1983

pham0329 wrote: »

I remember studying for the CCNA and thinking to myself "this isn't so bad..."...then you get the CCNP, and you find out how little you actually know...

Wait until you start studying for the CCIE...



To the OP... once you start doing this work in the real world you will learn a lot of "outside the book" material. Running debugs would be useful in figuring out what's going on with this type of issue (especially in a lab environment where you have access to both ends of the communication), but be careful using the debug commands for obvious reasons. Again, you most likely will not have access to the remote end devices to run some of the debugs on, but Cisco has a lot of information on troubleshooting various NAT issues. The issue you were having is covered actually... (missing a route on the destination back to the inside global). This link should prove helpful in the future (especially the animations): Verifying NAT Operation and Basic NAT Troubleshooting - Cisco Systems.

Congrats on your choice to pursue the CCNA!

solnsusie

jamesp1983 wrote: »

Wait until you start studying for the CCIE...To the OP... once you start doing this work in the real world you will learn a lot of "outside the book" material. Running debugs would be useful in figuring out what's going on with this type of issue (especially in a lab environment where you have access to both ends of the communication), but be careful using the debug commands for obvious reasons. Again, you most likely will not have access to the remote end devices to run some of the debugs on, but Cisco has a lot of information on troubleshooting various NAT issues. The issue you were having is covered actually... (missing a route on the destination back to the inside global). This link should prove helpful in the future (especially the animations): Verifying NAT Operation and Basic NAT Troubleshooting - Cisco Systems.Congrats on your choice to pursue the CCNA!

Thanks a lot, your post was really helpfull, and I was posting this problem a few weeks ago, and no body was able to help me, so I tought I will try again, and now I got my answer, again, thanks a lot,