In many of the previous chapters, we have covered the many of the key elements required to understand basic networking with linux. In this chapter, we will introduce a few new concepts, but will endeavor to put some of the ideas together to solve practical networking problems.

ARP flux. /proc/sys/net/ipv4/conf/all/hidden Nothing here for now. Refer to .

Media share; IP overlay; compare VLANS; consider bridging; consider migrating from one IP space to another (vrrpd, anybody?).

proxy ARP ARP, proxy ARP, proxy with arp Proxy ARP is a technique for splitting an IP network into two separate segments. Hosts on one segment can only reach hosts in the other segment through the router performing proxy ARP. If a router sits between two parts of an IP network and is not running bridging software, then routes to hosts in each segment and proxy ARP are required on the router to allow each half of the network to communicate with the other half. Occasionally, this technique is incorrectly called proxy ARP bridging. An Ethernet bridge operates on frames and a router operates on packets. The proxy ARP router should have routes to all hosts on both segments. Once the router can reach all locally connected destinations via the correct interfaces, you can begin to configure the proxy ARP functionality. Although proxy ARP complicates a network, a great advantage of proxy ARP technique is the greater control over IP connections between hosts. There are two primary proxy ARP techniques. With the 2.4 kernel, it is possible to use the sysctl net/ipv4/conf/all/proxy_arp to perform proxy ARP. Alternatively, manual population of the ARP table reaches the same end. The key part of the correct functioning of proxy ARP in a network is that the host breaking a network into two parts has correct routes for all destinations in both halves of the network. If the host which has interfaces in both networks does not have an accurate routing table, IP packets will get dropped on the routing device. One common method of breaking a network in two involves making a very small stub subnet at one end or the other of the IP range. This small subnet (maybe as small as a /30 network, with two usable IPs) makes an excellent sequestered location for a host which requires more protection or even, a generally untrusted host which shouldn't have complete access to the Ethernet to which the other machines connect. For a practical example of this, see the relationship between the &service-router;, &masq-gw; and &isolde; in the network map. &isolde; and &service-router; share the same IP network, 192.168.100.0/24. If either has a packet for the other, it will generate an ARP request which should be answered by &masq-gw;. Naturally, &masq-gw; has its routes configured in such a way that both hosts are reachable from it. Thus, the packet will successfully pass through &masq-gw;. Let's examine what the sequence of events is by which the packet will reach &service-router; from &isolde;. In this example, &isolde; will send an echo request packet to &service-router;. Please also refer to for examples and command lines to create a proxy ARP configuration. the admin on &isolde; creates an echo request packet for 192.168.100.1 with ping &isolde; sends an ARP request for the owner of 192.168.100.1 &masq-gw; replies that &isolde; should send packets for 192.168.100.1 to its Ethernet address, 00:80:c8:f8:5c:71 &masq-gw; receives the packet, unwraps it and selects eth3 as the output interface &masq-gw; sends an ARP request for the owner of 192.168.100.1 &service-router; replies that &masq-gw; should send packets for 192.168.100.1 to its Ethernet address, 00:c0:7b:7d:00:c8 &service-router; receives the packet unwraps it and hands it up the IP stack, which generates an echo reply bound for the source address, 192.168.100.17 (&isolde;'s IP) &service-router; sends an ARP request for the owner of 192.168.100.17 &masq-gw; replies that &service-router; should send packets for 192.168.100.17 to its Ethernet address, 00:80:c8:f8:5c:74 &masq-gw; receives the packet, unwraps it and selects eth0 as the output interface &masq-gw; sends an ARP request for the owner of 192.168.100.17 &isolde; replies that &masq-gw; should send packets for 192.168.100.17 to its Ethernet address, 00:80:c8:e8:4b:8e &isolde; receives the reply, unwraps it and hands it up the IP stack to the awaiting ping command Where possible, a simplified network is easier to maintain, but occasionally, this sort of trickery is necessary. This is an excellent way to insert a firewall into the middle of a network. The firewall, naturally, has to have its routes set properly, and proxy ARP entries will be required for routers. Now, here's a short script and configuration file which can be run as a SysVInit style script. This script provides a great deal of control over the ARP table directly so may be preferable in some cases to an alternate solution outlined below. This proxy-arp script reads the following configuration file. Each is commented heavily so it should be clear how to use them. This chapter discussed how to break a network in twain with proxy ARP techniques. For another explanation of the same concepts, read the Proxy ARP Subnet mini-HOWTO. Available in most (all?) 2.4 kernels is built-in capability for Proxy ARP. This is documented in deeper detail above. Consider familiarizing yourself with the methods of suppressing and controling ARP through Julian Anastasov's work.

Don't forget to add something here about multiple IPs bound to loopback; and refer to Julian's work. FIXME

Assume a machine has multiple connections to the same Ethernet segment, and has individual IPs bound to each interface. A peculiar feature of linux is its willingness to respond to ARP requests for any IP bound to any interface. This can lead to ARP flux, a situation where a given IP is sometimes accessed on one MAC address and sometimes another. /proc/sys/net/ipv4/conf/all/hidden; consider arp suppression issues.

Consider ARP suppression issues. Leakage of sensitive (IP addressing) information from other interfaces.

FIXME!! Don't forget to note that iproute2 NAT and binding to non-local IPs do not play well together. I disagree with this. Binding to a non-local socket, which was possible under kernel 2.2 with when the kernel was compiled with CONFIG_IP_TRANSPROXY, is available under kernel 2.4 via the /proc IP sysctl interface. If you wish to be able to bind to non-local sockets: # echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind Thanks go to Oskar Andreasson for his IP sysctl tutorial page. If using sysctl to allow binding to non-local IP doesn't solve your problem, then see if netfilter NAT can be used to solve this class of problem. Some people view the technique of binding to non-local IPs as spoofing, and indeed, it can be used for nefarious purposes, if an attacker controls a machine on the route between a target and a victim.