cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
450
Views
0
Helpful
6
Replies

PIX, DMZ and DNS

edw
Level 1
Level 1

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

6 Replies 6

acomiskey
Level 10
Level 10

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?

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

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.

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

Thanks

Ed

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

Hi,

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

Thanks

Ed

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card