NAT dropping traffic

Unanswered Question
Aug 24th, 2009

Hi

I have a p2p connection, a 3845 and 2821. When I have natting configured and applied it drops all my traffic but when I remove the "ip nat inside source list name inteface s0 overload" traffic moves through. what could be the problem, I have got the security ios on both routers? Below are the ios that are on these router's.

c2800nm-advsecurityk9-mz.124-25b.bin and

c3845-advsecurityk9-mz.124-25b.bin

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jon Marshall Mon, 08/24/2009 - 12:44

Your attached file shows the pings being successful not failing so i'm not sure what you mean.

Also, on the 2821 router shouldn't the loopback interface be 2.2.2.2 ie. your config -

2821

interface Loopback0

ip address 1.1.1.1 255.255.255.255

ip nat inside

ip virtual-reassembly

!

but 1.1.1.1 is on the 3825 as well ?

Perhaps you could clarify ?

Jon

mailaglady2 Mon, 08/24/2009 - 12:58

Sorry my mistake, it is indeed 2.2.2.2 on the 2821 it was a typing error but it's now fixed on the attachment. Pings are successfull but traffic don't go through. I have a traffic generator connected on the 192.1.1.1 and 192.2.1.1 networks.

Peter Paluch Mon, 08/24/2009 - 12:59

Hello,

What kind of traffic generator? D-ITG perhaps?

Does an ordinary traffic go successfully throught the NAT? Can you ping between two stations on those networks? Are you sure that no firewall is running on them?

Best regards,

Peter

mailaglady2 Mon, 08/24/2009 - 13:05

Agilent N2X, normally my traffic goes through. When I remove the command "ip nat source inside list name interface sx/x/x overload" my traffic goes through, and even when my traffic drops when I applied that command I can still get my respons from pings.

Jon Marshall Mon, 08/24/2009 - 13:04

Okay, that makes more sense.

From the file you have attached though, one thing for sure is that NAT is taking place as per your config and obviously between the routers your pings are successful.

So, as Peter suggested could you check the bits not related to the router ie.

end device firewalls

source and destination IP addresses ie. are you sure they fall in the right subnets to match the NAT acls.

Jon

mailaglady2 Mon, 08/24/2009 - 13:16

There are no firewalls connected on these routers, it's only these two routers and a traffic generator. As for the ip addressing I just double checked now on these routers, they look 100% correct.

Jon Marshall Mon, 08/24/2009 - 13:20

Okay.

Can you do a quick test.

1) clear any existing NAT translations on the 2 routers ie. "clear ip nat translations all" - i'm assuming you have no other NAT going on. If so you will need to be more specific and only clear translations relevant to this if indeed there are any.

2) Send traffic from one traffic generator to the other and then post "sh ip nat translations"

I'm assuming the traffic generators have their default-gateways set to the respective router LAN interface ?

Jon

mailaglady2 Mon, 08/24/2009 - 13:42

I have cleared all the translations "clear ip nat translations *", there's no other NAT going on, I have attached the results after clearing. the 1st results are when the traffic generator is sending traffic without the pings being generated and the 2nd part on the same notepad are when the pings are generated, but I am still not getting traffic on the recepient side on both routers.

Peter Paluch Mon, 08/24/2009 - 13:24

Hi,

What I am concerned about is that these traffic generators may in fact try to establish a control connection before starting to generate flows. I have seen software traffic generators (the D-ITG in particular) to fail when used in networks with NAT, as the endpoints exchanged the real (private) IP addresses in the control connection and afterwards they were not prepared to accept connections from NATted (public) IP addresses. This is a notoriously common problem with NAT when an IP address of an endpoing is not carried just in IP header but also as a payload of some internal protocol.

But regarding the NAT of both LAN networks, I am coming to yet another question: both LANs are considered as internal and they are both NATted using the "ip nat inside source". How do you expect to send a packet from one internal network to another? What address do you hope to use to reach the opposite internal network if it is NATted? There is no IP address to reach an endpoint in the opposite network - because on one side, due to the NAT, the IP space of the opposite network does not exist at all! I don't think that your scenario could work in this way.

Best regards,

Peter

mailaglady2 Mon, 08/24/2009 - 13:50

I am hoping to change my lan 192.2.1.0 to 192.10.10.2 from a 2821 router to reach the network 192.1.1.0 on the other/remote router being the 3845 and vice versa.

