Cannot Ping Servers in DMZ from Outside and

Answered Question
Mar 8th, 2007

Ok a few issues here.

I just installed a PIX515 replacing my 506. I have 3 interfaces now:

Inside 10.0.10.0/24

DMZ 10.0.20.0/24

Outside 64.69.117.0

I have attached my configuration, but here's my dilemna.

I have mapped a test box on the DMZ, and it's IP is 10.0.20.10, it's outside address is 64.69.117.29.

When I ping that address from an outside client, I get this reply in my Syslog:

03-08-2007 09:15:44 Local4.Critical 10.0.10.1 Mar 08 2007 09:13:34: %PIX-2-106028: Dropping invalid echo reply from inside:10.0.20.10 to outside:69.255.109.188, source address 10.0.20.10 should not match dynamic port translation, real inside:10.0.20.10/1, mapped outside:64.69.117.62/1

Now I know it is a translation problem but I am not sure where, do I need to do a static (inside,dmz) 10.0.10.0 10.0.10.0...?

Less importantly I have another issue:

My default gateway I added a route for the DMZ network, so even with the firewall shutdown, I can ping servers on the DMZ from the inside 10.0.10.0/24 network. Does that make sense? Or should I remove that route, and force all inside PCs to go through the firewall for access to the DMZ? I only ask because it seems that with that route I am defeating the purpose of a DMZ. Please advise?

Last question, like I said I can ping 10.0.20.0/24 network from the 10.0.10.0/24 network without the firewall at all, however for some reason I cannot ping the 10.0.20.4 DMZ interface itself from the 10.0.10.0/24 network, but I can ping that interface from the 10.0.20.0/24 network? What's wrong there?

thanks in advance, Rob

Attachment: 
I have this problem too.
0 votes
Correct Answer by vitripat about 9 years 8 months ago

Cool .. If you want to allow 10.0.10.0/24 network to be pingable from the DMZ host, you can add following command to PIX configuration-

static (inside,dmz) 10.0.10.0 10.0.10.0 netmask 255.255.255.0

clear xlate

Now from 10.0.10.0/24, you should be able to ping the DMZ host and vice-versa. Let me know if this helps.

Regards,

Vibhor.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.7 (3 ratings)
Loading.
vitripat Thu, 03/08/2007 - 07:55

There is one big issue here which would resolve most of the issues you are facing-

Network Loop.

You are right in saying that you should remove that extra route between inside network and DMZ network. Inside network should without exception pass through the firewall if they need to get to the DMZ network. Else the purpose of PIX is defeated.

Note following syslog message:

03-08-2007 09:15:44 Local4.Critical 10.0.10.1 Mar 08 2007 09:13:34: %PIX-2-106028: Dropping invalid echo reply from inside:10.0.20.10 to outside:69.255.109.188, source address 10.0.20.10 should not match dynamic port translation, real inside:10.0.20.10/1, mapped outside:64.69.117.62/1

In the above message, notice this part-

"Dropping invalid echo reply from inside:10.0.20.10"

This clearly indicates that due to network loop, DMZ machine is sending the reply via the inside interface (!!), whereas, it actually should send it from the DMZ interface. The default gateway of the DMZ hosts should be the DMZ interface and for the inside hosts should be the inside interface. Or I should say that if inside host need to pass traffic to any network, it should be via the inside interface of PIX and same for the DMZ.

thebrom Thu, 03/08/2007 - 08:08

ok so no real changes on my firewall, but rather on my default gateway router, and that should clear it up?

Actually it isn't a route I had on the def gate, it was nothing more than a secondary IP address on the FastEth0 interface.

I have removed that and still no luck, do I need to clear xlate? or add a static rute on the PIX for 10.0.20.0/24 out 10.0.10.4? I don't think they will allow me to do that, please advise.

vitripat Thu, 03/08/2007 - 08:18

Yes, nothing much on PIX. Once the route is removed, PIX will have a connected route to 10.0.10.0/22 network via inside interface IP, and to 10.0.20.0/24 network via DMZ interface IP. Do a "clear xlate" also on PIX. If possible, can you provide the config from the router also? To which interfaces of PIX is this router connected?

thebrom Thu, 03/08/2007 - 08:35

Ok I did a clear xlate and tried pinging from the outside to the DMZ and still get no reponse and syslog shows same error.

I can ping from the inside to the DMZ even without the secondary IP on the router.

I have attachjed router config.

Thie def gateway has only one interface, (Fasteth) andit routes things accordingly to everything else. It is only atteched to the inside interface of the firewall.

vitripat Thu, 03/08/2007 - 08:50

Thanks for the outputs. What is the default gateway IP of 10.0.20.10 ?

thebrom Thu, 03/08/2007 - 09:01

the def gateway of that is 10.0.10.15 which is that router I sent you.

vitripat Thu, 03/08/2007 - 09:08

