Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

*********DEVICES MONITORING TROUGH THE FIREWALL********

HI FW Experts,

                        I have a dilemma for devices monitoring through the firewall(ASA 5020). The monitoring server is on a DMZ, let's named it dmz108 and I have server in different DMZs that i want to monitor. First things that comes in mind is PING to the FAR SIDE is DENY by design, I am right? If so, is there any workawrround for this rule? But testing with packet tracer shows that the packet get to the interface,both ways.. Below is partial conf for the dmzs and print screen of the packet tracer.

PS Poller,monitoring server, is able to poll device in the INSIDE network.

static (inside,Outside) 20x.9x.xx.7x Server-DMZ107 netmask 255.255.255.255 --> Needs to ping the global to access DMZ107?

access-group DMZ103_access_in in interface DMZ103
access-group DMZ107_access_in in interface DMZ107

static (DMZ103,DMZ108) DMZ103-Network DMZ103-Network netmask 255.255.255.0
static (DMZ107,DMZ108) DMZ7-Network DMZ107-Network netmask 255.255.255.0

static (inside,DMZ103) 10.1x.0.0 10.1x.0.0 netmask 255.255.0.0

Thanks,

Jean Paul

6 REPLIES
New Member

Re: *********DEVICES MONITORING TROUGH THE FIREWALL********

Any ideas guys... Really need your help to get this issue sorted out.

Thanks,

Jean Paul

Cisco Employee

Re: *********DEVICES MONITORING TROUGH THE FIREWALL********

Hi Jean Paul,

Although you cannot ping a far-side interface by design, you certainly can ping a far side device. You'll treat it like any other traffic through the firewall, so you need to make sure you have the appropriate routes, translations, and ACL rules to allow the traffic.

It looks like the packet-tracer permits the traffic, so give it a try and see if you are able to ping the devices. If you're having trouble getting a reply, you may want to enable ICMP inspection to make sure that the return traffic is allowed back through the firewall. You can do this with the following commands:

policy-map global_policy
class inspection_default

    inspect icmp

service-policy global_policy global

If traffic is still failing, take a look at the syslogs that are generated and setup some packet captures to understand when/where the packets are dropped.

Hope that helps.

-Mike

New Member

Re: *********DEVICES MONITORING TROUGH THE FIREWALL********

Hi Mike,

               First of all thanks for the reply. WIth that bing said, let's get to the bottom of this issue. I have struggling with this issue for a while, I do have icmp enable in the inspect rule as per below,but the packet still failling. Let me help you understand the topology. The device that im trying to reach has two IPs, one for internal access(dmz103), and one for external access dmz107 which is mapped to a public IP. User from the inside network will use dzm103 to access this device and user from outside(Internet) will used the global of course which mapped to dzm107. Packet come from outside do hit the ACL,but never make it to dzm107.

policy-map global_policy
class inspection_default
   inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny 
  inspect sunrpc
  inspect xdmcp
  inspect sip 
  inspect netbios
  inspect tftp
  inspect pptp
  inspect dcerpc
inspect icmp

Thanks,

Jean Paul

Cisco Employee

Re: *********DEVICES MONITORING TROUGH THE FIREWALL********

Hi Jean Paul,

Which interface does the device actually reside off of? It sounds like the device is located off the dmz107 interface, but I'm not sure. A simple topology diagram might help clarify.

Let's assume the device you are trying to ping is behind the dmz107 interface and has an IP address of 10.1.1.1. If you want to ping this from the Internet, you need to configure something like this:

static (dmz107,outside) 20x.9x.xx.7x 10.1.1.1 netmask 255.255.255.255

access-list outside_access_in permit icmp any host 20x.9x.xx.7x

access-group outside_access_in in interface outside

With these commands, users on the Internet would ping 20x.9x.xx.7x, which should be untranslated to 10.1.1.1 and sent on to the device who owns this IP address behind the dmz107 interface.

You would also need to check the output of 'show route' and make sure there is a route that will match 10.1.1.1 for the dmz107 interface if it is not a directly connected subnet.

If you are still stuck, please post a sanitized copy of your NAT and ACL configurations, as well as the syslog messages that get generated when you try to ping so we can identify where the problem is.

-Mike

New Member

Re: *********DEVICES MONITORING TROUGH THE FIREWALL********

Hi Mike,

             The NAT and ACL are well configured, but i just realized that packet come through the Internet for dzm107 are looping out to the OUSIDE interface again.DMZ107 is directly connected via DZM switch... See packet tracer screen shot

Thanks,

Jean Paul

Cisco Employee

Re: *********DEVICES MONITORING TROUGH THE FIREWALL********

Hi Jean Paul,

I'm still not sure what the topology looks like here, but is 10.1xx.x.2xx the global/mapped address or the local/real IP address of the server you are trying to access? The packet-tracer should use the global address as the destination IP, since this is what hosts on the Internet would be connecting to. If you follow my last example, the packet-tracer should be destined to 20x.9x.xx.7x, since this is the global address configured in the following example static:

static (dmz107,outside) 20x.9x.xx.7x 10.1.1.1 netmask 255.255.255.255

-Mike

363
Views
0
Helpful
6
Replies
CreatePlease login to create content