Cisco 1721 DHCP and NAT

I am charged with servicing a wireless network  where there was once a Nomadix HSG handling DHCP. The Nomadix took a dump, leaving the network unstable, DHCP was not releasing, endless nighmares with the Nomadix. They decided to not spend any time trying to upgrade S/W on the Nomadix and just use the router... entirely their call.

So, now the network looks like this:
CSU/DSU Serial Int. --> Cisco 1721 -->Switch--> VDSL to two disparate locations--->(to two segments with firetide mesh radios directional ant.) --->7 Cisco Aironet (this is an over simplification since my question is based on DHCP and the router-- this is just background info. also the APs are working correctly and have static IPs)

Right now the 1721 is doing the the DHCP but only for the pool of public addresses we have. (/25 network 128) I want to have a private network so that we can increase the DHCP pool to about 254 and still have the public IPs to give out if needed for a approx. total of 380 IPs. The 1721 has an expansion slot avail for another eth interface, and I have one at my disposal, but do I need to do that?
Can I turn on NAT and also have the public IP range on the same interface somehow using the same DHCP server thats built-in to the 1721?

I also have a follow up question about ACL changes now that the Nomadix is gone, and I can post the conf. here is someone is willing to take a look.

Related post:

This may be a simple answer but I am learning and know very little about routers. Thanks.
Who is Participating?
gavinmacConnect With a Mentor Commented:
No problem!

Well the problem is it would be very random. Sometimes a user would get a public, sometimes a private. It's really just asking for trouble. The best you could do in this instance would be to provide one segment (You said you had two VDSL links to each segment) with public and the other with private, but this isn't good for the business of a Hotel. You really need to provision everyone with the same level of service or they will complain.

You will need to either order more public IP's, or change everything over to private and use global address pools and NAT. With this many public IP's you can disable PAT which will improve the reliability of VPN's.

Here is an example access-list but by no means will work for you. Just an example.

access-list 115 permit tcp any any eq 80    <-- Web browsing
access-list 115 permit tcp any any eq 443 <-- SSL web browsing
access-list 115 permit tcp any any eq 1723 <-- PPTP VPN
access-list 115 permit gre any any <--- GRE required by some VPN's
access-list 115 permit tcp any any eq 21 <--- Allow FTP
access-list 115 deny ip any any   <-- block anything that isn't listed above

