Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ip address setup questions 1

Status
Not open for further replies.
Jan 15, 2002
126
When setting up a dmz, is the ip address that's assigned to the dmz interface one that is made up that is similar to the one already assigned to the server on the dmz?

Thanks!
 
It would be a good idea to use an IP address in the same range as your server!! LOL

Use a private range in your DMZ, like a 172.16.10.0/24 or something! You could then give the DMZ NIC 172.16.10.1 and your server might then be 172.16.10.100, or whatever!!

Then do a static mapping that maps the servers actual IP address to its live routable IP address!

static (dmz, outside) aaa.bbb.ccc.ddd 172.16.10.100 netmask 255.255.255.0 0 0

Chris.
************************
Chris Andrew, CCNA
chrisac@gmx.co.uk
************************
 
I setup all of that and when I connect the server on the DMZ to the DMZ card using a crossover cable, I can't telnet into the PIX anymore from another telnet-enabled PC...it gives me "connection timed out" until I set things back to the old configuration...

I can ping the DMZ card from the DMZ server, but it's seems as though the PIX doesn't like the configuration...

Having limited time during the day to bring the server down, I'm running out of options...

Being new to firewalls, thanks for your patience...
 
Could you provide your PIX config (edited of course)??

By the way, what type of server are you putting in the DMZ?

Chris.
************************
Chris Andrew, CCNA
chrisac@gmx.co.uk
************************
 
I'm putting an NT4 server to use as an SMTP server.

My configuration currently is without the DMZ setup commands that I have tried recently. I can tell you what I'm adding to try to make use of the DMZ.

This link will show you what I'm trying to setup except I'm using access-list commands instead of conduit commands. I'm essentially trying to move an NT4 SMTP server from the inside network to the DMZ network but still be able to use the SMTP server for interoffice mail as well as Internet email. Is this possible?

Thanks
 
Yes, it's possible! Everything is possible!

Your DMZ will have a security level inbetween that of the inside and outside interfaces. So, your mail server will be able to initiate connections to the outside to send mail and your inside users will be able to initiate connections to the mail server to send mail. But ... in order to have remote mail servers send mail to your mail server to will have to create a conduit or an access-list to allow port 25 through to your DMZ. Don't allow any connections from the DMZ to the inside!!

If you could supply a config I'll have a look and try to help!

Chris.


************************
Chris Andrew, CCNA
chrisac@gmx.co.uk
************************
 
ok...

thanks

---------------------------------------
PIX Version 5.2(6)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security50
enable password
passwd
hostname PIX
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
names
access-list acl_inside permit ip host 192.168.x.x any
access-list acl_inside permit ip host 192.168.x.x any
access-list acl_inside permit ip host 192.168.x.x any
access-list acl_inside permit ip host 192.168.x.x any
access-list acl_inside permit ip host 192.168.x.x any
access-list acl_inside permit ip host 192.168.x.x any
access-list acl_inside permit tcp host 192.168.x.x any eq www
access-list acl_inside permit tcp host 192.168.x.x any eq www
access-list acl_inside permit tcp host 192.168.x.x any eq www
access-list acl_inside permit tcp host 192.168.x.x any eq www
access-list acl_inside permit tcp host 192.168.x.x any eq www
access-list acl_inside permit tcp host 192.168.x.x any eq www
access-list acl_inside permit tcp host 192.168.x.x any eq 443
access-list acl_inside permit tcp host 192.168.x.x any eq 443
access-list acl_inside permit tcp host 192.168.x.x any eq 443
access-list acl_inside permit tcp host 192.168.x.x any eq www
access-list acl_inside permit tcp host 192.168.x.x any eq 443
access-list acl_inside permit tcp host 192.168.x.x any eq www
access-list acl_inside permit tcp host 192.168.x.x any eq 443
access-list acl_inside permit ip host 192.168.x.x any
access-list acl_inside permit tcp host 192.168.x.x any eq 443
access-list acl_inside permit tcp host 192.168.x.x any eq 443
access-list acl_inside permit tcp host 192.168.x.x any eq 443
access-list acl_inside deny ip host 192.168.x.x any
access-list acl_inside deny ip host 192.168.x.x any
access-list acl_inside deny ip host 192.168.x.x any
access-list acl_inside deny ip host 192.168.x.x any
access-list acl_inside deny ip host 192.168.x.x any
access-list acl_inside deny ip host 192.168.x.x any
access-list acl_inside deny ip host 192.168.x.x any
access-list acl_inside deny ip host 192.168.x.x any
access-list acl_outside permit tcp any host x.x.x.x eq smtp
pager lines 64
logging on
no logging timestamp
no logging standby
no logging console
no logging monitor
no logging buffered
logging trap debugging
no logging history
logging facility 23
logging queue 512
logging host inside 192.168.x.x
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto
mtu outside 1500
mtu inside 1500
mtu dmz 1500
ip address outside x.x.x.x 255.255.255.192
ip address inside 192.168.x.x 255.255.255.0
ip address dmz 192.168.x.x 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
arp timeout 14400
global (outside) 1 x.x.x.x
nat (inside) 1 192.168.x.x 255.255.255.0 0 0
nat (inside) 1 192.168.x.x 255.255.255.0 0 0
nat (inside) 1 192.168.x.x 255.255.255.0 0 0
nat (inside) 1 192.168.x.x 255.255.0.0 0 0
static (inside,outside) x.x.x.x 192.168.x.x netmask 255.255.255.255 0 0
access-group acl_outside in interface outside
access-group acl_inside in interface inside
route outside 0.0.0.0 0.0.0.0 x.x.x.x 1
route inside 192.168.0.0 255.255.0.0 192.168.x.x 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 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
no sysopt route dnat
isakmp identity hostname
telnet 192.168.x.x 255.255.255.255 inside
telnet timeout 5
ssh timeout 5
terminal width 132
Cryptochecksum:
 
