Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
?
Solved

ASA upgrade from 8.2 to 8.3 - no more incoming traffic

Posted on 2012-08-27
86
Medium Priority
?
1,489 Views
Last Modified: 2012-10-01
So I upgraded our ASA a week ago and while testing quickly discovered that while all outbound traffic seemed to go out fine I could not hit any of our websites from external. Nor could I get SMTP traffic inbound either.

For the upgrade I used our existing active running config from the 8.2 ASA and restored it to the upgraded 8.3 ASA and let the software do its thing. I reviewed the code afterwards and it "looks" fine to me but obvoiusly something is a miss.

I've attached a few snipettes that pertain to our web server - our current setup is to allow http traffic through and nat to its internal address - .18 is the address of our internal web server

access-list OUTSIDE-IN extended permit tcp any host 216.223.xx.xx eq www 
object network obj-10.1.1.18
 host 10.1.1.18
nat (inside,outside) source static obj-10.1.1.18 obj-216.223.x.x-01 service obj-tcp-source-eq-80-01 obj-tcp-source-eq-80-01

Open in new window


There are some startup errors though most of them pertain to managing the ASA using Telnet, and SSH. Here's the only one I think that would pertain to my issue:

*** Output from config line 412, "access-list acl_out extended permit tcp host 10.1.1.14 any eq smtp "
WARNING: This command will not take effect until interface 'inside' has been assigned an IPv4 address

Open in new window


Not sure what the WARNING is about as that interface has an IPv4 address and v6 is currently disabled.

Any suggestions on where my issues may lie?
0
Comment
Question by:ITGeneral
  • 40
  • 30
  • 11
  • +3
86 Comments
 
LVL 18

Expert Comment

by:Garry Glendown
ID: 38337165
according to that warning, your inside interface doesn't have an IP assigned ... can you post the config part where the interface is configured?
0
 
LVL 29

Expert Comment

by:Jan Springer
ID: 38337166
It sounds like out of order NAT rules:

show nat detail
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38337329
In 8.3+ code you have to reference the real IP address of the server on the outside ACL, instead of the external NAT. So:

access-list OUTSIDE-IN extended permit tcp any host 216.223.xx.xx eq www

would become

access-list OUTSIDE-IN extended permit tcp any host 10.1.1.18 eq www
0
NFR key for Veeam Backup for Microsoft Office 365

Veeam is happy to provide a free NFR license (for 1 year, up to 10 users). This license allows for the non‑production use of Veeam Backup for Microsoft Office 365 in your home lab without any feature limitations.

 

Author Comment

by:ITGeneral
ID: 38337336
Here's the code for the Inside Interface:

interface Ethernet0/2
 description Inside LAN Interface - VLAN 994
 nameif inside
 security-level 100
 ip address 10.1.10.67 255.255.255.0 

Open in new window


Here's the nat detail:

Manual NAT Policies (Section 1)
1 (inside) to (any) source static any any destination static obj-192.168.254.0-01 obj-192.168.254.0-01 unidirectional
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 0.0.0.0/0, Translated: 0.0.0.0/0
    Destination - Origin: 192.168.254.0/24, Translated: 192.168.254.0/24
2 (inside) to (any) source static obj-172.16.2.0-01 obj-172.16.2.0-01 destination static obj-192.168.252.0-01 obj-192.168.252.0-01 unidirectional
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 172.16.2.0/24, Translated: 172.16.2.0/24
    Destination - Origin: 192.168.252.0/28, Translated: 192.168.252.0/28
3 (inside) to (any) source static obj-172.16.3.0-01 obj-172.16.3.0-01 destination static obj-192.168.252.0-01 obj-192.168.252.0-01 unidirectional
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 172.16.3.0/24, Translated: 172.16.3.0/24
    Destination - Origin: 192.168.252.0/28, Translated: 192.168.252.0/28
4 (inside) to (any) source static obj-172.16.5.0-01 obj-172.16.5.0-01 destination static obj-192.168.253.0-01 obj-192.168.253.0-01 unidirectional
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 172.16.5.0/24, Translated: 172.16.5.0/24
    Destination - Origin: 192.168.253.0/28, Translated: 192.168.253.0/28
5 (inside) to (any) source static obj-10.1.1.0-01 obj-10.1.1.0-01 destination static obj-192.168.254.0-01 obj-192.168.254.0-01 unidirectional
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.1.1.0/24, Translated: 10.1.1.0/24
    Destination - Origin: 192.168.254.0/24, Translated: 192.168.254.0/24
6 (inside) to (any) source static DM_INLINE_NETWORK_8 DM_INLINE_NETWORK_8 destination static obj-192.168.250.0-01 obj-192.168.250.0-01 unidirectional
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.1.1.68/32, 10.1.1.7/32, Translated: 10.1.1.68/32, 10.1.1.7/32
    Destination - Origin: 192.168.250.0/27, Translated: 192.168.250.0/27
7 (inside) to (any) source static obj-172.16.5.0-01 obj-172.16.5.0-01 destination static obj-10.50.48.0-01 obj-10.50.48.0-01 unidirectional
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 172.16.5.0/24, Translated: 172.16.5.0/24
    Destination - Origin: 10.50.48.0/24, Translated: 10.50.48.0/24
