Jon,
Thanks for your reply. I am certainly going to try the port number addition in the configuration and will post my findings here. But I am still not sure why it doesn't work in the way I have configured it.
What I didn't mention in my first post is that I also use inside translations on the router. I'll post the full NAT config now. I removed the outside translation for 10.10.10.2 because I don't need it anymore, but that doesn't change the problem I am having.
ip nat pool pool-nat-ing 10.10.10.50 10.10.10.50 netmask 255.255.255.0
ip nat inside source route-map map-ing pool pool-nat-ing overload
ip nat pool pool-nat-ing_alt 10.10.10.60 10.10.10.60 netmask 255.255.255.0
ip nat inside source route-map map-ing_alt pool pool-nat-ing_alt overload
ip nat outside source static 10.10.10.1 10.90.3.1 extendable
ip nat outside source static 10.10.10.1 10.10.20.1 extendable
route-map map-ing_alt permit 10
match ip address acl-nat-ing-10.10.10.60
route-map map-ing permit 10
match ip address acl-nat-ing-10.10.10.50
ip access-list extended acl-nat-ing-10.10.10.50
permit ip host 10.101.19.1 host 10.90.3.1
ip access-list extended acl-nat-ing-10.10.10.60
permit ip host 10.10.20.40 host 10.10.20.1
What I see on the old router is that when a packet gets translated the port numbers are also kept in the NAT table. As far as I know this is due to the route-maps and extendable keyword being used:
Pro Inside global Inside local Outside local Outside global
tcp 10.10.10.50:3774 10.101.19.1:3774 10.90.3.1:7000 10.10.10.1:7000
So a full translation (including port numbers) is kept in the NAT table as seen above. I don't mention port numbers in the configuration, the IOS obviously keeps track of those automatically (at least the old IOS does).
When reviewing the information below, one should think my configuration should work (as it does on the old router). This information comes from the page http://www.cisco.com/en/US/technologies/tk648/tk361/tk438/technologies_white_paper09186a0080091cb9.html
• "Extendable" static translations:
The extendable keyword allows the user to configure several ambiguous static translations, where an ambiguous translations are translations with the same local or global address.
ip nat inside source static extendable
Some customers want to use more than one service provider and translate into each provider's address space. You can use route-maps to base the selection of global address pool on output interface as well as an access-list match. Following is an example:
ip nat pool provider1-space ...
ip nat pool provider2-space ...
ip nat inside source route-map provider1-map pool provider1-space
ip nat inside source route-map provider2-map pool provider2-space
!
route-map provider1-map permit 10
match ip address 1
match interface Serial0/0
!
route-map provider2-map permit 10
match ip address 1
match interface Serial0/1
Once that is working, they might also want to define static mappings for a particular host using each provider's address space. The software does not allow two static translations with the same local address, though, because it is ambiguous from the inside. The router will accept these static translations and resolve the ambiguity by creating full translations (all addresses and ports) if the static translations are marked as "extendable". For a new outside-to-inside flow, the appropriate static entry will act as a template for a full translation. For a new inside-to-outside flow, the dynamic route-map rules will be used to create a full translation.
Am I missing something here?
Regards,
Arjan Hummel
