DMZ access from two different sources

[wilson_1234_2]

I am trying to set up a failover scenario using a CSS, but the basic connectivity is a problem right now.

The physical connections are shown in the attached document.

Normal operation has the customers accessing the HTTPS server from the HQ site from the Internet and that is working fine.

The idea is to have the CSS redirect the traffic to the DR HTPPS server if there is a failure of the HQ server. I have the address on the remote DR site statically mapped in the HQ 525 firewall and have allowed HTTP and HTTPS. I can ping it from the Internet, but I cannot access the DR HTPPS page from the HQ internet.

I can access the DR HTTPS page from the HQ internal network, which makes me think an access-list problem somewhere.

My questions:

1. Since my attempted connections to the DR HTTPS server will be coming from the inside interface to a DMZ interface on the DR PIX, and since the security levels are from a more secure (inside) to less secure (DMZ) should I be able to make this connection with no problem?

2. There is an access-list applied inbound to the DMZ1 interface on the DR pix, do I have to allow connections from the remote site in this list?

3. If so, which source should I make it?

[beth-martin]

This sample configuration demonstrates how to set up the PIX Firewall for access to a mail server located on the Demilitarized Zone (DMZ) network.

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00806745b8.shtml

[acomiskey]

1. Without an acl, yes.

2. No, fw is stateful.

Probably a nat or routing problem on dr pix. Log on dr pix while you attempt to hit it from the internet. If you get "no translation group" then you have nat issue. The other possibility is the request is hitting the https server but the reply is being routed to the outside of dr pix, not back to inside.

[wilson_1234_2]

thanks for the reply.

In my question one, are you saying "without and ACL, yes"

Are you talking abount an ACL that explicitly restricts traffic "inbound" from the DMZ interface?

[acomiskey]

In question 1 you asked if you should be able to make a connection from inside to dmz. My answer was yes, unless you have an existing acl applied into inside interface in which case you would need to allow the traffic.

[wilson_1234_2]

Sorry,

Can you explain your answer of the firewall being "stateful" to my question #2?

[acomiskey]

An acl applied into your dmz interface will filter the traffic originating from the dmz. If a connection was made from the inside to the dmz, the return traffic from the dmz to the inside would not be filtered by the acl as the firewall will allow it as being part of the original communication from inside to dmz. That is why it is called being a stateful firewall. An acl in a switch for example is not stateful. Hope that makes sense.

[wilson_1234_2]

please forgive me, I am jus trying to understand.

In question 1, I asked since the traffic is originating from inside and going to DMZ, should this be allowed,

You said, unless ther is an acl.

If it is stateful, then the acl would have no affect, correct?

The only thing that the acl would apply to would be traffic originating from DMZ to the outside, ot any lower security interface?

Is that correct?

If it is, why would you filter traffic entering the DMZ?

Why not just filter traffic allowed inbound to your protected interfaces from lower security interfaces?

[acomiskey]

I think we're getting off track here.

"In question 1, I asked since the traffic is originating from inside and going to DMZ, should this be allowed"

Yes.

"You said, unless ther is an acl."

I said unless there is an acl applied into "inside" interface.

"If it is stateful, then the acl would have no affect, correct?"

An acl applied into the dmz interface would have no effect on traffic that was initiated from the inside to the dmz, yes that is correct.

"The only thing that the acl would apply to would be traffic originating from DMZ to the outside, ot any lower security interface?"

It would apply to traffic from the DMZ to anywhere.

I don't think this is an acl issue. Like I said before, I think you have a nat or a routing problem.

[wilson_1234_2]

Ok,

I see, I missed the applied to the "inside"

Sorry, but it bugs me when I don't understand it completely.

Thanks for the help.

[acomiskey]

No problem, whats the status on this? Making any progress?

[wilson_1234_2]

Yes,

I have it working now. I have not been at this job but for a month and the network design was done by a security CCIE.

It is sort of overly complicated I think.

But the problem was that there is a VPN tunnel from HQ DMZ to DR DMZ server on the inside network.

What i didn't see in the beginning is that the DMZ's are also NATed to a different network on the inside to inside interfaces of the PIX devices, and the HQ server NAT address was not in the encryption access-list on the DR side.

I appreciate you helping me understand the PIX.