Static Natting Outside

[estelamathew]

Hello,

I have two  strange problem, please help me for success.

static (DMZ,outside) 82.X.X.X 10.1.1.1 netmask 255.255.255.255

access-list outside extended permit tcp any object-group WEB-SERVERS eq www
access-list outside extended permit tcp any object-group WEB-SERVERS eq https

access-list outside extended permit icmp any any

object-group network WEB-SERVERS
network-object 82.X.X.X 255.255.255.255

when i try to ping from internet i m not able to ping niether web-server is opening on port 80 or 443. There are no log seen for outside interface in logging bufffer.

2) Another problem i have is internal users are not able to go on internet, i have a proxy server which is static natted on ASA firewall with public IP  but the problem is ASA is receiving Natted IP becz behind ASA,,we have a Juniper which is doing Natting for proxy server and that natted IP is statically natted on ASA firewall,(double natting),

I have allowed natted IP of proxy server  in inside access-list of ASA firewall for HTTP and HTTPS access and also i have done 1-1 mapping with public IP,,

The Natted IP from juniper for proxy server is from the subnet between the inside interface and Juniper outside interface,

What can be the possibilities issues,pls help for troubleshooting.

[Sudeep Khuraijam]

What code level are you running?  Depending on that and if it is newer code like 8.3 + you have to use the inside object in your accesslist.

You will have to elaborate on your second question.  Is that the same static map as you have cited ?

[Jennifer Halim]

You mention that you have double NATing configured, once at Juniper and another one at ASA, so to confirm 10.1.1.1 is not the real address but the address after NATing at Juniper.

Secondly, I assume that you have the correct routing etc in place for 10.1.1.1 and since it's a NATed address, I assume that Juniper has proxy arp enabled for that NATed address?

3) On the ASA, do you have "inspect icmp" configured?

4) What is this address 82.X.X.X in relation to the ASA outside subnet? are they in the same subnet? and again, ASA is proxy arping for this address 82.X.X.X?

5) Are you seeing any hitcount on the outside access-list when you are trying to access 82.X.X.X on port 80 or 443? This will give us a pointer on where exactly it's broken, and we need to go hop by hop to check where it's breaking. If you are not seeing the hitcount, it means it's not even coming into the ASA yet, and you have to go further up (ie: router that connects to the ASA outside interface).

[estelamathew]

Hello Sudeep,

Versiion Code is 8.2(1)

Jennifer,

1. yes u have understood the question properly, for ex: 192.168.10.2 real ip of proxy server ------> Natted in Juniper to (10.1.1.5)-------> ASA recieve this Natted IP from juniper (10.1.1.5)------> ASA does static Nat for 10.1.1.5 to 82.82.82.82 static (inside,outside) 82.82.82.82 10.1.1.5 netmask 255.255.255.255
2. The subnet between the juniper outside interface and ASA inside interface is 10.1.1.0/24 so i dont think so need a static route for the proxy server real IP add because ASA will do arp for natted Ip 10.1.1.5 whcih is directly connected subnet of ASA inside interface.
3. No i dont have icmp inspect enabled
4. yes it is relation to outside interface ,yes they are in same subnet,it should do arp because DMZ is connected to ASA and webserver real ip is natted from one of the ip of the outside interface subnet,DMZ interface is in 1 vlan

static (DMZ,outside) 83.83.83.83 10.20.1.2 netmask 255.255.255.255

interface GigabitEthernet1/1
media-type sfp
nameif DMZ
security-level 75
ip address 10.20.1.252 255.255.255.0 standby 10.20.1.253

5. There were no deny packets seen from outside to inside in sh logging also other

6. Apart from proxy server  there were 4 other servers were natted by juniper going to internet for DNS request and also done natting on ASA, reply are seen from ISP DNS to these host in  sh local-host output but there were no output for proxy server natted IP address

[Sudeep Khuraijam]

Run a packet tracer with the flow you need.

Run a capture on the inside and outside interfaces with acls of expected source destinations, then generate traffic.

Step back and look elsewhere.  This last part is crucial sometimes and the problem maybe elsewhere.