8 (inside) to (any) source static obj-192.168.150.0-01 obj-192.168.150.0-01 destination static obj-10.50.48.0-01 obj-10.50.48.0-01 unidirectional
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 192.168.150.0/24, Translated: 192.168.150.0/24
    Destination - Origin: 10.50.48.0/24, Translated: 10.50.48.0/24
9 (inside) to (outside) source static obj-10.1.1.18 obj-216.223.x.20-01 service obj-tcp-source-eq-80-01 obj-tcp-source-eq-80-01
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.1.1.18/32, Translated: 216.223.x.20/32
    Service - Origin: tcp source eq www , Translated: tcp source eq www 
10 (inside) to (outside) source static obj-10.1.1.6-01 obj-216.223.x.20-01 service obj-tcp-source-eq-443-01 obj-tcp-source-eq-443-01
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.1.1.6/32, Translated: 216.223.x.20/32
    Service - Origin: tcp source eq https , Translated: tcp source eq https 
11 (inside) to (outside) source static obj-10.1.1.20-01 obj-216.223.x.20-01 service obj-tcp-source-eq-8888-01 obj-tcp-source-eq-8888-01
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.1.1.20/32, Translated: 216.223.x.20/32
    Service - Origin: tcp source eq 8888 , Translated: tcp source eq 8888 
12 (inside) to (outside) source static obj-10.1.1.4-01 obj-216.223.x.20-01 service obj-tcp-source-eq-25-01 obj-tcp-source-eq-25-01
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.1.1.4/32, Translated: 216.223.x.20/32
    Service - Origin: tcp source eq smtp , Translated: tcp source eq smtp 
13 (inside) to (outside) source static obj-10.1.1.4-01 obj-216.223.x.20-01 service obj-tcp-source-eq-110-01 obj-tcp-source-eq-110-01
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.1.1.4/32, Translated: 216.223.x.20/32
    Service - Origin: tcp source eq pop3 , Translated: tcp source eq pop3 
14 (inside) to (outside) source static obj-10.1.1.4-01 obj-216.223.x.20-01 service obj-tcp-source-eq-135-01 obj-tcp-source-eq-135-01
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.1.1.4/32, Translated: 216.223.x.20/32
    Service - Origin: tcp source eq 135 , Translated: tcp source eq 135 
15 (inside) to (outside) source static obj-10.1.1.4-01 obj-216.223.x.20-01 service obj-tcp-source-eq-143-01 obj-tcp-source-eq-143-01
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.1.1.4/32, Translated: 216.223.x.20/32
    Service - Origin: tcp source eq imap4 , Translated: tcp source eq imap4 
16 (inside) to (outside) source static obj-10.1.1.4-01 obj-216.223.x.30-01 service obj-tcp-source-eq-80-01 obj-tcp-source-eq-80-01
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.1.1.4/32, Translated: 216.223.x.30/32
    Service - Origin: tcp source eq www , Translated: tcp source eq www 
17 (inside) to (outside) source static obj-172.16.5.10-01 obj-216.223.x.20-01 service obj-tcp-source-eq-22-01 obj-tcp-source-eq-22-01
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 172.16.5.10/32, Translated: 216.223.x.20/32
    Service - Origin: tcp source eq ssh , Translated: tcp source eq ssh 
18 (inside) to (outside) source static obj-10.1.1.17-01 obj-216.223.x.20-01 service obj-tcp-source-eq-56100-01 obj-tcp-source-eq-56100-01
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.1.1.17/32, Translated: 216.223.x.20/32
    Service - Origin: tcp source eq 56100 , Translated: tcp source eq 56100 
19 (inside) to (outside) source static obj-10.1.10.10-01 obj-216.223.x.20-01 service obj-tcp-source-eq-85-01 obj-tcp-source-eq-85-01
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.1.10.10/32, Translated: 216.223.x.20/32
    Service - Origin: tcp source eq 85 , Translated: tcp source eq 85 
20 (inside) to (outside) source dynamic INSIDE-NETWORKS interface
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.1.1.0/24, ITDept/24, AgilisNetworks/24, CDM/24
    CEOHR/24, AC-AS/24, CustomerService/24, Engineering/24
    Operations/24, 192.168.1.12/32, Translated: 216.223.x.10/28 

Open in new window

0
 

Author Comment

by:ITGeneral
ID: 38337361
Sepist: So instead of using the external IP I would use the internal one basically? That makes sense I think. Now to just find a way to test it.
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38337368
Yes that is correct, replace all of the external IP's in your outside ACL with their internal counterparts.
0
 
LVL 29

Expert Comment

by:Jan Springer
ID: 38337746
The upgrade should have created the objects and referenced them appropriately.  Are you sure that the correct access list entries are not present?
0
 

Author Comment

by:ITGeneral
ID: 38337822
Well my NAT rules have all been re-created using object names that was obviously done by a wizard - those look just fine - however the rules on my ACL for the "OUTSIDE-IN" portion were still all pointing at their public IPs rather than their private ones. I've updated them all as Sepist suggested and will test it Wednesday.
0
 
LVL 29

Expert Comment

by:Jan Springer
ID: 38337863
That's odd.  The upgrade should have taken care of that, too.
0
 

Author Comment

