NAT setup

[cbyrnes]

If NAT is configured and operational, with Fa0/0 being inside, and Ser0/0.1 being outside, is it possible to use an ACL to permit specific inbound traffic on ser0/0.1?

Presently, an ACL is set up to allow ICMP echo & echo-replies inbound on Ser0/0.1. However, when an echo request comes in, it is routed (it seems) without address trans. ever taking place. Ie., the router sends it back to the source, creating the dreaded routing loop.

According to Nat Order of Operation, this should work (I think). Inbound echo, check ACL, handoff to NAT. But it doesn't.

I have been working on this for some time, and have read volumes without getting anywhere. Any insight is appreciated.

Thanks,

Cbyrnes

[cbyrnes]

Follow up - I am also wondering if the subnetting could be causing this prob. I have added a static route to the routing table, but it's not helping.

Our ISP has assigned our connection as an ABC.x.x.108/30 address. The public IPs they gave us for NATing are ABC.y.y.128/29. This aggregates as ABC.0.0.0/8. We are running RIP v2, with Ser0/0.1 passive. Thinking maybe the router can't deal with this ....

[freivald]

Seeing your NAT configuration might be helpful. Since you presented this as a group of addresses, I am, at great risk, going to *assume* that you are using a pool of addresses with dynamic nat.

If you have a ping packet coming in on the nat outside interface, then it would have to be communicating either with a statically translated address, or with a dynamic address that has already been added to the nat table through the use of outgoing traffic. Either way, the nat entry must already be established. If it is dynamic, you would have to generate the outgoing traffic, verify that the nat entry now exists, then from outside ping the address that was selected from the pool.

If the entry has not been established, then it is not skipping nat, as you speculated. Nat simply lets it go unprocessed because it has no entry in its table. This would allow it to be routed according to the unnatted address.

But there seems to be an additional problem. Why would you have a routing loop? You should not be routing your inside global addresses (ABC.y.y.128/29) back to your ISP. I have seen people use a loopback on the same subnet as the IG addresses to get the subnet into the routing protocol, and I have seen a static route to the null interface also recommended. Neither of these, of course, are ever intended to route the traffic, since nat should get it first if things are done right.

I hope this is helpful,

Mark

[cbyrnes]

Mark,

Thanks for the reply - I've been going round and round on this for days.

As regards the routing loop: The inside global addresses are a /29 pool, used for static NAT; Ie., the mail server, web server, etc. This subnet is NOT the same as the ISP link, which is a /30 - only 2 usable addresses, their end and mine. The route to S0/0.1 & the route to the inside global subnet aggregate to a class A net - ABC.0.0.0/8 - I don't think this works w/RIP. I realized that I'm only seeing the loop when I don't apply the ACL to S0/0.1 inbound. This fits with the your thoughts - NAT just doesn't process it. Since RIP sees the route to the Class A, ABC.0.0.0/8 as S0/0.1, is forwards it to the ISP's router, who sends it back, etc. At any rate, I believe, as you said, that this is a secondary or non-issue.

Right now, packets come inbound to a pre-existing static NAT entry, while outbound traffic goes through dynamic NAT overloaded on S0/0.1's IP. Assume a packet comes inbound, is accepted by the ACL, and gets passed off to NAT. The packet out of NAT will now have the inside local address as it's dest. At this point, there should be no routing problem, but it doesn't go through - the problem at the heart of all this.

