DMZ accesing internal network on ASA

Unanswered Question

Hi people,


in a 5510 ASA I need to install some public servers in DMZ interface, some of them need to get access to internal network, however, I put a static and the access-list to do that, but logging says theres not translation between them (DMZ and Internal) what do I need to do, is there some aditional configuration?


In fac, my servers are working fine with a static and the access-list for them, and they can be accessed form internet with no problem,


can somebody help me please ??


Martin

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
sundar.palaniappan Sun, 03/23/2008 - 10:26
User Badges:
  • Green, 3000 points or more

Martin,


Can you post the static and access list you are using.


Which direction are you initiating the traffic - from inside to DMZ or DMZ to inside?



derrickc Tue, 03/25/2008 - 11:22
User Badges:

It looks like the access-list "DMZ_access_in" may have an error. You are permitting the real DMZ IP address to the NAT'd inside address. Wouldn't you want to permit it to the inside server (the one you are trying to communicate with). For example:


access-list DMZ_access_in extended permit ip host 192.168.150.33 host


sundar.palaniappan Tue, 03/25/2008 - 12:10
User Badges:
  • Green, 3000 points or more

Martin,


Yes, as the previous poster indicated you need to permit the host on the DMZ (192.168.150.33) to access the device (inside host) in your DMZ ACL. Alternatively, you can configure the DMZ host access the entire inside network as follows.


access-list DMZ_access_in extended permit ip host 192.168.150.33 172.25.1.0 255.255.255.0


HTH


Sundar

cjake7777 Tue, 03/25/2008 - 12:23
User Badges:

It looks like your "static (DMZ,inside) 172.25.1.1 192.168.150.33 netmask 255.255.255.255" statement is in error. Its saying that 192.168.150.33 is the same device as 172.25.1.1? I dont think you are trying to do that, take it out, then it should work.

sundar.palaniappan Tue, 03/25/2008 - 12:33
User Badges:
  • Green, 3000 points or more

We misunderstood your requirement. It looks like you are trying to get 192.168.150.33 talk to 172.25.1.1, correct?


If it is then change the static as follows and test.


no static (DMZ,inside) 172.25.1.1 192.168.150.33 netmask 255.255.255.255


static (DMZ,inside) 192.168.150.33 192.168.150.33 netmask 255.255.255.255


Keep the access list one of two ways.


access-list DMZ_access_in extended permit ip host 192.168.150.33 host 172.25.1.1

(or)


access-list DMZ_access_in extended permit ip host 192.168.150.33 172.25.1.0 255.255.255.0



cjake7777 Tue, 03/25/2008 - 12:48
User Badges:

A way to get around "static (DMZ,inside) 192.168.150.33 192.168.150.33 netmask 255.255.255.255" is nat 0 statements. ex:

access-list 100 extended permit ip 172.25.1.0 255.255.255.0 192.168.150.0 255.255.255.0

!

nat (inside) 0 access-list 100

!

I just hate those crazy static statements....Just a suggestion

sundar.palaniappan Tue, 03/25/2008 - 17:14
User Badges:
  • Green, 3000 points or more

Martin,


The static identify nat I had suggested earlier should have worked as well. Did you do a 'clear xlate' after making the configuration change?


As you are probably aware the static identity nat and nat 0 should produce the same result, which is to pass traffic without IP translation.


The following link has examples for both.


http://www.cisco.com/en/US/docs/security/asa/asa70/configuration/guide/cfgnat.html#wp1043458


HTH


Sundar

Actions

This Discussion