From DMZ to two internal servers 2

[Guest_imported]

I have tried configuring this several different ways. All I have succeeded in doing is failing miserabley. I'm not a firewall expert by any means. I am trying to get the 172.31.5.6 to access to both 10.1.1.33 and 10.1.1.15. However, I can't seem to succeed someone here is my last hope. (Note Cisco TAC hasn't even come up with a useful solution) If anyone has any ideas I am more than welcome to hear them. You can also ask me if you need any information.

Here is what I have configured so far:

PIX Version 6.0(1)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 KEY_DMZ security10
nameif ethernet3 intf3 security15
nameif ethernet4 intf4 security20
nameif ethernet5 intf5 security25
enable password encrypted
passwd encrypted
hostname WWR-PIX
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000
fixup protocol http 663
names
pager lines 24
logging on
logging buffered debugging
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 10baset
interface ethernet3 auto shutdown
interface ethernet4 auto shutdown
interface ethernet5 auto shutdown
mtu outside 1500
mtu inside 1500
mtu KEY_DMZ 1500
mtu intf3 1500
mtu intf4 1500
mtu intf5 1500
ip address outside xxx.xxx.xxx.xxx 255.255.255.255
ip address inside 10.1.1.29 255.255.0.0
ip address KEY_DMZ 172.31.5.4 255.255.255.224
ip address intf3 127.0.0.1 255.255.255.255
ip address intf4 127.0.0.1 255.255.255.255
ip address intf5 127.0.0.1 255.255.255.255
ip audit info action alarm
ip audit attack action alarm
no failover
failover timeout 0:00:00
failover poll 15
failover ip address outside 0.0.0.0
failover ip address inside 0.0.0.0
failover ip address KEY_DMZ 0.0.0.0
failover ip address intf3 0.0.0.0
failover ip address intf4 0.0.0.0
failover ip address intf5 0.0.0.0
pdm history enable
arp timeout 14400
global (outside) 1 xxx.xxx.xxx.xxx
global (KEY_DMZ) 1 172.31.5.6-172.31.5.29
global (KEY_DMZ) 1 172.31.5.30
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
alias (inside) 10.1.1.30 xxx.xxx.xxx.xxx 255.255.255.255
static (inside,KEY_DMZ) 172.31.5.5 10.1.1.150 netmask 255.255.255.255 0 0
static (inside,outside) xxx.xxx.xxx.xxx 10.1.1.30 netmask 255.255.255.255 0 0
static (inside,KEY_DMZ) 172.31.5.6 10.1.1.33 netmask 255.255.255.255 0 0
conduit permit tcp host xxx.xxx.xxx.xxx eq smtp any
conduit permit icmp any any
conduit permit icmp any any echo-reply
conduit permit icmp any any source-quench
conduit permit icmp any any unreachable
conduit permit icmp any any time-exceeded
conduit permit tcp host xxx.xxx.xxx.xxx eq 443 any
route outside 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xxx 1
route inside 10.2.0.0 255.255.0.0 10.1.1.2 1
route inside 10.3.0.0 255.255.0.0 10.1.1.3 1
route inside 10.4.0.0 255.255.0.0 10.1.1.1 1
route inside 10.5.0.0 255.255.0.0 10.1.1.5 1
route inside 10.6.0.0 255.255.0.0 10.1.1.6 1
route inside 10.7.0.0 255.255.0.0 10.1.1.7 1
route inside 10.8.0.0 255.255.0.0 10.1.1.8 1
route inside 10.140.0.0 255.255.0.0 10.1.1.140 1
route KEY_DMZ 156.77.48.0 255.255.240.0 172.31.5.3 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 si
p 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
http server enable
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
no sysopt route dnat
telnet 10.1.1.1 255.255.255.255 inside
telnet 10.1.1.36 255.255.255.255 inside
telnet 10.1.1.27 255.255.255.255 inside
telnet timeout 5
ssh timeout 5
terminal width 80
Cryptochecksum:

 

[gbiello]

For starters, I don't see any conduits permitting (non ICMP) traffic to those IP's you specify. I'm not entirely sure how conduits work in a 3-interface setup, so I would recommend replacing them with access-lists. They're pretty easy. Here's a example:
access-list fromout permit icmp any any
access-list fromout permit tcp any host w.x.y.z eq telnet
access-group fromout in interface outside

on the KEY_DMZ interface you would need something like:
access-list fromdmz permit ip host 172.31.5.6 host 10.1.1.15
access-list fromdmz permit ip host 172.31.5.6 host 10.1.1.33
access-list fromdmz permit icmp any any
access-list fromdmz deny ip 172.31.5.6 255.255.255.224 10.0.0.0 255.0.0.0
access-list fromdmz permit ip any any
This gives your DMZ server access to those two IP's inside, and nothing else inside. It then gives you full access to the internet (even though your config doesn't apparently have nat translations set up for that purpose).

Next, you make it seem like you have a DMZ server with IP 172.31.5.6, but you're also doing a static translation to it. This would cause a conflict.

Instead of the "static (inside,KEY_DMZ)" translations and the "global (KEY_DMZ)", you could use a
static (inside,KEY_DMZ) 10.0.0.0 10.0.0.0 netmask 255.0.0.0
to translate the addresses to themselves, as you don't really need to translate the addresses to the DMZ. This would also make the above "fromdmz" access-list work. If not, you would have to replace the internal IP (10.1.1.x) with it's dmz static counterpart (172.31.5.y).

On another subject, syslogging is a great way to troubleshoot.