Peter Paluch Mon, 08/24/2009 - 14:06

Hello,

This is not going to work - with your NAT configuration (the overload of the "inside source"), the NAT translation entries are first created when a packet goes from inside to outside, not vice versa. But you are trying to do precisely that - you want to send a packet to the outside address of the opposite LAN network and expect that the opposite router will somehow come up with an internal address to which that packet shall be resent. But how should it do that? How shall it know which internal IP address should that packet be forwarded to? On the 3845 router, you have the 1.1.1.1/32 and 192.1.1.0/24 address ranges as internal networks. Which IP out of these should receive the packet you have sent to 192.10.10.1?

Actually, your configuration seems to contain another grave problem: despite the network 192.1.1.0/24 and 192.2.1.0/24 being internal networks, you are advertising them in your EIGRP routing protocol, so in fact your routers know about them. Now, if a machine in 192.1.1.0/24 network sends a packet directly to 192.2.1.x, that packet will arrive addressly to the 192.2.1.0/24 network - but when a reply is sent, that reply will be, according to the NAT configuration, translated from 192.2.1.x to 192.10.10.2 - a completely different address than expected in a reply. This is undoubtedly one of reasons that the traffic flows seem to be dropped.

If you want to do this with NAT you will probably have to define static NAT entries to have fixed entries in the translation tables. But you absolutely cannot use overload NAT to reach from one internal network to another.

Best regards,

Peter

mailaglady2 Mon, 08/24/2009 - 23:21

When do I use NAT overload? I thought overload is for using multiple inside local address to one inside global address.

Peter Paluch Mon, 08/24/2009 - 23:42

Hello,

You are correct, the NAT overload is used to hide multiple internal addresses behind a smaller count of outside addresses.

But the NAT overload as you are using it here is only suited for providing connections initiated from the inside and going outside, not in the opposite direction. When you initiate a connection from the inside, the router will create a translation record in its NAT database and when a reply comes back from the outside, the router first translates it back to the original recipient and only then it routes it into the internal network.

But when the connection is initiated from somewhere outside to the global IP, there is no corresponding translation entry created at all in the translation database. The router will accept that packet but the translation database does not have any corresponding entry and the router will not be able to forward that packet. After all, to whom should be that packet forwarded? There are hundreds of IPs inside your local network. Which one should be the recipient? According to which rule? What rule tells us that if we send a packet to 192.10.10.1, its real recipient should be, say, 192.1.1.2? Can you see or deduce such rule from your configuration? And what if it was not 192.1.1.2 but 192.1.1.3? Or .4? Or .127? Where is it said in your configuration how the 192.10.10.1 corresponds to a particular and unique inside local address? It is not written anywhere - because these mappings are created on the fly when a connection is initiated from the inside but not vice versa.

Please do not take my response here as being angry because of the count of questions. I am posting them here so that you can think about them, try to answer them and see that there is a logical flaw in how you deployed the NAT and how you intend to use it.

Once again - the overload NAT in your configuration is used for NATting connections that originate on the inside networks and go outside. It is not usable for connections that are initiated from outside with an intention to reach an inside network.

Best regards,

Peter

mailaglady2 Tue, 08/25/2009 - 11:30

Oh, I think I understand you now. My problem here is I thought since my packet had a source and destination IP address the routing protocol knew how to get to the destination, it won't be a problem whether the source ip add changes or not it will still get to the destination since it had the route on it's routing table. I need to use the port number's to be able to get into the remote inside network(outside local address), right?

Peter Paluch Tue, 08/25/2009 - 13:52

Hello,

You defeat the whole purpose of the NAT if you advertise your internal networks in a routing protocol. If you are NATting a network, you do not want anyone outside to be aware of its existence. An internal network should therefore never be advertised to the outside in a routing protocol.

Thinking that "let the IP addresses be public or private, it does not matter, they are all known in the routing table so it should work" is not correct. Note that the NAT code works in conjunction with routing and it can significantly influence the routing decisions. Read this document to understand the order of NAT operations:

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml

If you want to test your network using NAT, you must define static mappings between your internal and external addresses - a static NAT. I do not recommend using ports (port forwarding) unless you are absolutely sure that your traffic generators do not require any additional ports for their own operation.

Best regards,

Peter

Actions

This Discussion