Of course, this is secure, but limiting. You can never guess what your residents will require, so if the customer network is in no way connected to your internal corporate network, you could probably quite safely have no access-lists at all, and protect your clients using NAT (so external hackers can't traverse your router and get to their computers)

NAT is the safest, cheapest, most flexible way of achieving what you need. Using the network is fine. If you don't use PAT (i.e. the 'overload' statement in the NAT rules) then VPN's should work a little more reliably.

If you're really concerned about VPN abilties, you will need to extend/change your Public Assigned range with a /23 or /24 - depending on your needs.
adamwitherspoonAuthor Commented:
Here is conf file, I "privatized' some of it for security. I posted it as reference -- hope this helps. Please note that the line with DISABLED in front is in fact not there and the default lease has been changed to four hours as well.

show run
Building configuration...

Current configuration : 1681 bytes
version 12.3
service timestamps debug datetime msec
service timestamps log datetime
no service password-encryption
hostname xxxxxxxxxx
enable password xxxxxxxxxxx
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
ip cef
ip dhcp excluded-address xx.xx.211.129 xx.xx.211.139
ip dhcp pool pool1
   network xx.xx.211.128
   default-router xx.xx.211.129
   dns-server xx.xx.209.99 xx.xx.209.100
   domain-name xxxxxxxxxxxxx
ip dhcp-server xx.xx.211.129
no ftp-server write-enable
interface FastEthernet0
 ip address xx.xx.211.129
 DISABLED ip access-group 115 in
!(disabled to allow DHCP until we figured out how to add ACL to allow DHCP traffic)
 speed 100
interface Serial0
 no ip address
 encapsulation frame-relay IETF
 no fair-queue
 frame-relay lmi-type ansi
interface Serial0.1 point-to-point
ip address xx.xx.209.138
frame-relay interface-dlci 16  
ip classless
ip route xx.xx.209.137
no ip http server
access-list 115 deny   icmp any any redirect
access-list 115 deny   ip any
access-list 115 deny   ip any
access-list 115 deny   ip host any
access-list 115 deny   tcp any any eq 135
access-list 115 deny   udp any any eq 135
access-list 115 deny   udp any any eq netbios-ns
access-list 115 deny   udp any any eq netbios-dgm
access-list 115 deny   tcp any any eq 139
access-list 115 deny   udp any any eq netbios-ss
access-list 115 deny   tcp any any eq 445
access-list 115 deny   tcp any any eq 593
access-list 115 permit ip any any
line con 0
line aux 0
line vty 0 4
 password xxxxxxx
It's probably not a good idea to mix and match two seperate subnets (/25 Public and /24 private) on the same broadcast domain. Your best bet (without really knowing your security policies, and the applications in use on the network, etc.) is to actually assign ONLY private IP's to all the nodes behind the 1721 and use NAT Translations to allow a large group of private IP's to share a smaller group of public IP's.

If you want to use both, you'll need to use VLANs, 802.11x authentication (or similar, e.g. PPPoE), or insert that extra Ethernet module, so you can choose which nodes get the private addresses and which get the publics.

Is there any reason that nodes need Public IP's assigned directly to them?
Cloud Class® Course: CompTIA Cloud+

The CompTIA Cloud+ Basic training course will teach you about cloud concepts and models, data storage, networking, and network infrastructure.

Also your access-list isn't really security minded. It should follow this basic flow:

permit something
permit somethingelse
permit (so on, so on)
deny anything else not listed above (the 'catch all' - 'deny ip any any')

Yours seems to be the reverse, whereby you are selectively denying traffic. This increases the risk of security holes in the lists.

Of course, you may have a specific reason for having your access-lists in reverse. All depends on exactly what applications the network is used for.
adamwitherspoonAuthor Commented:
Well the idea was that certain users on-site will use the public IPs to connect via VPNs or have some other need to use a public IP. I scoffed to myself when I heard that, because it shouldn't make a huge difference really.

There is a bit of reluctance on the clients part to give up the public IPs and I am not sure why.

It is a basic network really, I was thinking I would do with NAT what we can't do with our public range:
510 available IPs and I could limit the number of DHCP address  to 300 or so in the pool.

I just wish there was a way to do both on one have it work well without security issues.
adamwitherspoonAuthor Commented:
I think they are that way due to the Nomadix being there in the past... if you could suggest a better ACL I would be most appreciative.
adamwitherspoonAuthor Commented:
Thanks so much for your replies!!!!

following this statement:

If you want to use both, you'll need to use VLANs, 802.11x authentication (or similar, e.g. PPPoE), or insert that extra Ethernet module, so you can choose which nodes get the private addresses and which get the publics.

If I had the extra module, and had it installed and working, how would this scenario work out? Does this mean I can't have both on the same network (forgive my ignorance) and that I wouldn't be able to serve up private IPs on DHCP and still be able to give out static IPs on the same network?

Also, you could use PPPoE and not have any IP's on the Ethernet layer. This allows you to assign usernames/passwords and choose which customers will get public and which will get private. PPP also allows you to account for the usage of each user very accurately, so often is used in a hotel setting.

This fixes your 'available IP' problem as well. No DHCP - as soon as someone disconnects, the IP is free'd up and ready for the next person. More secure as well if you are sharing your corporate/guest networks.

Almost all OS's support PPPoE connections by default, but does involve some configuration by your customers. It's pretty easy to have some lamenated instructions stuck to the door of each room.
Also, you can use sub-interfaces to have two seperate subnets on the same physical segment. I'm definitely not recommending this though.
adamwitherspoonAuthor Commented:
Thanks for your determined and thorough answer!
I appreciate it greatly.
adamwitherspoonAuthor Commented:
Awesome, thanks so much for the help!
No problems, anytime! Good luck with it all!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.