by:ITGeneral
ID: 38350011
Well, I tried flipping it over last night - changing the rules on my ACL to point to their internal ones had absolutely NO effect. It doesn't look like there's any traffic even getting to the Access Rules as I don't see the hits increasing when I tried to browse to our companies web sites from the outside. Again outbound traffic did not seem to be affected.
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38350023
Anything showing in the logging when you try to connect?
0
 

Author Comment

by:ITGeneral
ID: 38350034
Nothing in debug.

I've attached a screenshot of the ASDM Access Rules.

I'm going to try and set this ASA up so that I can test it without having to bring down our network. We have a couple of spare public IPs that I can use and maybe I'll setup a laptop to emulate a website on the inside.
ASAAccessRules.png
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38350075
Rules look ok and I see one hit......

Could you post a sanitized config to have a look at? Perhaps we're overlooking something.
0
 

Author Comment

by:ITGeneral
ID: 38350307
Here it is.
sanitizedconfig.txt
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38350373
Though I'm still getting used to the new methology, I'm not too sure about this:

object service obj-tcp-source-eq-80-01
 service tcp source eq www

nat (inside,outside) source static obj-10.1.1.18 obj-216.x.x.3-01 service obj-tcp-source-eq-80-01 obj-tcp-source-eq-80-01


You might want to try to change:

nat (inside,outside) source static obj-10.1.1.18 obj-216.x.x.3-01 service obj-tcp-source-eq-80-01 obj-tcp-source-eq-80-01
to
nat (inside,outside) source static obj-10.1.1.18 obj-216.x.x.3-01 service www www
0
 

Author Comment

by:ITGeneral
ID: 38350406
Ok thats interesting - those NAT rules were created by the "wizard" - so I just assumed those would be correct.
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38350412
Or, perhaps even better:

Remove:
nat (inside,outside) source static obj-10.1.1.18 obj-216.x.x.3-01 service obj-tcp-source-eq-80-01 obj-tcp-source-eq-80-01

And add:
object network obj-10.1.1.18
host 10.1.1.18
nat (inside,outside) static 216.x.x.3 service tcp www www
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38350415
Well you know, never assume anything ;)
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38350428
Have you ever come across this document: http://www.cisco.com/en/US/docs/security/asa/asa83/upgrading/migrating.html#wp96308

To me this proved to be very helpfull.
0
 

Author Comment

by:ITGeneral
ID: 38352172
Well, I tried the above - though admittedly in a test environment and I'm getting a TCP access denied by ACL - but my ACL hasn't changed - other than to point it to my test webserver.

I have however had to change my public IP and of course I added the test web server in the same network as our actual web server.
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38353285
Ok, could you post a config as it is now?
0
 

Author Comment

by:ITGeneral
ID: 38365166
Sorry for the delay - here it is.
Sanitized2.txt
0
 

Author Comment

by:ITGeneral
ID: 38376615
Anyone have any ideas on what the issue could be?
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38376643
Well, according to the sanitized config, there is no route for 10.1.1.X on your ASA

interface Ethernet0/2
 description Inside LAN Interface - VLAN 994
 nameif inside
 security-level 100
 ip address 10.1.10.67 255.255.255.0

route inside 10.1.10.0 255.255.255.0 10.1.1.75 1
route inside 10.1.20.0 255.255.255.0 10.1.1.75 1
route inside 10.1.30.0 255.255.255.0 10.1.1.75 1
route inside 10.1.40.0 255.255.255.0 10.1.1.75 1
route inside 10.1.50.0 255.255.255.0 10.1.1.75 1
route inside 10.1.60.0 255.255.255.0 10.1.1.75 1
route inside 10.1.70.0 255.255.255.0 10.1.1.75 1
route inside 10.1.80.0 255.255.255.0 10.1.1.75 1
route inside 172.16.2.0 255.255.255.0 10.1.1.75 1
route inside 172.16.3.0 255.255.255.0 10.1.1.75 1
route inside 172.16.5.0 255.255.255.0 10.1.1.75 1
route inside 172.25.1.0 255.255.255.0 10.1.1.75 1
route inside 192.168.1.0 255.255.255.0 10.1.1.75 1
route inside 192.168.115.0 255.255.255.0 10.1.1.75 1


That would be a problem
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38376673
Ooops, sorry for the delay.

Looking at:

