PIX, DMZ and DNS

Unanswered Question
Jun 12th, 2007

Hi,

I have just put a web server into a DMZ zone behind a PIX 520. I have a bunch of users on the inside network and then a card for the outside network.

Our DNS is offsite IE not behind our firewall and we are currently on NT4. So the internal clients have WINS only for internal resolution.

When I ping the website which is being served in the DMZ, from a internal client it was giving me the correct lookup from the external DNS. Of course the client couldn't get to the website as PIX520 6.3 OS does not allow for route going out and back in.

Anyway over night something has happen as the resolution is now the internal NAT address in the firewall and the hosts can now see the website.

My question is this:

Does the pix compensate for this somehow or how do people get the lookup correct for internal client looking at DMZ websites without affect external DNS entries.

Thanks

Ed

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
acomiskey Tue, 06/12/2007 - 04:49

Something must have changed somewhere or the pix is configured to do dns doctoring. It would not do anything automatically. Could you post the pix config?

edw Tue, 06/12/2007 - 05:35

Hi,

Nothing has changed - I was wondering if it was a routing table of sorts that was updated ??

PIX Version 6.3(4)

interface ethernet0 auto

interface ethernet1 auto

interface ethernet2 auto

interface ethernet2 vlan1 physical

interface ethernet2 vlan2 logical

interface ethernet3 auto

nameif ethernet0 out security0

nameif ethernet1 in security100

nameif ethernet2 dmz1 security50

nameif ethernet3 perimeter_2 security60

nameif vlan2 dmz2 security45

.

.

.

domain-name at-bristol.org.uk

fixup protocol dns maximum-length 512

.

.

.

no names

.

.

.

access-list Outbound permit tcp 17.1.40.0 255.255.255.0 any eq www

access-list Outbound permit udp 17.1.40.0 255.255.255.0 host x.x.x.x eq domain

access-list Outbound permit udp 17.1.40.0 255.255.255.0 host x.x.x.x eq domain

access-list Outbound permit udp 17.1.40.0 255.255.255.0 host x.x.x.x eq domain

.

.

.

access-list Inbound permit tcp any host 18.1.40.4 eq www

access-list Inbound permit tcp any host 18.1.40.4 eq https

.

.

.

access-list DMZ-Farm permit udp 17.2.30.4 255.255.255.240 host x.x.x.x eq domain

access-list DMZ-Farm permit udp 17.2.30.4 255.255.255.240 host x.x.x.x eq domain

access-list DMZ-Farm permit udp 17.2.30.4 255.255.255.240 host x.x.x.x eq domain

.

.

.

ip address out 18.1.40.2 255.255.255.0

ip address in 17.1.35.1 255.255.255.0

ip address dmz2 17.2.30.1 255.255.255.0

.

.

.

arp timeout 14400

.

.

.

nat (inside) 2 17.1.40.0 255.255.255.0 0 0

.

.

.

static (dmz2,out) 18.1.40.4 17.2.30.4 netmask 255.255.255.255 0 0

access-group Inbound in interface out

access-group Outbound in interface in

access-group DMZ2 in interface dmz2

route outside 0.0.0.0 0.0.0.0 18.1.40.1 1

route inside 17.1.40.0 255.255.255.0 17.1.35.2 1

Thanks

Ed

acomiskey Tue, 06/12/2007 - 05:50

There is nothing in your pix config which would allow http://18.1.40.4 from the inside. The inside clients must be resolving the name to 17.2.30.4 somehow.

edw Tue, 06/12/2007 - 15:30

The PIX must be caching the ip somehow. Its the only explaination I can think of.

Thanks

Ed

acomiskey Wed, 06/13/2007 - 04:48

The pix doesn't cache anything. Sure your clients haven't cached the site?

edw Wed, 06/13/2007 - 14:36

Hi,

no defo not. Well - it works so, would of liked to figure out the reason thou..

Thanks

Ed

Actions

This Discussion