Cannot telnet to mail server in DMZ - Pix

You have edit out the static / global / nat statements which are needed. Can u pls show those as well?

Need to understand the nat lines for the device as stated above, more specificly if there are nat bypass translation rules in place to support the internal interface communicating with the dmz hosts without triggering the address translation which is defined. This is usually reflected in a nat (interface-name) 0 access-list <acl name>

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2010.01.28 22:52:29 =~=~=~=~=~=~=~=~=~=~=~=

name 192.168.1.0 Ford_Net
name 192.168.3.0 Lincoln_Net
name 192.168.5.0 Colision_Net
name 192.168.1.3 Galileo
name 192.168.0.13 Beethoven
name 192.168.1.2 Einstein
name 209.169.60.176 Verio_Network
name 10.1.1.190 Nancy
name 10.1.1.180 Nostradamus_2
name 10.1.1.179 Nostradamus_1
name 10.1.1.189 Sid
name 192.168.10.2 ADP_Host
name 192.168.7.0 Affordable_Net
name 10.1.1.186 GetWired
name 192.168.0.0 Jaguar_Net
name 10.1.1.187 Ford_Secure
name 192.168.6.0 Holyoke_Net
name 10.1.1.185 Michaelangelo_2
name 10.1.1.184 Michaelangelo_1
name 192.168.1.13 Brahms
nat (inside) 0 access-list no-nat
nat (inside) 10 Jaguar_Net 255.255.248.0 0 0
nat (vacant) 10 192.168.10.0 255.255.255.0 0 0

static (inside,dmz) 10.1.1.181 Einstein netmask 255.255.255.255 2000 250
static (dmz,outside) 209.169.60.179 Nostradamus_1 netmask 255.255.255.255 1000 100
static (dmz,outside) 209.169.60.180 Nostradamus_2 netmask 255.255.255.255 1000 100
static (dmz,outside) 209.169.60.189 Sid netmask 255.255.255.255 1000 100
static (dmz,outside) 209.169.60.190 Nancy netmask 255.255.255.255 1000 100
static (dmz,outside) 209.169.60.186 GetWired netmask 255.255.255.255 1000 100
static (dmz,outside) 209.169.60.187 Ford_Secure netmask 255.255.255.255 1000 100
static (dmz,outside) 209.169.60.185 Michaelangelo_2 netmask 255.255.255.255 50 50
static (dmz,outside) 209.169.60.184 Michaelangelo_1 netmask 255.255.255.255 50 50
access-group to-dmz in interface outside
access-group inside in interface inside
access-group ford-adp-in in interface vacant
access-group dmz-in in interface dmz

ThePhreakshow,

Do you want to allow one machine to talk from inside to the DMZ or all? As of right now your only NAT that would allow traffic in that direction is this one.

static (inside,dmz) 10.1.1.181 Einstein netmask 255.255.255.255 2000 250


So 192.168.1.2 is mapped to 10.1.1.181 when is is talking to devices in the DMZ.

If you want all or more then you will need to open it up with something similar to this.

static (Inside_firewall,DMZ) 192.168.1.0 192.168.1.0 netmask 255.255.0.0 --> the 192.168.1.0 will change depending on what you want to allow to talk.

You will then have to make sure that the port is open in you inside ACL.

Regards,

3nerds

The command should be
static (Inside,DMZ) 192.168.0.0 192.168.0.0 netmask 255.255.0.0

What GuruChia put appears to be accurate for your install, I was just giving an example and allowing you to change it as needed. As you can see my inside name is different.

Regards,

3nerds

You had stated that I currently have one machine capable of talking from inside to DMZ as shown as:

static (inside,dmz) 10.1.1.181 Einstein netmask 255.255.255.255 2000 250

I believe that this static NAT was originally setup to give the DMZ servers access to DNS. The server Einstein is actually the main filserver/DNS/AD server on the internal network.