access-list OUTSIDE-IN extended permit tcp any host 10.1.1.4 object-group EXCHANGE
access-list OUTSIDE-IN extended permit tcp any host 10.1.1.161 eq www
access-list OUTSIDE-IN extended permit tcp any host 10.1.1.4 eq www
access-list OUTSIDE-IN remark External access for MIRS
access-list OUTSIDE-IN extended permit tcp any host 10.1.1.20 eq 8888
access-list OUTSIDE-IN extended permit tcp any host 10.1.1.6 eq https
access-list OUTSIDE-IN remark Sense Connections for management of /Smart  Network
access-list OUTSIDE-IN remark Data Systems AS/2 access to AS/2 server @ 10.1.1.17
access-list OUTSIDE-IN extended permit tcp host 72.a.b.c host 10.1.1.17 eq 56100
access-list OUTSIDE-IN remark Required for AS/2 connectivity from SpecialHost
access-list OUTSIDE-IN extended permit tcp object-group SpecialHost host 10.1.1.17 eq 56100
access-list OUTSIDE-IN extended permit tcp object-group DM_INLINE_NETWORK_6 object-group DM_INLINE_NETWORK_3 object-group SenseServices
access-list OUTSIDE-IN remark SSH port for Sense
access-list OUTSIDE-IN extended permit tcp host 208.a.b.c host 216.x.x.3 eq ssh inactive
access-list OUTSIDE-IN extended permit ip host 216.x.a.b host 216.x.x.1 inactive
access-list OUTSIDE-IN extended deny ip any any
access-list OUTSIDE-IN remark Sense Connections for management of /SmartNetwork
access-list OUTSIDE-IN remark Data Systems AS/2 access to AS/2 server @ 10.1.1.17
access-list OUTSIDE-IN extended permit tcp host 72.x.y.z host 216.x.x.3 eq 4080 inactive
access-list OUTSIDE-IN remark Cleo test
access-list OUTSIDE-IN extended permit tcp host 208.x.y.z host 216.x.x.3 eq 56100 inactive
access-list OUTSIDE-IN remark Cleo test
access-list OUTSIDE-IN extended permit tcp host 208.x.y.z host 216.x.x.3 eq 4080 inactive
access-list OUTSIDE-IN extended permit object-group DM_INLINE_SERVICE_3 object-group DM_INLINE_NETWORK_1 host 216.x.x.3 inactive
access-list OUTSIDE-IN remark Sense Connections for management of  /SmartNetwork
access-list OUTSIDE-IN remark Data Systems AS/2 access to AS/2 server @ 10.1.1.17
access-list OUTSIDE-IN remark Required for AS/2 connectivity from SpecialHost
access-list OUTSIDE-IN remark SSH port for Sense
access-list OUTSIDE-IN remark Sense Connections for management of  /SmartNetwork
access-list OUTSIDE-IN remark Data Systems AS/2 access to AS/2 server @ 10.1.1.17
access-list OUTSIDE-IN remark Cleo test
access-list OUTSIDE-IN remark Cleo test


I'm missing a line to allow www to the 10.1.1.18.
Also have a look at the 'deny ip any any' in the middle. Everything after that line is ignored.
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38376701
@Sepist: Good catch, overlooked that.

Or should 10.1.1.18 be 10.1.10.18?
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38376783
It looks like 10.1.1.x is their server subnet, the others have their own purpose. Just assuming here based on the ACL remarks.
0
 

Author Comment

by:ITGeneral
ID: 38376801
Sepist:

Good point however my currently active ASA doesn't have that statement in it either:

route outside 0.0.0.0 0.0.0.0 216.223.90.65 1
route inside 10.1.10.0 255.255.255.0 10.1.1.75 1
route inside 10.1.20.0 255.255.255.0 10.1.1.75 1
route inside 10.1.30.0 255.255.255.0 10.1.1.75 1
route inside 10.1.40.0 255.255.255.0 10.1.1.75 1
route inside 10.1.50.0 255.255.255.0 10.1.1.75 1
route inside 10.1.60.0 255.255.255.0 10.1.1.75 1
route inside 10.1.70.0 255.255.255.0 10.1.1.75 1
route inside 10.1.80.0 255.255.255.0 10.1.1.75 1
route inside 172.16.2.0 255.255.255.0 10.1.1.75 1
route inside 172.16.3.0 255.255.255.0 10.1.1.75 1
route inside 172.16.5.0 255.255.255.0 10.1.1.75 1
route inside 172.25.1.0 255.255.255.0 10.1.1.75 1
route inside 192.168.1.0 255.255.255.0 10.1.1.75 1
route inside 192.168.115.0 255.255.255.0 10.1.1.75 1

erniebeek: It's definately 10.1.1.18 and wouldn't

access-list OUTSIDE-IN extended permit tcp any host 10.1.1.161 eq www

allow the HTTP traffic through as it comes before the

access-list OUTSIDE-IN extended deny ip any any

The order of the rules is the same on my current running ASA.
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38376820
I'm not really sure how that subnet is working at all then, can you post "show route" from the ASA?
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38376839
Ok, so we're talking  10.1.1.161 and not  10.1.1.18.

But this is an interesting thing. You are able to reach the 10.1.1.x network from the ASA?
0
 
LVL 35

Expert Comment

by:Ernie Beek
ID: 38376842
@Sepist: you're thinking the same?
0
 

Author Comment

by:ITGeneral
ID: 38377145
From my currently active ASA running on the old code:

C    10.1.1.0 255.255.255.0 is directly connected, inside

Open in new window


From my test ASA on new code:

C    10.1.10.0 255.255.255.0 is directly connected, inside

Open in new window


However I'm using 10.1.10.0 network just so that I can have the test ASA up and running at the same time as my production one. But when I make the test one active I change the IP on that outside interface to match the one on my active ASA.

So there's maybe a question - when I change my inside interface's IP address to 10.1.1.x would it update/change that route?
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38377173
Well then 10.1.1.0 would be the connected interface so there would be no need for a static route since it's directly attached to the ASA. All of these configuration changes you've made are on the test ASA which is on the 10.1.10.x inside subnet?
0
 

Author Comment

by:ITGeneral
ID: 38377182
That's correct. Then just before I make it live I change the outside interface to 10.1.1.x IP.
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38377189
Do you make it the same inside IP as the other ASA and unplug the other one from the network?
0
 

