Best Practice for assigning IP address of inward-facing router port?

Incident response
Intrusion management
Network security
I have a very standard setup for my company - a Cisco router facing the Internet, connected to a Firewall appliance with 2 zones, one a DMZ and the other an internal network. My question is what IP address do I give my inner facing port on my router - a routable or non-routable one? If routable, I can telnet in to it from the public Internet. However, I have read of best practices that say you should never do this. I will have a VPN solution so I can VPN into my private network and telnet from there. Secondly, assuming I choose non-routable, I have two zones in my network, one my office LAN and one my DMZ, each with a different IP block. Should I use one of those two IP blocks for the internal port or should I pick a third, completely different IP block? Is there any reason not to do this?

Answer Wiki

Thanks. We'll let you know when a new response is added.

I’d suggest using two different private addresses like 192.168.x.y. You can always use NAT or PAT to connect internal private addresses to external public addresses for things like SMTP and HTTP.

If you use a public IP for your internal LAN you run the risk of colliding with an external address and not being able to easily access the external hosts because your LAN hosts and routers think they’re on the local LAN.

Discuss This Question: 4  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Paul144hart
    Your internal network (office) should be a non-routable address (one you are in control, two its safer). The Firewall with do NAT/PAT. The DMZ will have to be routable (in the internet address space that your company owns/leases), if you want anyone to access a web server, etc in the DMZ. This is not a hard requirement on the machines in the DMZ, as the cisco router can NAT to the DMZ. The firewall will have IP(s) in that space as well. Yes, the networks should be differnet subnets - routing will be clearer to you and you want to make it clear they are separate networks, and also not supernetted. If you use the router to NAT, then I would suggest a class C private network for DMZ and a Class A or B for the office. The DMZ should be the only machines that can be accessed from the public internet. The only way to access the office net should be from the DMZ. It sounds like the firewall is setup as a two arm box, so the router connects the public internet to the DMZ, which is one arm, and the other arm is the office network. The VPN box would be on the DMZ and once logged in you should allow you to access your office. -Paul
    0 pointsBadges:
  • Larrythethird
    You can even make your internal network a little more secure by using a proxy server so no user actually connects to the internet directly. Only the servers that absolutely HAVE to be on the internet, web servers, email servers,and CRM front ends (and they still reside between the firewalls in the DMZ) and the internet router are the only systems the should ever need internet routable numbers. We use an internal and an external firewall with the DMZ in the middle, limiting access both from the outside in, and access from the inside out. No real data system actually resides in the DMZ, only systems that are allowed to access data on the internal servers.
    0 pointsBadges:
  • Astronomer
    In general I agree with Paul. If the DMZ is between the router and the firewall then you should be doing static NATing with the router for the DMZ systems that have private addresses but public IPs from the internet. Go with private whenever you can. It's safer. In this case, the internal router port would have an address in your private DMZ range. If by two zones you mean the DMZ and the private net are behind the firewall, (a better setup if you aren't using your router as a screening firewall for the DMZ), you can use public IPs between the router and firewall, but why waste public IPs? Unless you forsee needing external help debugging connectivity, there is no good reason to use up public addresses for infrastructure. This would be a third private network, seperate form the DMZ and internal nets. Use class C. In any case, I recommend a private IP behind the router and do your NAT there. Part of your question implies you may not have a solid understanding of routers. Remember the cisco and firewall devices are both routers despite what cisco documentation may say, (unless you had a firewall built into a bridge). Each port of a router is on a different network. If your router is connected to your DMZ, that port has to have a DMZ address. If the router isn't connected directly to the DMZ or internal net, then its address can't be from either of these nets. Another result of this is the need to define static routes once the architecture is in place. You will have to tell the firewall how to reach the internet, (default route), and tell the router how to reach the internal net. rt
    15 pointsBadges:
  • petkoa
    Hi, It seems to me that one of the issues in the question was not clarifed: > what IP address do I give my inner facing port > on my router - a routable or non-routable one? > If routable, I can telnet in to it from the > public Internet In fact, you do not telnet the interface, BUT THE HOST (router) FROM one of it's interfaces: the point is that telnet or whatever incoming connections should not be allowed when coming on external interface(s). "In the wild" there might be situations (and I'm sure, there are) when your router has no public IP at all - it's sitting on the private network of the ISP and ISP routers deal with NAT. Nevertheless, you'll not want telnet to your router from the hosts on ISP private network. BR, Petko
    3,140 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: