PIX Communication Problems (DMZ & Inside Network)

[smartin]

Allowing SMTP from DMZ to inside network.

access-list DMZ permit tcp any host xxx.xxx.xxx.xxx eq smtp

access-list DMZ permit icmp any host xxx.xxx.xxx.xxx echo-reply

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 DMZ security10

Everything working OK until the Mail server on the inside network gets rebooted then communication is lost, computers on the DMZ cannot send mail, can't ping the mail server.

Here's the strange part, when I'm on the mail server and I start "pinging" the server on the DMZ communications start working again.

Arp problem on the PIX, on a switch ??

[mostiguy]

Do you have any static commands? They are necessary to open permanent translation slots from low security to high security interfaces. If you only use nat (inside) 0 0.0.0.0 .0.0.0.0/access-list commands, the translation slots are temporary, such that low security ints (DMZ in your case) can only make connections so long as there are connections from high security ints (inside) making outbound connections that keep dynamic (temporary) connection slots open. So, when the inside device stops making conns, the outside device cannot make conns to the higher security int due to lack of a conn slot.

If you post your whole config, we would probably know for sure.

Matt

[smartin]

Thanks Matt, see config below.

PIX Version 6.3(1)

interface ethernet0 auto

interface ethernet1 100full

interface ethernet2 100full

interface ethernet3 auto

interface ethernet4 auto shutdown

interface ethernet5 auto

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 DMZ security10

nameif ethernet3 OPEN security99

nameif ethernet4 OPEN2 security99

nameif ethernet5 Host security25

fixup protocol ftp 21

no fixup protocol h323 h225 1720

no fixup protocol h323 ras 1718-1719

fixup protocol http 80

no fixup protocol ils 389

fixup protocol rsh 514

no fixup protocol rtsp 554

no fixup protocol sip 5060

fixup protocol sip udp 5060

no fixup protocol skinny 2000

fixup protocol smtp 25

fixup protocol sqlnet 1521

no names

access-list DMZ permit icmp any host 172.16.2.4 echo-reply

access-list DMZ permit tcp any host 172.16.2.12 eq smtp

pager lines 24

logging on

logging timestamp

logging buffered warnings

logging trap debugging

mtu outside 1500

mtu inside 1500

mtu DMZ 1500

mtu OPEN 1500

mtu OPEN2 1500

mtu Host 1500

ip verify reverse-path interface outside

ip verify reverse-path interface Host

ip audit info action alarm drop

ip audit attack action alarm drop

no failover

failover timeout 0:00:00

failover poll 15

no failover ip address outside

no failover ip address inside

no failover ip address DMZ

no failover ip address OPEN

no failover ip address OPEN2

no failover ip address Host

nat (inside) 1 172.16.0.0 255.255.0.0 0 0

nat (DMZ) 3 192.168.1.0 255.255.255.0 0 0

nat (Host) 2 0.0.0.0 0.0.0.0 0 0

static (inside,Host) 172.16.0.0 172.16.0.0 netmask 255.255.0.0 0 0

static (Host,DMZ) 172.17.0.0 172.17.0.0 netmask 255.255.0.0 0 0

static (Host,DMZ) 172.18.0.0 172.18.0.0 netmask 255.255.0.0 0 0

static (inside,OPEN2) 172.16.0.0 172.16.0.0 netmask 255.255.0.0 0 0

static (Host,DMZ) 172.0.0.0 172.0.0.0 netmask 255.0.0.0 0 0

static (inside,DMZ) 172.16.0.0 172.16.0.0 netmask 255.255.0.0 0 0

access-group outside in interface outside

access-group inside in interface inside

access-group DMZ in interface DMZ

access-group host in interface Host

route outside 0.0.0.0 0.0.0.0 207.15.46.2 1

route Host 172.0.0.0 255.0.0.0 172.19.1.253 1

route Host 172.17.1.0 255.255.255.0 172.19.1.253 1

route Host 172.18.1.0 255.255.255.0 172.19.1.253 1

[mostiguy]

You have a somewhat odd config.

For static commands, they vary depending on whether or not you use nat.

for nat 0 (i.e, no nat)

static (high security int,low security int) high securitry ips high security ips

is appropriate. So all of your static commands make sense that involve host2 - as that int is not using NAT. But the static(inside,DMZ) command is using NAT, so the config is odd. The no nat form of the static command will map the 172.16/16 to the DMZ interface for hosts on it to access those boxes. I believe what is happening is that when the DMZ server talks to the inside, it refers to the inside server by 172.16.2.12. But when the inside server initiates the commo, that commo gets natted, and the originating IP for said commo is not necessarily 172.16.2.12.

So, I think what happens is the DMZ might have conflicting ideas as to which ip to really use. Do you have any logs for this setup? I would be interested to know if the DMZ box is sending packets that get blocked to the smtp port of an IP address that is being used for nat for the inside interface.

You could try adding:

access-list no-nat-smtp permit ip host 172.16.2.12 host dmz.host.ip.here

nat (inside) 0 access-list no-nat-smtp

that should stop natting between the inside server and the dmz box. after that, and a clear xlate, all commo to and from the inside smtp server should appear as coming from 172.16.2.12 . That might do it

Matt

[smartin]

Thanks Matt, I' ll try adding the statements tonight, do some testing & reply tomorrow.

[smartin]

Same problem, can you suggest the "right way" to set this up?

Thanks..