Author Comment

by:ITGeneral
ID: 38377197
Yup, I also change the outside address to match as well.
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38377316
Okay. My guess is that these:

nat (inside,outside) source static obj-10.1.1.6-01 obj-216.x.x.3-01 service obj-tcp-source-eq-443-01 obj-tcp-source-eq-443-01
nat (inside,outside) source static obj-10.1.1.20-01 obj-216.x.x.3-01 service obj-tcp-source-eq-8888-01 obj-tcp-source-eq-8888-01
nat (inside,outside) source static obj-10.1.1.4-01 obj-216.x.x.3-01 service obj-tcp-source-eq-25-01 obj-tcp-source-eq-25-01
nat (inside,outside) source static obj-10.1.1.4-01 obj-216.x.x.3-01 service obj-tcp-source-eq-110-01 obj-tcp-source-eq-110-01
nat (inside,outside) source static obj-10.1.1.4-01 obj-216.x.x.3-01 service obj-tcp-source-eq-135-01 obj-tcp-source-eq-135-01
nat (inside,outside) source static obj-10.1.1.4-01 obj-216.x.x.3-01 service obj-tcp-source-eq-143-01 obj-tcp-source-eq-143-01
nat (inside,outside) source static obj-10.1.1.4-01 obj-216.x.x.2-01 service obj-tcp-source-eq-80-01 obj-tcp-source-eq-80-01
nat (inside,outside) source static obj-172.16.5.10-01 obj-216.x.x.3-01 service obj-tcp-source-eq-22-01 obj-tcp-source-eq-22-01
nat (inside,outside) source static obj-10.1.1.17-01 obj-216.x.x.3-01 service obj-tcp-source-eq-56100-01 obj-tcp-source-eq-56100-01
nat (inside,outside) source static obj-10.1.10.10-01 obj-216.x.x.3-01 service obj-tcp-source-eq-85-01 obj-tcp-source-eq-85-01

are somehow breaking your connection.

Using a fresh install of 8.4, I made only this NAT in my config:

object network obj-172.16.0.3
host 172.16.0.3
 nat (inside,outside) static 64.x.x.x

and permitted access to port 23 via the ACL "permit tcp any host 172.16.0.3 eq 23" and it worked right off the bat.


So for you I'd say:

Remove the lines I reference above
Add the nat I referenced above but tailored for your inside/outside hosts
change the outside ACL to a new one for testing purposes, maybe just a permit ip any any and test it out.
If it doesn't work blow it up start from scratch.
0
 

Author Comment

by:ITGeneral
ID: 38378026
Ok, so I've pretty much cleared out my OUTSIDE-IN rules as well as removed ALL NAT policies except for the following:

[show nat]


Auto NAT Policies (Section 2)
1 (inside) to (outside) source static objTestWebServer interface service tcp www www

Open in new window


show access-list (pertinent part)
access-list OUTSIDE-IN line 1 extended permit ip any any

Open in new window


And I STILL can't get to my internal web server - I get this coming up in the debug:

Sep 07 2012 16:09:37: %ASA-4-106023: Deny tcp src outside:66.206.238.85/56677 dst inside:10.1.1.161/80 by access-group "OUTSIDE-IN" [0x0, 0x0]

At least it seems to be translating my public IP that I'm using to the proper internal IP and port but why can't I get there?

Below is what my packet tracer shows. Look like blocked by implicit rule but how can that be if I'm basically opening up everything on the OUTSIDE interface?

ASA Packet Tracer
0
 

Expert Comment