That is still creating the same problem. Right now if you ping the public IP for DMZ host from outside, PIX directs the echo-request to the private IP of the host on DMZ. However, when DMZ tries to reply, it uses its routing table and sends the reply to the router. Therafter router sends the reply based on its routing table to pix inside interface IP, which will generate the same syslog as seen earlier.

As I stated earlier, could you please have the default gateway of the DMZ host be 10.0.20.4 ? Can DMZ host reach the PIX DMZ interface directly or it still has to go through the same router?

thebrom Thu, 03/08/2007 - 09:16

OK Vibhor, I am sorry I misunderstood, but I just switched the DMZ host's gateway to 10.0.20.4, and I can ping 10.0.20.4 from that host, but I cannot ping anything on the 10.0.10.0/24 network, and nothing on the 10.0.10.0/24 network can ping it.

However I can ping the DMZ host from an outside client using the 64.69.117.29 IP, so I am half way there.

Correct Answer
vitripat Thu, 03/08/2007 - 09:28

Cool .. If you want to allow 10.0.10.0/24 network to be pingable from the DMZ host, you can add following command to PIX configuration-

static (inside,dmz) 10.0.10.0 10.0.10.0 netmask 255.255.255.0

clear xlate

Now from 10.0.10.0/24, you should be able to ping the DMZ host and vice-versa. Let me know if this helps.

Regards,

Vibhor.

thebrom Thu, 03/08/2007 - 10:37

spoke to soon.

It was working fine for a while and then all of the sudden all we had disruptions on the internal network, like outlook connectivity to exchange would hang, and I would RDP into a server and lose connectivity, all of this unrelated to the DMZ network as I am on the 10.0.10.0/24 network along with the servers themselves.

Now I removed the command:

static (inside,dmz) 10.0.10.0 10.0.10.0 netmask 255.255.255.0 0 0

and it resolved the issue, what gives?

vitripat Thu, 03/08/2007 - 10:42

It seems that there is still some sort of loop in the network. However we can make things work .. :-)

The reason you loose connectivity seems to be related to PIX doing proxy-arp for 10.0.10.0/24 network on the dmz interface with the static command in. Heres the work around .. reenter following commands on PIX-

static (inside,dmz) 10.0.10.0 10.0.10.0 netmask 255.255.255.0 0 0

sysopt noproxyarp dmz

Now things should work fine. PIX will not proxy-arp (which is the default behaviour) for 10.0.10.0/24 network now on the dmz interface. dmz hosts when attemting to send the traffic to 10.0.10.0/24 network will contact their default-gateway, which is pix's dmz interface. Then only PIX will create a translation and allow the traffic accordingly.

Let me know if this helps.

Regards,

Vibhor.

thebrom Thu, 03/08/2007 - 10:44

Ok, I entered it, I'll let you know what happens in about an hour or so. It makes sense!

Rob

thebrom Thu, 03/08/2007 - 12:02

this appears to have resolved the issue, thanks a million!

Now, is that typicl to have to enter the sysopt noproxyarp command in this situation? Or is it just solving my problem? In otherwords, is this something I should do everytime I create a DMZ?

vitripat Thu, 03/08/2007 - 14:00

Well it is helpful in our scenario because there is a network loop. With the static command in, PIX will do proxy-arp for all the hosts in 10.0.10.0/24 network, and the reason why you faced issues could be explained-

When a host on 10.0.10.0/24 network is trying to communicate with some other host in same network, it would broadcast requesting for the MAC of the other host. Somehow, this broadcast reaches the DMZ interface and hence DMZ replies with its own MAC address. This inturn causes issues with your internal traffic.

The best thing would be to track down where this loop is happening and shut it down. Things will keep working fine with the sysopt command in through ;-)

Hope this explains things.

Regards,

Vibhor.

vitripat Thu, 03/08/2007 - 08:02

Quoting -- Last question, like I said I can ping 10.0.20.0/24 network from the 10.0.10.0/24 network without the firewall at all, however for some reason I cannot ping the 10.0.20.4 DMZ interface itself from the 10.0.10.0/24 network, but I can ping that interface from the 10.0.20.0/24 network? What's wrong there?

You can ping the 10.0.20.0/24 network from 10.0.10.0/24 network due to the network loop. This is the reason you are able to ping the network even with the firewall shut down !! You are unable to ping the DMZ interface from inside network because when PIX's DMZ interface recieves the echo-request, it would be dropped because this echo-request should be coming from the inside network and not the dmz network. Here when PIX recieves the echo-request from the dmz, it will try to send the reply back via the inside interface, based on PIXs routing table. However, this ping will never work even when the network loop is removed because, on PIX firewalls, you cannot ping the farside interface in any case. Which means, from inside network, you may be able to ping the DMZ network hosts, but you wont be able to ping the DMZ interface IP. Here is a link to support the same-

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml#pingsown

Hope this helps. Please let me know after removing the network loop how many of your issues are resolved.

Regards,

Vibhor.

Actions

This Discussion