05-13-2003 09:48 AM - edited 02-20-2020 10:44 PM
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 ??
05-13-2003 10:11 AM
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
05-13-2003 10:31 AM
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
05-13-2003 12:18 PM
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
05-14-2003 06:20 AM
Thanks Matt, I' ll try adding the statements tonight, do some testing & reply tomorrow.
05-19-2003 09:55 AM
Same problem, can you suggest the "right way" to set this up?
Thanks..
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide