Transparency using Proxy ARP instead of subnetting (10.x)

Security Gateway Articles and How to's
Posts: 85
Joined: 18 Apr 2008, 10:46
Location: Clavister HQ - Örnsköldsvik

Transparency using Proxy ARP instead of subnetting (10.x)

Post by jono » 22 Apr 2008, 16:59

This article applies to:
  • Clavister CorePlus 8.x, 9.x
  • Clavister cOS Core 10.x
We demonstrate here how to setup a Security Gateway using Proxy ARP to split a network of public IP addresses so that it may be used on several interfaces without normal subnetting. This allows you to use public IP addresses on your public servers and avoid static address translation (SAT/NAT) completely.

  • You can use public IP addresses on the machines on the dmz network even if your ISP has only given you a single public IP network.
  • No need to reconfigure your ISP router -- your ISP does not need to get involved.
  • You will save a lot of IP addresses that would have been wasted in a subnetting scenario.
  • The IP rules decide if certain traffic should be allowed, there are no security issues.
  • Proxy ARP is easier to use than manual ARP publishing of individual IP addresses.
  • There is no need to use SAT/Allow combinations for incoming connections, or SAT/NAT combinations for connections from the internal network, or using NAT for outgoing traffic your servers. You only need Allow rules in each direction.
  • In summary: your configuration becomes much more manageable.
Topics covered in this document
  • Host & Networks in this scenario
  • Routing table
  • Rules
Hosts and networks in this scenario
How_to_easily_split_your_public_IP_network.jpg (36.46 KiB) Viewed 4021 times
Nearly all addresses are moved from the external side to the DMZ side of the Security Gateway. The DNS servers (two IP addresses) are moved to a fourth interface, "dmz2".

Also note how the Security Gateway uses the same IP address on the "ext", "dmz" and "dmz2" interfaces. This works perfectly with Clavister Security Gateway.

Routing table
In the routes section, we simply point out which way the Security Gateway should go to get to addresses in our split-up network.

To get to the default gateway, "gw-world", we go through the "ext" interface.
To get to our DNS servers, we go through the "dmz2" interface.
To get to the rest of the network, we go through the "dmz" interface.

We then enable full proxy arp on all these routes. This means that:
  • The default gateway (gw-world) can ARP resolve all addresses
  • All hosts on dmz and dmz2 can use (gw-world) as gateway
  • All hosts on dmz and dmz2 can resolve eachother (though, of course, the Security Gateway ruleset still controls how they can communicate)
How_to_easily_split_your_public_IP_network2.jpg (16.63 KiB) Viewed 4022 times
Note how we do not care about route ordering. The Security Gateway will always choose the smallest matching route, so when it looks up (DNS_public), it will find the route through "dmz2", even though the "dmznet through the dmz interface" route is listed higher up.

For those that have a deeper understanding of ARP: don't worry, even though we've told the Security Gateway to publish the address on "ALL" interfaces, it will in fact never publish the address on the interface where the host actually lives, as that would introduce address conflicts.

This rulesheet shows only the rules regarding the DMZ interfaces. It is just an example to show how simple your rules can be when using Proxy ARP and public IP adresses instead of SAT and NAT. You'll probably need some rules to let the internal network administer the DMZ hosts.
How_to_easily_split_your_public_IP_network3.jpg (83.76 KiB) Viewed 4019 times
This ruleset concentrates on what is really important: your security policy, without having to worry about address translation details.