by:INV_support
ID: 38378103
What's the readout of `packet-trace input outside tcp 66.206.238.85 56677 10.1.1.161 80 detailed` ?
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38378108
Look at the interfaces i your packet tracer, route lookup says source is outside, destination is outside - implicit deny is due to intra-interface routing (that shouldn't even be routing that way). What does "show route" look like when that packet tracer fails?
0
 

Author Comment

by:ITGeneral
ID: 38383036
INV_support:

results:

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xacc229f8, priority=111, domain=permit, deny=true
        hits=6, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
        input_ifc=outside, output_ifc=outside

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38383062
Yep it's trying to send traffic destined to 10.1.1.x to the outside interface, there must not be a route installed for 10.1.1.x when you're testing.
0
 

Author Comment

by:ITGeneral
ID: 38383085
Right of course, ok added the route.

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   10.1.1.0        255.255.255.0   inside

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group OUTSIDE-IN in interface outside
access-list OUTSIDE-IN extended permit ip any any
access-list OUTSIDE-IN remark Sensus Connections for management of RNI/Smart Meter Network
access-list OUTSIDE-IN remark Savaga Data Systems AS/2 access to AS/2 server @ 10.1.1.17
access-list OUTSIDE-IN remark Required for AS/2 connectivity from MDMR
access-list OUTSIDE-IN remark SSH port for Sensus
access-list OUTSIDE-IN remark Sensus Connections for management of RNI/Smart Meter Network
access-list OUTSIDE-IN remark Savaga Data Systems AS/2 access to AS/2 server @ 10.1.1.17
access-list OUTSIDE-IN remark Cleo test
access-list OUTSIDE-IN remark Cleo test
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xace440e0, priority=13, domain=permit, deny=false
        hits=18, user_data=0xa90e0680, cs_id=0x0, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
        input_ifc=outside, output_ifc=any

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xaccd38b0, priority=0, domain=inspect-ip-options, deny=true
        hits=73, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
        input_ifc=outside, output_ifc=any

Phase: 5
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xad7f5238, priority=13, domain=ipsec-tunnel-flow, deny=true
        hits=63, user_data=0x0, cs_id=0x0, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
        input_ifc=outside, output_ifc=any

Phase: 6
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
object network objTestWebServer
 nat (inside,outside) static interface service tcp www www
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0xae333060, priority=6, domain=nat-reverse, deny=false
        hits=55, user_data=0xae4cebf8, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=10.1.1.161, mask=255.255.255.255, port=80, dscp=0x0
        input_ifc=outside, output_ifc=inside

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38383109
Better. Remove:

 (inside) to (outside) source static objTestWebServer interface service tcp www www

and add:

 object network obj-10.1.1.161
host 10.1.1.161
 nat (inside,outside) static EX.TE.RN.AL ip

and it should work.
0
 

Author Comment

by:ITGeneral
ID: 38383318
Argh, this is killing me. Still getting blocked by the ACL.


Phase: 6
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
object network obj-10.1.1.161
 nat (inside,outside) static 66.x.x.x
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0xae333060, priority=6, domain=nat-reverse, deny=false
        hits=1, user_data=0xa7ab0ff8, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=10.1.1.161, mask=255.255.255.255, port=0, dscp=0x0
        input_ifc=outside, output_ifc=inside

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule


Corresponding log shows TCP access denied by ACL from 66.x.x.x to outside (public interface IP here)
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38383388
Can you post the current config? There is definitely something else in there making reverse path verify deny the packet.
0
 

Author Comment

by:ITGeneral
ID: 38383568
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38383586
Try removing "ip verify reverse-path interface outside" and see if you get the same error.
0
 

Author Comment

by:ITGeneral
ID: 38383838
Same deal.


Phase: 6
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
object network obj-10.1.1.161
 nat (inside,outside) static 66.x.x.x
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0xae333060, priority=6, domain=nat-reverse, deny=false
        hits=1, user_data=0xa7ab0ff8, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=10.1.1.161, mask=255.255.255.255, port=0, dscp=0x0
        input_ifc=outside, output_ifc=inside

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38383870
Hmm, the only thing I could see as a problem at this point is if you're packet-tracing the wrong IP. The source should be whatever fake external IP you're sourcing from, and the destination should be the 66.x.x.x IP, not the "real" IP of the server.
0
 

Author Comment

by:ITGeneral
ID: 38383927
Well, here's what I'm using

packet-trace input outside tcp 66.206.238.85 56677 10.1.1.161 80 detailed

Open in new window


66.206.238.85 is the address I'm using from the outside to test from
10.1.1.161 is the actual IP address of the PC that I've put a test website on

My outside interface is 216.a.b.c - are you saying I should be using that public IP instead of the interal private one? (.161)
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38383945
When running packet tracer yes, since external IP's would be trying to reach the external IP, not your internal, which is what you want to simulate in packet-tracer

packet-trace input outside tcp 66.206.238.85 56677 216.x.x.x 80 detailed
0
 

Author Comment

by:ITGeneral
ID: 38383971
Right, that makes sense. Fails much quicker now.

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   216.a.b.c 255.255.255.255 identity

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xacc222c8, priority=0, domain=permit, deny=true
        hits=142, user_data=0x9, cs_id=0x0, use_real_addr, flags=0x1000, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
        input_ifc=outside, output_ifc=any

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38384005
Lol.

Well looking at your sanitized config, you have this for the 1 to 1 nat:

object network obj-10.1.1.161
 nat (inside,outside) static 66.x.y.z

yet your outside nat should be in the 216 network?
0
 

Author Comment

by:ITGeneral
ID: 38384031
Whoops ya forgot to change that :) it now reads:

object network obj-10.1.1.161
 host 10.1.1.161
!
object network obj-10.1.1.161
 nat (inside,outside) static 216.a.b.c

Open in new window




Still no love:

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   216.a.b.c   255.255.255.255 identity

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xacc222c8, priority=0, domain=permit, deny=true
        hits=177, user_data=0x9, cs_id=0x0, use_real_addr, flags=0x1000, protoco                                                                                                                               l=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
        input_ifc=outside, output_ifc=any

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38384044
Hmm, weird. That 216.x.x.x IP address isn't the outside interface's IP address also is it?
0
 

Author Comment

by:ITGeneral
ID: 38384046
It most certainly is!
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38384058
Oh! Change

object network obj-10.1.1.161
 nat (inside,outside) static 216.a.b.c

to

object network obj-10.1.1.161
  nat (inside,outside) static interface service tcp 80 80
0
 

Author Comment

by:ITGeneral
ID: 38384112
Still nothin' :

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   216..x.x.x   255.255.255.240 outside

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xacc229f8, priority=111, domain=permit, deny=true
        hits=9, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
        input_ifc=outside, output_ifc=outside

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38384174
Weird it's trying to hairpin the traffic out the outside interface. One last trick up my sleeve would be to change

object network obj-10.1.1.161
  nat (inside,outside) static interface service tcp 80 80

