Which is better - static route or NAT?

We have 3 routable IPs from COX for our business line coming through an

1811 router. Call them 2.2.2.a ,2.2.2.b, and 2.2.2.c

The router has 2.2.2.a assigned to its FE0 interface and is connected to the cable modem. There are two internal servers which are supposed to be accessible via

2.2.2.b and 2.2.2.c from the internet. Right now, we have static NAT set up for those two systems and are using 10.0.0.a and 10.0.2.b for their internal side. That works well, for the most part. The problem is when we have other systems on the internal network trying to access these servers via their public addresses.

Would it work better (or at all) if I simply set up static routes for

2.2.2.b and 2.2.2.c and forward them out the vlan0 interface (10.0.0.c)? If so, what changes would have to be made on the servers other than setting a NIC's IP to the appropriate external address for each server? Would the gateway for the servers remain 10.0.0.c or would I have to do something else?
Reply to
bthetford
Loading thread data ...

Are these servers hosted in a firewall DMZ?

Reply to
Rohan

The firewall is very unrestrictive, right now, anyway, but yes they are in DMZ.

Reply to
bthetford

I suppose if you have a default route pointing to the inside interface of the firewall you should be able to NAT them to using the Public address when they cross Internal to DMZ.

Reply to
Rohan

I think NAT is better

Network solution for tomorrow. LinkWaves Corp

29980 Technology Drive, Suite 6 Murrieta, CA 92563 http://www.l> I suppose if you have a default route pointing to the inside interface of
Reply to
ciscoseller

What do I do to fix the issue of accessing external IPs of those servers from VLAN1, then, if I use NAT?

Reply to
bthetford

I'm not quite sure I follow. You mean the servers use their public addresses on their NICs and their default route is the VLAN1 interface? Do I even still need NAT, in that case?

Also, the servers can act as the NAT gateways for the internal network, if that makes the router setup easier. I'd prefer not to do that, but it is doable. I'm just not so sure how the router gets set up, in that case.

Reply to
bthetford

Also, if an additional VLAN would make anything easier, that's doable too. The servers both have spare NICs sitting in them just waiting to be used and cabling is certainly not a problem.

The current setup is WAN --- 1811 --- L2 Switch --- LAN

A thought I had was putting the servers' public IPs on a separate VLAN and running that VLAN to their other NICs and then using a static route on the router to forward packets out that VLAN.

The internal network would then be on a separate VLAN and would use dynamic NAT for internet access.

Would this take care of the address translation issue?

Reply to
bthetford

I am not sure how you layed out your environment

Is it : INTERNET ---L3--FW-- L3---INTERNAL? | DMZ

>
Reply to
Rohan

I am not sure how you layed out your environment

Is it : INTERNET ---L3--FW-- L3---INTERNAL? | DMZ

Reply to
Rohan

Yes, almost.

INTERNET --- (L3---FW---L3) --- L2 --- INTERNAL | DMZ

That's more how it looks, in my mind. In words, the 1811 is hooked to the internet on FE0. The firewall is ACL only and is on FE0 inbound. It makes the servers be in DMZ. VLAN1 is configured to use 10.0.3.1 and is on FE9. FE9 connects to our L2 switch. L2 switch connects to various hosts, including the servers.

Reply to
bthetford

How about a bridge? Would it work if I created a new VLAN and bridged it with the external subnet? The servers would then have their additional NICs attached to that vlan and would then use the ISP's router as a gateway.

Reply to
bthetford

Why isn't the DMZ in FW? Unless you are telling me that (L3---FW---L3) is the 1811?

Reply to
Rohan

Yes L3--FW--L3 is the 1811

I apologize for any confusing drawings on my part. I'm not so great at representing networks in ASCII. ;)

Reply to
bthetford

Well should be able to NAT between Interfaces.

Reply to
Rohan

Not sure what you mean there.

Reply to
bthetford

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.