DMZ traffic Problem on PIX 515

[marcas.rice]

I have been giving a new subnet for my DMZ interface, the PIX 515e with IOS ver 6.3 (3) has 3 interfaces, inside, outside, and DMZ. The outside subnet and the DMZ are different subnets.

I have setup a server in the DMZ with a Static Nat to the inside subnet , this passes traffic without any problems unless your on the outside interface subnet. If I set up a laptop on the outside subnet with it default gateway the same as the pix, I am unable to access the server in the DMZ subnet. However if I am anywhere else (i.e. the internet) all works fine.

I have enclosed the Pix config and any help would be appreciated.

[binhkdinh]

Marcas,

If I understand you correctly, you're trying to access the server in the DMZ (46.18.106.160 /27) from the outside, correct? If that's true, you need to add a static mapping (dmz,outside), then add an entry on the "inbound" ACL to permit traffic to the nat'ed IP.

Also, you don't have an access-group attached to the inside interface. Is that intended or truncated?

HTH

-Binh

[marcas.rice]

I appreciate your response and the config changes would be something like this:

static (DMZ,outside) 63.87.109.9 46.18.106.163 netmask 255.255.255.255 0 0

and add:

access-list inbound remark Allow CITRIX/ICA Traffic to Citrix Servers

access-list inbound permit tcp any host 63.87.109.9 eq citrix-ica

access-list inbound permit tcp any host 63.87.109.9 eq 2598

access-list inbound permit tcp any host 63.87.109.9 eq www

The missing ACL on the inside interface is by design because a websense server is being used to police outbound access, this piece of the config was truncated.

The additions your suggesting to be added the config should make the traffic come in and out the outside interface to the DMZ. However, in this case, there is a dedicated T1 for the DMZ interface.

It appears I left this out of the original problem description, my apologies.

So this brings me back to my problem, Since there is a dedicated circuit for the outside interface and a dedicated circuit for the DMZ interface, I figured that the reason this didn't work was because traffic was coming in thru the DMZ interface, but when traffic is sent back to the host the pix sees the destination as being locally connected, so instead of sending the traffic thru the DMZ interface back out, its trying to send it out thru the outside interface.

Any way around this or would your proposed config changes fix this as well?

Thank you for your help, I appreciate it.

[binhkdinh · Accepted solution]

Marcas,

My earlier reply was to fix the problem that prevented you from accessing the DMZ from the outside.

Now, accessing the inside coming in thru the DMZ is a different problem. For this, you can try to isolate the problem to the source by adding a static route for that particular source going out thru DMZ. The command should be similar to the one you currently have:

route dmz 66.160.222.239 255.255.255.255 46.18.106.161 1.

HTH.

-B

[marcas.rice]

Thank you for your reply's, I wanted you to know how I fixed it.

I theorized that the problem was that when traffic was returning from the server on the way out, the pix would look at the destination address and decide that the traffic was local to the outside interface, not the DMZ where the traffic originated from. Because of this the traffic was dropped. The laptop on the outside interface has an Ip address of 63.87.109.190/26. Because of my theory, it seemed that I needed the PIX to think that the 63.87.109.190/26 was not on the same subnet as 63.87.109.137/26. I simply changed the subnet mask to a /27 on the outside interface of the PIX. Although I lost 30 external IP addresses on the outside interface, The Pix now forwards traffic from the DMZ interface back out the DMZ interface. The Goal was to make all traffic inbound from the dedicated T1 on the DMZ to go back out the DMZ.

Now that the immediate problem is solved, I wonder if I removed these two statements would accomplish this as well:

ip verify reverse-path interface outside

ip verify reverse-path interface inside

That's for testing another day. Thank you again for your replies.