Public network transparency using cOS Core Proxy ARP instead of subnetting

Last modified on 18 Apr, 2023. Revision 15
This article describes how to use Proxy ARP in cOS Core to dynamically perform automatic ARP handling between interfaces in a semi-transparent mode configuration setup.
Up to date for
cOS Core 14.00.09
Supported since
cOS Core 8.90.xx
Status OK
Peter Nilsson


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.


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.


  • 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:

Public_GroupWebserver, Fileserver

Nearly all 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:

InterfaceNetworkGatewayLocal IPProxy ARP






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 ( 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 ( 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 ( 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 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 addresses
      • All hosts on VLAN-10, VLAN-20 and Lan can use (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 (, 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:

IndexNameActionSource interfaceSource NetworkDestination InterfaceDestination NetworkServiceOptionsNotes

Allow everyone to access the webserver
Give internet access to the webserver (if needed)

Allow everyone to access the public file server
Give internet access to the fileserver (if needed)
Give unrestricted internet access to the Lab Machine

Give default internet access to standard users in the Lannet range.

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

Setup of a Layer-3 bridge over IPsec in cOS Core
12 Apr, 2023 core proxyarp arp ipsec routing
cOS Core IKEv2 split tunneling with Windows and local user database.
28 Mar, 2023 ikev2 windows vpn routing splittunneling
Problem with auto-created Core routes
22 Mar, 2021 core ipsec routing
Setting up OSPF with IPsec in cOS Core
16 Apr, 2024 core routing ospf ipsec
Using /31 network masks in cOS Core (RFC-3021)
1 Jun, 2022 core routing management
Using Multicast DNS with cOS Core
24 May, 2021 core howto mdns multicast transparentmode airprint igmp dns
The meaning of the Default_Access_Rule log entry
7 Nov, 2022 core arp log routing
Transparent mode & L2TPv3 unavailable in cOS Core HA clusters
17 Feb, 2023 core ha cluster transparentmode l2tpv3
Troubleshooting cOS Core rules/routes with ping simulation
17 Mar, 2023 core routing rules ping icmp cli
Is Statless (FwdFast) faster than a normal IP policy?
27 Jan, 2021 core stateless routing brokenlink
Route failover with IPsec tunnels in cOS Core
13 Feb, 2023 ipsec core routing failover