Hopefully this is all clear (and accurate) and I haven't overlooked anything.
-gbiello

 

[tschouten]

It makes sense to me unfortunately I'm stuck with conduits due to the fact my manager refuses to allow me to move to Access-lists. I understand access lists better than conduits this is one of the reasons I'm having a hard time. I should probably have been a bit more specific in what is going on in this Pix. E/0= Outside which of course is the internet side. E/2=Key_DMZ which is a T1 line from a company that needs access to a specific set of servers. and of course we all know what E\1 is. I had pretty much the same idea with an access-list set I came up with and provided my boss. But he would have nothing to do with access lists and demanded I use conduits. He's the one who originally configured and I got stuck with troubleshooting it. So I aggree with you, use access-lists. I've tried using the same theory with conduits but for some reason they wont allow you to make two conduit statements for 172.3.5.x. When you can with an access list does this make any sense to anyone?

I'm about ready to pull my hair out..hate conduits!! Oh, by the way thanks for your post. It does make a lot of sense I just wish I could use it!

 

[yizhar]

HI.

* As mentioned by gbiello, syslog messages are a must for troubleshooting. It will give you some answers and important info.

* There is a conflict here:
static (inside,KEY_DMZ) 172.31.5.6 10.1.1.33
global (KEY_DMZ) 1 172.31.5.6-172.31.5.29

You do not need the global (KEY_DMZ) unless you want inside to access DMZ. Do you?
In any case this conflict must be fixed.

* You have mentioned in your post the host 10.1.1.15, but here it is different. Is there an extra 0 in the address:
static (inside,KEY_DMZ) 172.31.5.5 10.1.1.150

* After changing "global" "static" and other tranlation related commands, remember to issue the "clear xlate" command at the pix or reboot it.
You should also check that there are no ARP problems if you change ip addresses. Check the neighbour routers ARP tables to verify.

* Remember that you should provide and troubleshoot ip routing, not only the pix itself. In your case you should verify that the DMZ partner company is configured with proper routing all the way to 172.31.5.X and is not filtering it.

* For usage of conduit commands, here is a sample for you:
static (inside,KEY_DMZ) 172.31.5.5 10.1.1.15
static (inside,KEY_DMZ) 172.31.5.6 10.1.1.33
conduit permit tcp host 172.31.5.5 156.77.48.0 255.255.240.0 eq ????
conduit permit tcp host 172.31.5.6 156.77.48.0 255.255.240.0 eq ????

* The "alias" command can make troubles because of proxy arp. If all you need is DNS translation, then better solution is using internal DNS server without the alias command at all, and alternate solution is to keep the "alias" but add this command:
sysopt noproxyarp inside

* You have unused interfaces, but you are allowing access from internet to your web server on inside. Not such a good idea. You should plan implementing a DMZ for your servers and move or add servers as needed.

Bye
Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar

 

[tschouten]

Thanks Yizhar and gbiello,

I truly appreciate all of your information. I got thrown into this by being the only cisco cert person on my staff. And have never worked on or even looked at pix or vpn until a day before I posted this.

When gbiello mentioned there was a conflict the light finally clicked on (all be it late last night)! I finally started to remotely grasp how conduits and static commands worked together. When I started looking at how I could do this all with acl's I started understanding things alittle more. As I said this got handed to me after my manager couldn't succeed with it, I'm only a switch and router person on his team. So I feel like a complete idiot when it comes to working on a PIX. By the way my boss also refuses to use DNS internally. And I apologize if I seem like the firewall moron I am.

This is what I did, it seems to work properly. I'm just wondering if I left any holes?? (not to mention my boss thinks I am just letting everything in by doing this..I don't think I am)


no static XXXXXXXXX

static (inside,key_dmz) 10.1.0.0.0 10.1.0.0.0 netmask 255.255.255.255. 0 0
conduit permit tcp host 10.1.1.150 eq any 172.31.5.0 255.255.255.224
conduit permit tcp host 10.1.1.15 eq any 172.31.5.0 255.255.255.224
conduit permit tcp host 10.1.1.33 eq any 172.31.5.0 255.255.255.224
conduit deny any host 10.0.0.0 eq any 172.31.5.0 255.255.255.224

 

[yizhar]

HI.

> static (inside,key_dmz) 10.1.0.0.0 10.1.0.0.0 netmask 255.255.255.255
This is not your actual config - copy and paste the real one ...

The static command is primarly designed for single or few hosts, I suggest one of the following 3 options instead:

1. To provide access from DMZ to specific several hosts and not to the whole internal network, use STATIC and CONDUIT:
static (inside,KEY_DMZ) 172.31.5.5 10.1.1.15
conduit permit tcp host 172.31.5.5 ... See the sample in my previous post.
You will also need to verify that ip routing to 172.31.5.X is configured all the way.

2. To provide access from DMZ to the whole inside or large number of hosts, you can use "nat 0 access-list" and CONDUIT. It seems to me better then static because static does also proxyarp and I think it has more overhead on the pix, and is also less secure for that reason.

3. You can also go similar to what you did, but with 3 static statements one for each server, and not a single statement for all the network:
static (inside,key_dmz) 10.1.1.150 10.1.1.150
static (inside,key_dmz) 10.1.1.15 10.1.1.15
static (inside,key_dmz) 10.1.1.33 10.1.1.33

* In any translation method you choose (static nat, static with same address, or nat 0) when you use CONDUIT it is better to be more specific and define which ports are open, unless you need free access between the networks. For this you don't need a firewall - you can connect the DMZ router directly to your LAN.

Bye
Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar