Overview

This article will describe how to set up cOS Core Proxy ARP to split a network of public IP addresses so that it can be used on several cOS Core interfaces without subnetting. This will allow us to use public IP addresses on our public servers and avoid static address translation (SAT/NAT) completely. The idea is to allocate the entire public IP range to an interface located behind the firewall and then create single-host routes for the IP addresses that are to be allocated elsewhere.

The diagram below illustrates the example scenario this article’s setup will be based on. This is a scenario where we have received an entire /24 public network range from the ISP (with the exception being the default gateway IP). This would rarely be the case today given the shortage of public IPv4 addresses, but consider it an example of how Proxy ARP can be used to solve such a scenario in an effective way.

Benefits

Some of the benefits of using public IPs directly on equipment behind the firewall are the following:

• We can use public IP addresses on the computers on the Lan network, even if our ISP has only given you a single public IP network.
• No need to reconfigure the ISP router. Our ISP does not need to get involved.
• We will save a lot of IP addresses that would have been wasted in a sub-netting scenario. As an example, only one IP address needs to be assigned to the various interfaces in the firewall.
• The IP policies still decide what traffic should be allowed. There are no security issues.
• Proxy ARP is easier to use than manual ARP publishing of individual IP addresses (if more than one IP per interface).
• There is no need to use address translations, such as SAT, for incoming connections, or SAT/NAT combinations for connections from the internal network, or use NAT for outgoing traffic for our servers. We only need allowing IP rule set entries in each direction.

Limitations

• This is not a true transparent mode setup since, for example Global Broadcasts, will not be able to traverse the interfaces. So, for instance, trying to locate a host behind another interface using Samba/Windows share will not be possible unless you input the path directly.

Configuration steps

1. Address book setup

The cOS Core address book should be configured with the following addresses:

Nearly all 192.0.2.0/24 addresses are moved from the external side to the Lan side of the firewall. The Webserver and DNS servers are moved to be placed behind their own interfaces (VLAN-10 and VLAN-20).

Note that we allocate the same IP address to VLAN-10, VLAN-20 and the Lan interface. We will go into details about the reason for this later.

2. Routing table setup

The table below illustrates the setup of the main routing table:

So what does this actually do? Let’s break it down:

• The routes for the Webserver and Fileserver are single routes telling the firewall that e.g. the Webserver IP (192.0.2.3) is now routed behind the VLAN-10 interface. The routing principle is "narrowest route first" which means that this route will match before the Lannet (192.0.2.0/24) route as a single-route is smaller.
  • To get to the default gateway, "Wan_GW", we go through the "Wan" interface. Configuring it like this also enables all devices behind the firewall to use Wan_GW (192.0.2.1) as their default gateway, the Proxy ARP option will make the firewall respond to any ARP queries towards this IP.
  • To get to the Webserver or Fileserver servers, we go through the "VLAN-10" and/or "VLAN-20" interface.
  • To get to the rest of the 192.0.2.0/24 network, we go through the "Lan" interface.
• Proxy ARP is set to be "All" interfaces. This means that, regardless of interface, if someone makes an ARP query for e.g. the Webserver IP, the firewall would respond to this ARP request. If we want to add more interfaces in the future and want to restrict this slightly, the Proxy ARP can be configured to be VLAN-20, Lan and Wan, if we look at the Webserver route as an example. The interface(s) that must be included in Proxy ARP are the interface(s) we expect incoming ARP queries from, that are towards the IP address or network configured on the route.
  
  • Proxy ARP will NOT forward ARP queries on the interface the ARP query was received on, otherwise this would cause a big IP conflict if "All" is used. This is why it can be a big advantage in some scenarios to use "All", since if we add additional interfaces in the future, they will be included automatically.
  • To give further explanation, full proxy arp on all these routes means that:
    • The ISP (default gateway, Wan_GW) can ARP resolve all 192.0.2.0/24 addresses
    • All hosts on VLAN-10, VLAN-20 and Lan can use 192.0.2.1 (Wan_GW) as gateway
    • All hosts on VLAN-10, VLAN-20 and Lan can resolve each others addresses using ARP (though, of course, the cOS Core ruleset still controls how they can communicate).
• The same IP address is configured on all interfaces (192.0.2.2), this is needed in order for the firewall to perform ARP queries towards internal and external hosts. It will not cause an IP conflict as long as no network is interconnected on layer-2 somewhere (this would be a big problem not related to the firewall).

3. IP rule set setup

To configure the needed IP rule set entries in the main IP rule set is now straightforward. The table below lists example IP Policy entries:

In the table above, no address translation is needed (the options column is blank) since we are using public IP addresses on all devices and they can communicate with each other without any translation. Which service to allow in the outgoing direction would be up to the administrator. We used Any as the source interface for rule #1 and #3 but if we want to restrict this further we could create an interface group consisting of Wan, VLAN-10, VLAN-20 and Lan and use that instead as the source interface if we do not want to allow access to these servers by default for any new VLAN or interface added. There is however a big advantage in using Any in this case for that exact reason.

Related articles