NAT Question

this doesn't sound like a NAT/PAT issue.  you said you configured PAT already.  so when a user goes out, a translation entry is added to a nat translations table

show ip nat translation

what it sounds like is a stateful firewall issue since you are using a router it doesn't do it by default.  ASA's because they are meant to be firewalls most always have stateful features turned on out of the box.  IOS devices don't do this.  So when the 192.168.100.x client connects to 1.1.1.1:8080, it creates the translation entry because one doesn't exist but it also (I'm guessing) doesn't have an ACL applied to the inside interface in the inbound direction so the traffic is allowed.  The return traffic doesn't have an ACL that allows that packet specifically so it doesn't even get to the point where it looks up the nat translation entry to be able to get the packet back to the client.  Stateful firewalling dynamically creates those ACL entries to allow that return traffic because the original start of the "conversation" was allowed.

What you need to do is configure "inspection" and I would recommend using "zone based firewall" mechanism as that is the latest and most supported way to do firewalling on IOS devices.

Here is a doc outlining how to define zones, assign interfaces, create policies, and apply them.  https://supportforums.cisco.com/docs/DOC-27487

If you have any questions (which is most likely I'm guessing) please let me know and I'll try to answer any followup questions you have.

I will put this on a router and let you know how it works - sounds like I will just need to also put the inspect command on the inside zone then?

you'll need to convert your current outside to inside to this as well so you'll be adding inspection there as well or it'll start getting denied.  zone based is much different than old style of simply creating an ACL and applying to an interface.

If you really don't want to do that, CBAC style (the style being replaced) should still be valid syntax so you could look into using that which only involves adding inspect statements to the config and might be easier for you to implement.

http://packetlife.net/blog/2009/mar/10/ios-context-based-access-control-cbac/

It's up to you whichever you think is better.  I just brought up zone based as I know that is the current way Cisco wants things to be done.

So I tried the CBAC style for a quick attempt --did not work, the problem may be I am patting to the same address I am trying to access

the IP address does not show up in the IP nat translations

this is what shows
tcp GigabitEthernet0/0 _IP:55327    10.15.1.11:55327      xxxxxx:443      xxxxxx::443
tcp GigabitEthernet0/0 _IP:63491    10.15.1.11:63491      xxxxxx::443      xxxxxx::443


here are my nat statements

ip nat inside source list ls_acl interface GigabitEthernet0/0 overload
ip nat inside source static tcp 10.15.4.152 80 interface GigabitEthernet0/0 8087

CBAC doesn't care about PAT/NAT/DynNAT.  It all processes things in a way to make that a moot point (e.g. won't translate then evaluate return traffic so IPs are different and mess up lookup)

Can you post the ACLs you have and the CBAC you configured so far.

ip inspect name firewall tcp
ip inspect name firewall udp
ip inspect name firewall icmp

interface GigabitEthernet0/0
ip access-group FIREWALL in

ip access-list extended FIREWALL
 permit ip any any


I am just starting with an any any ACL now to make sure I get it working before adding anything else

first off, if you are allowing all traffic, for routers you can just leave off the ACL "ip access-group" application and its the same thing

you created the inspect list but didn't apply it.  you need to apply it as the traffic is leaving the router.  so if G0/1 is the outside interface you'd do this

int g0/1
ip inspect firewall out

this will inspect the traffic as it is leaving that interface and record the necessary data for when the return traffic comes back.

sorry I do have the command on there - I did not copy it over

interface GigabitEthernet0/0
 ip address xxxxxxxxxxxxxxxxxxxxx
 ip access-group FIREWALL in
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat outside
 ip inspect FIREWALL out
 ip virtual-reassembly in
 duplex auto
 speed auto
 no cdp enable
 service-policy output SHAPE

the name is case sensitive I'm pretty sure so if you used all caps applying it and all lowercase creating it, the ip inspect list you created actually never gets applied

ok so the case has now been corrected - and still same issue

well that's not good.  that should work.  please post config again.  also what device is this (model) and what IOS version are you running.  I'll try to get my routers at home semi-mirrored to yours to see if I can figure it out as based on what I see right now it all looks good.

finally before you do that try the audit-trail and debug stuff in that link I gave you earlier.  see if that helps at all.

ip nat inside source static tcp 10.15.4.10 80 interface GigabitEthernet0/0 8081
ip nat inside source list ls_acl interface GigabitEthernet0/0 overload

ip access-list extended FIREWALL
 permit ip any any

interface GigabitEthernet0/0
 ip address xxxxxxxxxxxxxxxxxx
 ip access-group FIREWALL in
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat outside
 ip inspect firewall_out out

ip inspect name firewall_out tcp
ip inspect name firewall_out udp




the audit trail debug never really showed it making a connection back in

ok, well i'm sorry but I led you down the wrong road.  I've been looking over this for a few hours as it's irritating me now.  I know this is possible but its not the inspect thing (not saying that may not be part of the problem though as IOS acl's are stateless by default so inspects most likely are needed).  however, what I'm seeing is that your client will be translated but at that point it makes up its mind where it is forwarding.  The only way that the 1.1.1.1 gets translated to the inside server is if the packet is received on that 'ip nat outside' interface.  because it isn't actually being received there, it can't do it.  I got it working in my lab setup by switching the inside interface to an outside but then it breaks it for clients going out to anything else (so obviously no go on that one).

trying to figure out how to do a destination nat for packets being received on the inside interface but calling it quits for tonight.  just figured I give ya an update and to say I'm not leaving you out to dry

Been looking at another way to doing nat:  domain-less.

http://blog.ine.com/2008/02/15/the-inside-and-outside-of-nat/

looks like it'll solve your problem but haven't fully tested it out yet to ensure no side effects.  will let you know later.  way past bed time at this point.  :)

any update?

sorry, planning on testing this further tonight.  just been slammed with work and family lately I haven't had a chance to look at it again.  Have some time tonight after work though.

very helpful and well put