ASA NAT issue

[TGF_Cisco]

    hi

I have the following setup with ASA 5520 and Netscreen sitting on our DMZ connecting to a provider over site to site VPN.

ASA 5520 uses two interface, both connecting to netscreen , each connecting to trusted and untrusted interface.

The untrusted interface on the netscreen is natted on our ASA to a public IP address.

In terms of the incoming traffic, it hits the public DMZ on ASA and we have control on what the subnets have access through ACL's

our VPN provider needs access into our server sitting on our LAN for which I have setup a NAT rule

On LAN interface

static 1.1.1.1 PUBLIC-DMZ 10.10.10.10            note: 10.10.10.10 is a public IP address

and a reverse NAT  on PUBLIC-DMZ

static 10.10.10.10  LAN 1.1.1.1

and I have allowed access on a particular port for the provider subnet to access 1.1.1.1

Provider confirms that they are not able to access the IP address on that particular port 389..  nor able to ping even though ICMP access is allowed..

[Jouni Forss]

Hi,

Your best bet is to use "packet-tracer" to show what the ASA does to the incoming connection.

packet-tracer input outside tcp 12345

or

packet-tracer input outside icmp 8 0

Then post the output here.

- Jouni

[TGF_Cisco]

So the source IP belongs to the provider range and the destination is the NATted IP address on the DMZ

[Jouni Forss]

Hi,

Please provide the CLI output not the ASDM.

Also, shoulndt the source port be some external interface leading to internet or is "PUBLIC-DMZ" that interface?

- Jouni

[TGF_Cisco]

gvadc-fw/tgf# packet-tracer input publIC-DMZ tcp "Source range from provider" 12345 10.10.10.10

Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (LAN,PUBLIC-DMZ) ActiveDirectory_NAT ActiveDirectory2 netmask 255.255.255                                                                                                                                                             .255
  match ip LAN host ActiveDirectory2 PUBLIC-DMZ any
    static translation to ActiveDirectory_NAT
    translate_hits = 0, untranslate_hits = 7
Additional Information:
NAT divert to egress interface LAN
Untranslate ActiveDirectory_NAT/0 to ActiveDirectory2/0 using netmask 255.255.25                                                                                                                                                             5.255

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group ACL_PUBLIC-DMZ in interface PUBLIC-DMZ
access-list ACL_PUBLIC-DMZ extended permit object-group DM_INLINE_SERVICE_9 obje                                                                                                                                                             ct-group DM_INLINE_NETWORK_73 host ActiveDirectory_NAT
object-group service DM_INLINE_SERVICE_9
service-object icmp
service-object tcp eq ldap
object-group network DM_INLINE_NETWORK_73
network-object ORACLE_NEW_SUBNET1 255.255.252.0
network-object ORACLE_NEW_SUBNET3 255.255.252.0
network-object ORACLE_NEW_SUBNET2 255.255.248.0
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
static (LAN,PUBLIC-DMZ) ActiveDirectory_NAT ActiveDirectory2 netmask 255.255.255                                                                                                                                                             .255
  match ip LAN host ActiveDirectory2 PUBLIC-DMZ any
    static translation to ActiveDirectory_NAT
    translate_hits = 0, untranslate_hits = 7
Additional Information:

Phase: 7
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (LAN,PUBLIC-DMZ) ActiveDirectory_NAT ActiveDirectory2 netmask 255.255.255                                                                                                                                                             .255
  match ip LAN host ActiveDirectory2 PUBLIC-DMZ any
    static translation to ActiveDirectory_NAT
    translate_hits = 0, untranslate_hits = 7
Additional Information:

Phase: 8
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 1612671295, packet dispatched to next module

Phase: 10
Type: ROUTE-LOOKUP
Subtype: output and adjacency
Result: ALLOW
Config:
Additional Information:
found next-hop 172.19.200.1 using egress ifc LAN
adjacency Active
next-hop mac address 0000.0c07.acc8 hits 23496521

Result:
input-interface: PUBLIC-DMZ
input-status: up
input-line-status: up
output-interface: LAN
output-status: up
output-line-status: up
Action: allow

gvadc-fw/tgf#

[Jouni Forss]

Hi,

If I understand the picture correctly the PUBLIC-DMZ is not the interface on the ASA that is connected to the Internet directly so I am wondering if you have the NAT configured for the correct WAN interface?

Or is the situation such that the connection attempt is first coming through the L2L VPN connection between the NetScreen VPN devices and then reaching the PUBLIC-DMZ interface of the ASA?

If that is the case I would confirm that the local NetScreen VPN device has a route for the Public NAT IP address that is configured on the ASA. I would also confirm that this Public NAT IP address is part of the encryption domain in the L2L VPN connection.

- Jouni

[TGF_Cisco]

You are right , PUBLIC - DMZ is the interface where the traffic hits the ASA.

For the moment, I have only one NAT rule

gvadc-fw/tgf# show nat LAN  1.1.1.1 255.255.255.255

match ip LAN host ActiveDirectory2 PUBLIC-DMZ any

    static translation to ActiveDirectory_NAT

    translate_hits = 0, untranslate_hits = 8

what else can I check?

Does it require a reverse NAT?

[Jouni Forss]

Hi,

I guess you have configured Static NAT for this so you dont need anything else.

The "packet-tracer" test also seems to go through so it seems there is no configuration problems on the ASA.

What I am wondering is if the traffic from behind the L2L VPN is coming all the way to the ASA? Have you confirmed that the hitcounter of the ACL is increasing when the remote user tries to connect? Do notice that the hitcounter gets increased when you use "packet-tracer" so some of the current hitcounts (or all of them) might be generated by the test on the firewall itself.

If we presume that your L2L VPN configuration includes the NAT IP address in the configurations and is otherwise properly configuration like the mentioned routing for the NAT IP address towards ASA then it would seem to me that the problem is behind the ASA, perhaps even the server itself. Perhaps network configurations or some software firewall.

- Jouni

[TGF_Cisco]

We donot have  access to the Netscreen as it is managed by the vendor, so waiting for their response on routing..

But I do see very few hits probably coming from the tests done on the firewall itself..

I have asked the provider to check routing and i hope they will come back to us..

but Just to let you know the reason for asking regarding reverse NAt. We have another IP address that is NAtTEd for the provider to reach on port 25.

The way it has been setup is one public IP for internet access, one for DMZ for provider access and there are two NAT rules  one on LAN itnerface out to Public IP and a reverse NAT on Public DMZ . I am not sure why that was required and I cannot remove it .

And another question about packet capture, what would be the syntax if i were to monitor packets real time..