to

object network obj-10.1.1.161
  nat (inside,outside) static interface route-lookup service tcp 80 80

Which will force the ASA to use the routing table.
0
 

Author Comment

by:ITGeneral
ID: 38384212
I'm getting an error at "route-lookup" - does it go somewhere else in that line perhaps?
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38384246
Ah it might not be available i 8.3, I only have 8.4 to test with. I'm not sure where to go with your current situation unfortunately. I would just blow away the config and start from scratch.
0
 

Author Comment

by:ITGeneral
ID: 38384550
Ya I'm going to blow away the config in the morning and try that from a clean config and see where I get.
0
 

Author Comment

by:ITGeneral
ID: 38390980
Ok, so I've blown away the entire config and started from scratch. My goal is to see what it takes to get traffic to port 80.

So with this I can see the traffic hit the outside interface and start the connection but it times out.

Outside Interface IP: 216.a.b.c (and yes I'm using that as the address of the website as well)
Inside WebServer IP: 10.1.10.101

At this point 10.1.10.101 is plugged directly into the INSIDE port - so not going through a switch or anything.

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xacc76280, priority=1, domain=permit, deny=false
        hits=18, user_data=0x0, cs_id=0x0, l3_type=0x8
        src mac=0000.0000.0000, mask=0000.0000.0000
        dst mac=0000.0000.0000, mask=0100.0000.0000
        input_ifc=OUTSIDE, output_ifc=any

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
object network obj-10.1.10.101
 nat (INSIDE,OUTSIDE) static interface service tcp www www
Additional Information:
NAT divert to egress interface INSIDE
Untranslate 216.a.b.c/80 to 10.1.10.101/80

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group OUTSIDE_access_in in interface OUTSIDE
access-list OUTSIDE_access_in extended permit tcp any 10.1.10.0 255.255.255.0 eq www
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xad8ab2b0, priority=13, domain=permit, deny=false
        hits=0, user_data=0xa90e0880, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=10.1.10.0, mask=255.255.255.0, port=80, dscp=0x0
        input_ifc=OUTSIDE, output_ifc=any

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xaccc9190, priority=0, domain=inspect-ip-options, deny=true
        hits=4, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
        input_ifc=OUTSIDE, output_ifc=any

Phase: 5
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
object network obj-10.1.10.101
 nat (INSIDE,OUTSIDE) static interface service tcp www www
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0xa7f6be98, priority=6, domain=nat-reverse, deny=false
        hits=5, user_data=0xa81b3a58, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=10.1.10.101, mask=255.255.255.255, port=80, dscp=0x0
        input_ifc=OUTSIDE, output_ifc=INSIDE

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
 in  id=0xaccf8ff0, priority=0, domain=inspect-ip-options, deny=true
        hits=364, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
        input_ifc=INSIDE, output_ifc=any

Phase: 7
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 104, packet dispatched to next module
Module information for forward flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_translate
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Module information for reverse flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_translate
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

Result:
input-interface: OUTSIDE
input-status: up
input-line-status: up
output-interface: INSIDE
output-status: up
output-line-status: up
Action: allow

Open in new window

running-config.txt
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38391061
Can you ping 10.1.10.101 from the ASA? Can you telnet on 80 to 10.1.10.101 from command prompt on the server itself?
0
 

Author Comment

by:ITGeneral
ID: 38391168
I can ping it from the ASA but I cannot Telnet to 10.1.10.101 from itself.

I can however browse to the website from my PC which is on the same VLAN currently.
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38391182
Something doesn't sound right  behind the ASA if you can't telnet on 80 from a server to itself but can browse on another machine to http://10.1.10.101
0
 

Author Comment

by:ITGeneral
ID: 38391257
Well, I'm not sure that should work regardless. Internally if I try to telnet to our production web server on 80 I don't get anything there either.
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38391331
Ah, I took it from my own experience that on my machine I can telnet to my own IP on port 21 and get an FTP prompt so I figured IIS/Apache performed the same.

The only other thing I can think of is asynchronous routing, is the webservers default route a different ASA than the one youre testing?
0
 

Author Comment

by:ITGeneral
ID: 38391581
Ya I know what you mean with regards to FTP and even SMTP but I'm pretty sure you can't Telnet to a web server.

Hmmm, thats a good point. I was actually mistaken I thought the test webserver was plugged directly into the ASA but its not - its going through our swtich so ya its probably trying to get out that other ASA.

Can I add a persistent route on my webserver that forces it out my test ASA at 10.1.10.67? (INSIDE Interface IP)
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38391592
Of course, "route add source.IP mask 255.255.255.255 10.1.10.67 /p"
0
 

Author Comment

by:ITGeneral
ID: 38391877
So I added that persistent route in

route add 10.1.10.101 MASK 255.255.255.255 10.1.10.67 /p

Open in new window


I still get the same thing though - no issues with ACLs or NATting but it comes back with SYN TIMEOUT after 30 seconds.
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38391903
the route you're adding should be the external IP you're coming from, not the server IP address. so if my computers IP was 8.8.8.8 on the internet the route would be

route add 8.8.8.8 mask 255.255.255.255 10.1.10.67 /p

Open in new window

0
 

Author Comment

by:ITGeneral
ID: 38391920
Ok, so different error now - "Failed to locate egress interface for TCP from INSIDE: 10.1.10.101/80 to 66.a.b.c/62823"
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38391933
You're missing the outside default route :)

all you have is:

route INSIDE 10.1.10.0 255.255.255.255 10.1.1.75 1

Open in new window

0
 

Author Comment

by:ITGeneral
ID: 38392026
Ahhh :) There we go - gee that wasn't too hard. :) Wow ok so now I'm just going to go back and see if I can't figure out whats different between this test config and the one you were trying to help me out with the last several days.