Could you explain what you are trying to do with that access-list? It looks a bit mad to me!! Are you only letting specific users on the inside out on specific services? Why?

Chris.
************************
Chris Andrew, CCNA
chrisac@gmx.co.uk
************************
 
We have some hosts that are unrestricted and the others are restricted to 443 traffic for now. It's just the way I have to set it up for the time being.

By the way, did you check out the link

What's confusing me is that in this sample configuration, they use a "static (inside,DMZ)" instead of a nat command.

I know the "static (dmz,outside)" and access-list commands to enter for my DMZ, but what's throwing me off is the route, static, and nat commands that I should enter. Also, the PIX telnet problem when I try to bring up the server on the DMZ.

Thanks for taking the time to help...
 
The static (inside, dmz) option used in the configuration example is so that inside users can still go on to the DMZ with their own IP addresses! I wouldn't do it this way. If the internal network has an IP scheme of 192.168.1.0 for example, then I would assign a different IP scheme for the DMZ, like a 172.16 or 192.168.50.0 or whatever!! You would then do NAT for all inside users going to the outside and for all inside users going to the DMZ. The mail server in the DMZ would have a static map to the IP address in the MX record for the domain.

What exactly is your telnet problem? Is it just telnet into the PIX from the inside interface? Having a server on the DMZ shouldn't affect telnet into the PIX from the inside!

Off to watch the Simpsons now! I'll have a closer look at your config later!!

DOH!!!

Chris.
************************
Chris Andrew, CCNA
chrisac@gmx.co.uk
************************
 
What access-list commands should I setup to allow only smtp from the outside to the dmz and pretty much everything from the inside to the dmz?

thanks
 
On the outside interface of the PIX let mail through with something like:

access-list mail_in permit tcp any host mailserver eq 25.

Your static NAT statement would then take care of routing the packets to the real IP address on the DMZ.

Your inside users will be able to access the DMZ by default unless you block them. Higher security to lower security!!

Chris.
************************
Chris Andrew, CCNA
chrisac@gmx.co.uk
************************
 
For some reason, as soon as I plug in the crossover cable for the DMZ server (with or without the DMZ settings in the configuration), the PIX times out when I try to telnet into it from another telnet-enabled PC. But when I plug back in the old connection, I can telnet in. It's like the new connection locks up the firewall or something....any ideas?

Thanks
 
Okay, so when you put your mail server in the DMZ you can't get to it from the inside network?? Is this what you're saying?

Looking at your configuration it seems that you haven't put in a NAT statement so that your inside users can go to the DMZ. This is why a telnet session from a client PC is timeing out at the PIX. Internal users are not able to get to the DMZ without a NAT statement.

