View Single Post
  #15 (permalink)  
Old 2006-10-09
northlandboy northlandboy is offline
Senior Member
 
Join Date: 2006-07-28
Location: New Zealand
Posts: 857
Rep Power: 3
northlandboy has an average reputation (10+)
Default Re: How to view the automatic proxy arps NGX

OK, let's assume you've got a very simple firewall setup, with 3 connections - internal network, DMZ, external interface.

You have some say a mail server sitting in the DMZ. Both the DMZ and the internal network are privately addressed. You want to make the mail server publicly visible. Historically, you would have had a public network - let's say a /24 - on your external interface. You would have assigned an address from your public range to the mail server NAT.

Your problem then is that you need to get the packets addressed to the mail server NAT to be sent to the firewall's MAC address, so that it will process and NAT the packets. So to do that, you put a proxy ARP entry on the firewall, telling it to proxy ARP for the firewall. If you're particularly fond of doing things the hard way, you'll also have translate on client side unchecked, so you need to go and add a /32 route also.

That is all a lot of manual work. Also think about how you're going to deal with expansion - what if you use up all of that /24? Some people do even more crazy stuff like adding a secondary public interface to the firewall, and then doing proxy ARP for that.

Consider instead a different scenario. This time, you have a very small (say /29) public or private range between the firewall and the upstream router. Public if you need to do any VPNs, private otherwise. You still have the same /24 assigned for use as NAT addresses. This time, you add a route on the upstream router, telling it that in order to get to that /24, go via the firewall.

Now when the upstream router receives packets for your mail server IP, it knows it needs to route them to the firewall. It will set the firewall MAC as the destination MAC on the frames, and they will be forwarded correctly to the firewall. The firewall will process the packets, realise it needs to NAT it, do the NAT, and forward the frames to the destination.

This is a much cleaner way of doing it. Your NAT range doesn't physically exist anywhere. You can now use every address in that range. Far less manual work is required. If you need to expand the range, it's easy to just add a route to the upstream router for your new network.

The first method is a bit of a historical thing, but if I was setting up any new network now, I would have to have an extremely good reason for designing it in a way that required proxy ARP. Obviously there are some legacy systems where you can't easily move away from it, but you should not be deploying new systems requiring it.

As a side note, in the first case, rather than adding a proxy ARP to the firewall, you could have just added a /32 route to the upstream router - it would achieve the same outcome, of getting the router to forward those frames to the firewalls MAC address.
Reply With Quote