Of course just looking back at this quickly - that route on my test server would have been nice to put on there say yesterday morning... :)
0
 

Author Comment

by:ITGeneral
ID: 38437521
Ok, so I'm ready to give this another try tonight. I'm doing some more testing today however and I'm finding I can't get to my test web server. Its IP has changed - details of all pertinent IPs are below - I get a SYN Timeout - using Wireshark I can actually see the traffic getting to my web server - it just apparently doesn't want to go back?

ASA: Inside Test Address - 10.1.10.67 (same as before)

WebServer IP: 10.1.1.161 (different - was in the 10.1.10.0 range before)
Gateway: 10.1.1.75

Outside IP: 66.206.x.x (same IP as before)

Packet-Tracer shows that all traffic is being allowed to and from the webserver so I'm thinking its something on my webserver. I tried adding a static route for my 66.206.x.x to point it directly to the Inside interface on the ASA (10.1.10.67) but that doesn't help any - nor does it change the SYN Timeout issue.

Firewall is turned off on the web server and it is accessible from inside my own network.
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38437830
What is 10.1.1.75?
0
 

Author Comment

by:ITGeneral
ID: 38437839
Switch stack
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38437851
So it is a layer 3 stack? Does it have a route to send your source IP address to the ASA's inside interface's IP?
0
 

Author Comment

by:ITGeneral
ID: 38437871
Thats correct, layer 3 stack. I am able to ping from the web server (10.1.1.160) to the inside ASA interface (10.1.10.67).
0
 
LVL 2

Expert Comment

by:Sepist
ID: 38437881
But from what IP are you testing from?

Your switch stack needs to know to route your source IP that you are testing from back out the ASA instead of it's existing default gateway.
0
 

Author Comment

by:ITGeneral
ID: 38437929
Ahh right ok. So after adding the route for my outside test IP to my switch stack and forcing it to use 10.1.10.67 it works. I would have thought that because it came in through 10.67 that it would have just gone back out that path - but I guess the stack was "intercepting" it and sending it out my production ASA. That's great thanks for the help. Now to undo all this and get ready for the cutover tonight.
0
 

Author Comment

by:ITGeneral
ID: 38441130
Well, that could have gone way better. I coudln't get any traffic either in our out after blowing away all the NAT rules and just attempting to use the 1 for port 80 traffic - in fact I saw no external traffic at all. So at that point I loaded the config from post ASA Upgrade wizard where I started initially - at least with that loaded I was able to browse the Internet and send email. Basically everything outbound worked. In fact it looked like even my site-to-site VPN was back up and running. However, once again no Inbound traffic. I mean I was connected with a laptop to public wireless and trying to hit one of our websites and never saw the IP hit the ASA. So I was thinking about this and started wondering - would I be able to have OUTBOUND traffic if the upstream router didn't have the new MAC address of the upgraded ASA? Because basically what the upstream router is seeing (our ISP) is the same IP address but coming from a new MAC. I checked with our ISP and the ARP table only updates every 4 hours. They didn't think that that could be the problem though as they seemed to think I'd either have traffic in both direction or NO traffic at all if it were an arp issue. BUT I am getting outbound web and mail traffic.
0
 
LVL 2

Accepted Solution

by:
Sepist earned 2000 total points
ID: 38442931
If you had outbound it's not an arp issue as the traffic would need to return through the ASA for tcp 3 way handshake. I can't tell you what your issue is during migration but it sounds like you need to have someone who has experience with 8.3+ code come in and take care of that migration as there are too many variables at play
0
 

Author Closing Comment

by:ITGeneral
ID: 38450721
Thanks so much for hanging in there with me Sepist. In the end the issue WAS with the upstream router not updating its ARP. I had our ISP flush the ARP table last night after doing another cutover and running the updated code that the ASA automatically updates when it goes from 8.3 to 8.4 and it all worked save for a couple of NAT rules that I had to re-create due to the whole Global NAT thing - other then that though it went off without a hitch! No idea why we were able to get out but not have traffic come in but as soon as they cleared the ARP table in the upstream router everything worked perfectly!

Thanks again for all the help - especially when I was setting things up to test from a separate network. I know you spent a considerable amount of time with me - it is appreciated.
0

Featured Post

Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

When speed and performance are vital to revenue, companies must have complete confidence in their cloud environment.
In this article, the configuration steps in Zabbix to monitor devices via SNMP will be discussed with some real examples on Cisco Router/Switch, Catalyst Switch, NAS Synology device.
Both in life and business – not all partnerships are created equal. As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …
When cloud platforms entered the scene, users and companies jumped on board to take advantage of the many benefits, like the ability to work and connect with company information from various locations. What many didn't foresee was the increased risk…
Suggested Courses
Course of the Month13 days, 23 hours left to enroll

581 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question