You need to add a global (dmz) statement with an address range or one IP address on the DMZ IP scheme. Then your inside users IP addresses will be NATed when going on to the DMZ.

Chris.


************************
Chris Andrew, CCNA
chrisac@gmx.co.uk
************************
 
If I plug in the dmz server crossover cable to the pix dmz card, I can no longer telnet into the pix from a certain PC that works fine otherwise. Strange!

For now, I will have to use the static (inside,dmz) instead of nat because certain network issues prevent me from changing the current ip address of the DMZ server...

What access-list commands should be used in conjunction with the static (inside,dmz) statement to allow all traffic from the inside to the dmz?

Thanks
 

You don't need access-lists to let the inside into the DMZ. The inside network has a higher security level than the DMZ so these connections are allowed! Higher to lower ... that's how ASA works! However, you do need a NAT statement for your clients on the DMZ that they will be NATed to when they try to connect. You don't need to change the IP address of the server on the DMZ at all! You only do static translations when you want a global IP to be translated to an internal IP. In this case, when going from the inside network to the DMZ you're using private IP's all the way. Just allow the inside network to be NATed on the DMZ! That's it!! ************************
Chris Andrew, CCNA
chrisac@gmx.co.uk
************************
 
ok...I'm just getting more confused...please bear with me...

So, In no case do I need to change the IP address of the DMZ server if I use either nat or static?

Can you list out the steps I need to take for both dmz options?
1. static (inside,dmz)

2. nat (dmz) and global (dmz)



Thanks for your fast responses!
 
Okay, so you've got a DMZ with a mail server on it! The outside world needs to be able to get to your mail server on the global address aaa.bbb.ccc.ddd! Your inside The actual IP address of the server is, for example 172.16.2.100. This is the address that the static NAT statement will map to when the outside world connects to the mail server on aaa.bbb.ccc.ddd.

Also, your inside users need to be able to get to the mail server on the DMZ. They will use the private address 172.16.2.100.

For the outside world to be able to access the mail server we need to map the outside IP to the actual IP:

static (dmz, outside) aaa.bbb.ccc.ddd 172.16.2.100 netmask 255.255.255.0 0 0

The outside world also needs an access-list or conduit to allow it to access the DMZ. This is because the outside interface (the internet) has a lower security level (0) than the DMZ (1 to 99 .. probably something like 50).

access-list mail_in permit tcp any host aaa.bbb.ccc.ddd eq 25

This allows anyone on the internet access to the mail server on port 25 only. It would be applied to the outside interface:

access-group mail_in in interface outside

That takes care of the outside to the mail server. But, what about the inside connecting to the mail server?? Well, no special security measures are needed as the inside network is security 100, higher than the DMZ, so connections are allowed by ASA. But, if the inside network is on the IP range 192.168.1.0 /24 then all traffic going to the 172.16.2.0 /24 IP range will need to be NATed on the DMZ.

For this we could either have a pool of addresses or we could just use one address and use PAT. Let's say that all 192.168.1.x addresses will go to the DMZ with the IP address 172.16.2.10 (with a different port number .. Port Address Translation!!). The inside network is already subject to NAT with a statement such as:

nat (inside)1 192.168.1.0 255.255.255.0 0 0

To have this address range translated on the DMZ, we use:

global (dmz) 1 172.16.2.10 netmask 255.255.255.0

We could also allow the inside network out to the internet on the address of the outside interface:

global (outside) 1 interface

So, the nat statement defines what IP's will be subject to NAT and the global statement says what these IP's will be translated to!

I hope that this makes it a bit clearer!!

Chris.
************************
Chris Andrew, CCNA
chrisac@gmx.co.uk
************************
 
ok...that makes perfect sense...thanks

but what if the internal network is 192.168.1.0/24 and the ip address of the dmz server is within that subnet and can't be changed right now....what are my options now for dmz access from the inside? I'm o.k. on the outside part.

Thanks again.
 
You really need the DMZ on a different IP range to the inside network! By it's nature a DMZ is a separate network. If you rey to connect to an IP address on your network then it won't go via the gateway. Separate networks require separate IP ranges or subnets.

If you can't change the IP address at the moment then leave it on the inside until you can set up a DMZ properly. When you are ready to set up the DMZ then know what to do!

Chris.
************************
Chris Andrew, CCNA
chrisac@gmx.co.uk
************************
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top