Overview

However, situations may exist where a network running Ethernet is separated into two parts with a routing device such as a Clavister NetShield Firewall in between. In such a case, cOS Stream itself can respond to ARP requests directed to the network on the other side of the Clavister NetShield Firewall using the feature known as Proxy ARP.

Splitting an Ethernet network into distinct parts so that traffic between them can be controlled is a common usage of the proxy ARP feature. cOS Stream rule sets can then be used to impose security policies on the traffic passing between the different network parts.

A Typical Scenario

A host behind the G1 network (192.168.1.0/24) might send an ARP request to find out the MAC address for the IP address of one of the servers now situated behind another interface (e.g. G2). With the proxy ARP feature configured, cOS Stream responds to this ARP request instead of the servers. cOS Stream sends its own MAC address in response, pretending to be the target server. After receiving the reply, the host then sends data directly to cOS Stream which forwards the data to the target server(s) located behind the other interface (G2). In the process, cOS Stream checks the traffic against the configured rule sets. The entire scenario is illustrated below.

Figure 6.3. A Proxy ARP Example

Setting Up Proxy ARP

The network 192.168.1.0/24 is connected to the interface G1 and there are two servers that have been moved to be located behind the G2 interface. There will be a route configured that says that the network 192.168.1.0/24 can be found on G1. This might be called route_1.

For route_1 it is possible to specify the option that this network should be proxy ARP'ed on interface G2. Now, any ARP request issued by hosts in the 192.168.1.0/24 network connected to G1 looking for the MAC address of Server-1 or Server-2 will get a positive response from cOS Stream. In other words, cOS Stream will pretend that the MAC address of Server-1 and Server-2 are located on G1 and will pick up and forward data traffic to G2.

In the same way, Server-1 and Server-2 should be published on the interface G1 so that there is a mirroring of routes and ARP proxy publishing. Hosts behind G1 will believe that the servers are located in its local network domain and the same for the servers, meaning the servers believe the clients are part of it's own local network behind G2, accomplishing a semi-transparent mode behavior.

In this way there is complete separation of the sub-networks but the hosts are unaware of this.

Keep in mind that if the host tries to access IP addresses outside of the local network then this request will be sent to the gateway configured for that host, in the scenario illustrated the gateway would be the IP address configured on interface G1 and G2 (192.168.1.1).

	Not all interfaces can make use of Proxy ARP
	It is only possible to have Proxy ARP functioning for Ethernet and VLAN interfaces. Proxy ARP is not relevant for other types of cOS Stream interfaces since ARP is not involved.

System:/> cc RoutingTable main

System:/RoutingTable/main> add Route Interface=G1
				     Network=192.168.1.0/24
				     ProxyARPInterfaces=G2

System:/RoutingTable/main> add Route Interface=G2
				     Network=192.168.1.11
				     ProxyARPInterfaces=G1

System:/RoutingTable/main> add	Route Interface=G2
				     Network=192.168.1.22
				     ProxyARPInterfaces=G1

System:/RoutingTable/main> cc
System:/>