I tried to telnet to the mail server from this server, (who should have been seen as 10.1.1.181) and it did not work. I tried to ping this machine from a DMZ server (at its NAT'ted 10.1.1.181 address) and that did not work. The DMZ servers are pointing to 10.1.1.181 for DNS, but lookups result in a server timeout.

So for some reason, even this machine cannot telnet to the mail server in the DMZ and currently, the DMZ servers have nowhere to turn to for their DNS. The plot thickens.

I will suggest you remove this line:
static (inside,dmz) 10.1.1.181 Einstein netmask 255.255.255.255 2000 250

You can have your servers in DMZ to access 192.168.1.2 directly for DNS.

Lets check a few basic:

Does your mail server have default gateway setup correctly to the Pix interface?

Does your mail server have firewall enable?

Does your mail server enable SMTP for all subnet? Most mail server block SMTP except for selected network.

The mail server default gateway is setup to be the address of the DMZ interface on the Pix.
The mail server (and underlying Windows Server 2008) are not running any firewalls locally.
The mail server trusts hosts coming from 192.168.x.x and 10.1.1.x networks.
I can telnet to port 25 from any of the other machines that are in the DMZ (10.1.1.x).
If I remove that static NAT to the internal server (EInstein @ 192.168.1.2) then none of the DMZ machines can resolve DNS. They need to go to that machine (Einstein) so they when looking up a site (or mail, or internal web) they get the private IP of 10.1.1.x instead of its public counterpart.

What I mean is to remove
static (inside,dmz) 10.1.1.181 Einstein netmask 255.255.255.255 2000 250

and use this instead:
static (Inside,dmz) 192.168.0.0 192.168.0.0 netmask 255.255.0.0

This way, 192.168.1.2 will map to DMZ as 192.168.1.2. All your DMZ servers can access 192.168.1.2 for DNS.

Does this cause a vuknerability going from a lower security interface (DMZ) to a higher one (Internal)? and does that effectively allow any of my DMZ servers (10.1.1.x) to communicate with any of the machines on the internal network (192.168.x.x)?

Are there corresponding ACL's that need to change as well?

Just want to double check before I make these changes and test it.

Thanks a ton.

This is just to open up the addressing space for the DMZ. You still have to control the traffic by ACL.

By default, Pix will allow higher security interface (e.g. inside) to lower security (e.g. dmz) and the return traffic.

By default, all lower security interface to higher security interface are blocked unless permit by ACL.

So without any ACL, inside can access dmz but not the other way round.

You do need to change (or add if not already done so) the ACL for dmz to allow access to the new natted address for the DNS.

When I add the static mapping as you indicated:

static (Inside,dmz) 192.168.0.0 192.168.0.0 netmask 255.255.0.0

The DMZ computers cannot access the internal DNS server on the inside interface.

I did not change anything with regards to the ACL's that existed previously.

To test this theory, I removed the above static map and replaced it with the previous:

static (inside,dmz) 10.1.1.181 192.168.1.2 netmask 255.255.255.255 2000 250

and everything worked fine again.

Just so you are clear, the DMZ machines need to be able to access the DNS server on the inside interface to recieve the proper IP addresses.... Of course, as things exist right now, anything on the inside can access the machines on the DMZ lower security interface with no problems.

After you remove
static (inside,dmz) 10.1.1.181 192.168.1.2 netmask 255.255.255.255 2000 250
and add this instead
static (Inside,dmz) 192.168.0.0 192.168.0.0 netmask 255.255.0.0

Does your machine accessing DNS as 10.1.1.181 or 192.168.1.2? After you make the change of the nat, you need to make corresponding changes so that your DMZ hosts access 192.168.1.2 as DNS?

You also need to make adjustment to the DMZ ACL to make sure dmz is allow to 192.168.1.2 DNS service.

Finally it will help if you post your global statements. Also do you mind post your ACL again if you made any change since last time you post.

OK, adding the following:
static (Inside,dmz) 192.168.0.0 192.168.0.0 netmask 255.255.0.0
and then changing all of the DMZ servers to point to 192.168.1.2 for their DNS worked fine..... BUT, I did not have to add an ACL for that.

Does this now mean that any kind of traffic is allowed from the DMZ (10.1.1.x) to the internal network (192.168.x.x)?

Here is the current config:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2010.02.08 14:35:53 =~=~=~=~=~=~=~=~=~=~=~=
show run
: Saved
:
PIX Version 6.3(3)
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto shutdown
interface ethernet3 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 vacant security75
nameif ethernet3 dmz security25
clock timezone EST -5
clock summer-time EDT recurring
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
no fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
name 192.168.1.0 Ford_Net
name 192.168.3.0 Lincoln_Net
name 192.168.5.0 Colision_Net
name 192.168.1.3 Galileo
name 192.168.0.13 Beethoven
name 192.168.1.2 Einstein
name 209.169.60.176 Verio_Network
name 10.1.1.190 Nancy
name 10.1.1.180 Nostradamus_2
name 10.1.1.179 Nostradamus_1
name 10.1.1.189 Sid
name 192.168.10.2 ADP_Host
name 192.168.7.0 Affordable_Net
name 10.1.1.186 ADP_GetWired
name 192.168.0.0 Jaguar_Net
name 10.1.1.187 Ford_Secure
name 192.168.6.0 Holyoke_Net
name 10.1.1.185 Michaelangelo_2
name 10.1.1.184 Michaelangelo_1
name 192.168.1.13 Brahms
access-list outbound permit ip any any
access-list no-nat permit ip Jaguar_Net 255.255.248.0 192.168.4.24 255.255.255.248
access-list no-nat permit ip any 192.168.4.24 255.255.255.248
access-list ford-adp-in permit ip 192.168.10.0 255.255.255.0 any
access-list to-dmz permit udp any host 209.169.60.179 eq domain
access-list to-dmz permit udp any host 209.169.60.189 eq domain
access-list to-dmz permit udp any host 209.169.60.190 eq domain
access-list to-dmz permit udp any host 209.169.60.179 eq dnsix
access-list to-dmz permit udp any host 209.169.60.189 eq dnsix
access-list to-dmz permit udp any host 209.169.60.190 eq dnsix
access-list to-dmz permit tcp any host 209.169.60.179 eq www
access-list to-dmz permit tcp any host 209.169.60.180 eq www
access-list to-dmz permit tcp any host 209.169.60.189 eq www
access-list to-dmz permit tcp any host 209.169.60.190 eq www
access-list to-dmz permit tcp any host 209.169.60.179 eq ftp
access-list to-dmz permit tcp any host 209.169.60.180 eq smtp
access-list to-dmz permit tcp any host 209.169.60.180 eq pop3
access-list to-dmz permit tcp any host 209.169.60.180 eq imap4
access-list to-dmz permit udp any host 209.169.60.180 eq 143
access-list to-dmz permit ip any host 209.169.60.186
access-list to-dmz permit ip any host 209.169.60.187
access-list to-dmz permit tcp any host 209.169.60.180 eq 465
access-list to-dmz permit tcp any host 209.169.60.180 eq https
access-list to-dmz permit udp any host 209.169.60.180 eq 443
access-list to-dmz permit icmp any any
access-list dmz-in permit udp any host 10.1.1.181 eq domain
access-list dmz-in permit ip 10.1.1.0 255.255.255.0 any
access-list dmz-in permit tcp any host 10.1.1.181 eq domain
access-list inside deny udp any any eq 135
access-list inside deny udp any any eq tftp
access-list inside deny udp any any eq netbios-ns
access-list inside deny udp any any eq netbios-dgm
access-list inside deny udp any any eq 139
access-list inside deny tcp any any eq 135
access-list inside deny tcp any any eq 137
access-list inside deny tcp any any eq 138
access-list inside deny tcp any any eq netbios-ssn
access-list inside deny tcp any any eq 445
access-list inside deny tcp any any eq 593
access-list inside deny tcp any any eq 4444
access-list inside permit ip any any
access-list unity_splitTunnelAcl permit ip Jaguar_Net 255.255.255.0 any
access-list unity_splitTunnelAcl permit ip Ford_Net 255.255.255.0 any
access-list unity_splitTunnelAcl permit ip Lincoln_Net 255.255.255.0 any
access-list unity_splitTunnelAcl permit ip Colision_Net 255.255.255.0 any
access-list unity_splitTunnelAcl permit ip Affordable_Net 255.255.255.0 any
access-list unity_splitTunnelAcl permit ip 192.168.10.0 255.255.255.0 any
access-list unity_splitTunnelAcl permit ip 10.1.1.0 255.255.255.0 any
no pager
logging on
logging timestamp
logging trap informational
logging history errors
logging host inside 192.168.0.3
icmp permit any outside
icmp permit any inside
icmp permit any dmz
mtu outside 1500
mtu inside 1500
mtu vacant 1500
mtu dmz 1500
ip address outside 209.169.60.178 255.255.255.240
ip address inside 192.168.1.1 255.255.255.0
ip address vacant 192.168.10.1 255.255.255.0
ip address dmz 10.1.1.177 255.255.255.240
ip verify reverse-path interface outside
ip verify reverse-path interface inside
ip verify reverse-path interface vacant
ip verify reverse-path interface dmz
ip audit info action alarm
ip audit attack action alarm
ip local pool vpnpool 192.168.4.25-192.168.4.30
global (outside) 10 interface
global (dmz) 10 interface
nat (inside) 0 access-list no-nat
nat (inside) 10 Jaguar_Net 255.255.248.0 0 0
nat (vacant) 10 192.168.10.0 255.255.255.0 0 0
static (dmz,outside) 209.169.60.190 Nancy netmask 255.255.255.255 1000 100
static (dmz,outside) 209.169.60.179 Nostradamus_1 netmask 255.255.255.255 1000 100
static (dmz,outside) 209.169.60.180 Nostradamus_2 netmask 255.255.255.255 1000 100
static (dmz,outside) 209.169.60.189 Sid netmask 255.255.255.255 1000 100
static (dmz,outside) 209.169.60.186 ADP_GetWired netmask 255.255.255.255 1000 100
static (dmz,outside) 209.169.60.187 Ford_Secure netmask 255.255.255.255 1000 100
static (dmz,outside) 209.169.60.185 Michaelangelo_2 netmask 255.255.255.255 50 50
static (dmz,outside) 209.169.60.184 Michaelangelo_1 netmask 255.255.255.255 50 50
static (inside,dmz) Jaguar_Net Jaguar_Net netmask 255.255.0.0 2000 250
access-group to-dmz in interface outside
access-group inside in interface inside
access-group ford-adp-in in interface vacant
access-group dmz-in in interface dmz
: end

pix#

I looked at your ACL, this is what you have:

access-list dmz-in permit udp any host 10.1.1.181 eq domain
access-list dmz-in permit ip 10.1.1.0 255.255.255.0 any
access-list dmz-in permit tcp any host 10.1.1.181 eq domain

The second line basically allow your DMZ to access anything. You should tighted this up.

What type of communications do you think the DMZ would need to have with the internal network? Just DNS requests?

What would your recommended ACL instead of line 2 be?

Last question and then I will award points. THanks.

Thanks for sticking with me on this thread.