The big question is why the packets don't go through after natting. I'm wondering if I need to change or add to NAT. Is there any way for me to view packet activity after NAT ? (IOS 12.0(7) Any thought on what might cause this ? Do you think this is what's going on ?

Thanks,

Chris

[freivald]

Well my stab in the dark missed, and there is still a lot of darkness hanging over your problem. As I said before, it might certainly lighten up the issue if you provided the sterilized config.

But, until then, let's see if these night-vision goggles will help...

It sounds as if you haven't actually verified whether NAT is, or is not, taking place. Have you done some debugging on NAT to determine if it is translating? If it is, you probably don't have a NAT problem; you just need to figure out the routing that NAT has presented you. If it isn't translating, then something seems to be broken with the NAT part of your configuration.

The first thing I would do is the debugging, if you haven't. Are the translations corresponding to the static entries taking place? Is the dynamic natting working? Can you ping from the inside and get a good dynamic translation entry? Can you ping to the outside using one of the statically translated addresses? If it is not translating, I don't know if I will be able to assist without seeing the configuration, but let's get a list of what you can and cannot do.

If it is, we would seem to have a routing problem. I see now how the aggregate would cause a loop, but I find this to be unfavorable. If we get things working right, though, NAT should break that loop. Are you using RIP v1 or v2? Do you have a route to your inside local addresses, and can you ping them from the router? Do you have a route to your outside destination addresses other than the aggregate? Can you do an extended ping to an outside destination using the s0/0.1 as the source IP? Are you running RIP with the ISP? Another list is in order here. What works, and what doesn't? Clearly, it would help to see the configuration in order to sort out the routing, too.

Flailing in the dark,

Mark

[cbyrnes]

Mark,

Sorry, ACL and NAT below:

access-list 105 permit tcp any any established

access-list 105 permit tcp 'outside host ip' M.p.q.130 255.255.255.248 eq 80

access-list 105 permit smtp any M.p.q.129 25

access-list 105 permit udp any any

access-list 105 permit icmp any any echo

access-list 105 permit icmp any any echo-reply

access-list 105 permit icmp any any time-exceeded

access-list 105 permit icmp any any packet-too-big

access-list 105 permit icmp any any traceroute

access-list 105 permit icmp any any unreachable

access-list 105 deny icmp any any log

access-list 105 deny tcp any any log

ip nat pool xlate M.n.o.110 m.n.o.110 netmask 255.255.255.252

ip nat inside source list 1 interface Serial0/0.1 overload

ip nat inside source static tcp a.b.c.11 80 M.p.q.130 80 extendable

ip nat inside source static tcp a.b.c.15 110 M.p.q.129 110 extendable

ip nat inside source static tcp a.b.c.15 25 M.p.q.129 25 extendable

Debug NAT not possible (hung the router). Maybe after hours one evening... 'sho ip nat translations' shows xlations taking place. Both static and dynamic entries are listed in the table. I have chng'd all routers to RIP v2. All inside locals route fine, both in and out, and are 'pingable' frm router and vise-versa. S0/0.1 pings, in & out, OK. The default-gateway is set to S0/0.1. S0/0.1 is passive, no routing w/ISP.

Again, thanks for the assist. As I said, I've tried to figure this out, but it makes no sense at this point.

Chris

[freivald]

Hello, Chris.

First, your access lists are not causing you a problem. You are blocking some ICMP types, but the ones you are working with, ping and traceroute, seem to be allowed.

I am a little confused about your last message. It sounds like dynamic NAT is working fine, and there are no problems associated with it - is this right?

You say that all inside locals route fine - are you saying that you can ping the static IL addresses from a host on the outside, but not the global addresses? With your present configuration, I would expect this. Your static commands are translating on ports 80, 110 and 25 for http, pop3 and smtp respectively. None of these entries allow ICMP. You can't test these translations with ICMP, you will have to test them with their respective protocols. See if you can connect with a browser to the web server corresponding to the IG address with port 80. I would have to ask my mail-server friends to figure out how to easily test the pop3 and smtp ports.

You might try something like:

ip nat inside source static tcp l.l.l.l 23 g.g.g.g 23 extendable

and test using telnet instead of icmp (or maybe you can figure out a nat command that will translate just icmp). Or you could simply drop the port numbers in the configuration until you are done testing.

So let's just examine quickly what occurs when you try to ping the global addresses.

1. Ping packet is encapsulated with global destination address and sent to your router.

2. Your router receives the ping packet and permits it through the ACL since ICMP is allowed.

3. Your router's NAT looks at the ping packet and checks the translation table. None found - even though the address exists in NAT table for a specific port, a translation for *ICMP* is not found.

4. Your router's NAT passes the packet on untranslated and IP consults the routing table.

5. IP finds the most specific route, which winds up being your aggregate pointing traffic to the ISP.

6. Ping packet loops until TTL expires.

To summarize - if I understand everything you have described correctly, NAT and routing are both working fine, but you are trying to get it to translate something for which it is not configured. If I were you, I would probably replace one of the static commands with a command excluding the port numbers, test it with ping, then reconfigure the port numbers which would disallow any pinging to those global addresses, but not to the local addresses. Then I would test the respective protocols with your applications.

Does this make sense to you?

ciao,

Mark

[cbyrnes]

Mark,

"My availability for the next couple weeks has become dear, but I will try to follow up on this as I can."

Understood.

"You are blocking some ICMP types, but the ones you are working with, ping and traceroute, seem to be allowed. Since you are allowing these already,

what are you trying to block and log with deny ICMP any any log? "

ICMP redirects, multicasts, etc., per Cisco security write-ups.

"I am a little confused about your last message. It sounds like dynamic NAT is working fine, and there are no problems associated with it - is this right? "

Yes.

"You say that all inside locals route fine - are you saying that you can ping the static IL addresses from a host on the outside, but not the global

addresses? "

No, IL IPs are not routable - 192.168.x.x - I meant that within my WAN, everything that should be reachable is, from both on-site and remote nodes,

as well as having access to the web, mail, etc.

"Your static commands are translating on ports 80, 110 and 25 for http, pop3 and smtp respectively.

**** None of these entries allow ICMP. **** "

This is what finally jumped out at me when I emailed you directly.

"You can't test these translations with ICMP, you will have to test them with their respective protocols."

SMTP, POP3 come and go w/o any probs.

"So let's just examine quickly what occurs when you try to ping the global addresses.

1. Ping packet is encapsulated with global destination address and sent to your router.

2. Your router receives the ping packet and permits it through the ACL since ICMP is allowed.

3. Your router's NAT looks at the ping packet and checks the translation table. None found - even though the address exists in NAT table for a

specific port, a translation for *ICMP* is not found."

I believe you've hit the nail on the head.

"4. Your router's NAT passes the packet on untranslated and IP consults the routing table.

5. IP finds the most specific route, which winds up being your aggregate pointing traffic to the ISP.

6. Ping packet loops until TTL expires."

"To summarize - if I understand everything you have described correctly, NAT and routing are both working fine, but you are trying to get it to translate something for which it is not configured. If I were you, I would probably replace one of the static commands with a command excluding the port numbers, test it with ping, then reconfigure the port numbers which would disallow any pinging to those global addresses, but not to the local addresses."

Have been continuously testing, and Mon. tried what you have suggested - set up a static xlation w/o the port, and it works, both from inside and outside

the LAN. If I configure correctly, IG IPs will be pingable, IL will not.

I think I'm finally close to getting this right, thanks in no small part to your help and insight.

Thanks again,

Chris Byrnes