IP Helper on SonicOS Enhanced

Transcription

1 Introduction IP Helper on SonicOS Enhanced Version: 1.0 Date: 8 April 2005 IP Helper is a framework within SonicOS Enhanced designed to manage the conveyance of broadcast traffic across network boundaries. Broadcasting is used to allow one node to communicate simultaneously with multiple nodes on a network by specifying a broadcast destination address. Since there is no one, or perhaps even no foreknown recipient for broadcast traffic, the layer 2 (MAC) destination address for broadcast traffic is always FF:FF:FF:FF:FF:FF, while the layer 3 (IP) broadcast address can take on a number of different forms, as described below in limited broadcasts and directed broadcasts. When a node receives a packet, in addition to responding to traffic destined for its own unique MAC address and assigned IP address, it is expected to process traffic destined for the broadcast MAC address (FF:FF:FF:FF:FF:FF:) at layer 2, and traffic destined for interesting subnet broadcast addresses at layer 3. The term interesting is used to refer to subnet broadcast traffic destined for the layer 3 broadcast address , as well as to broadcast traffic directed to the subnet to which the node belongs. RFC 1812 ( Requirements for IPv4 Routers ) defines two major types of IP broadcasts: Limited Broadcasts A limited broadcast is used when a single node needs to communicate to all other nodes on its local segment. The limited broadcast IP address is , and is typically used when the network is not yet known. It is only valid as a destination address, not as a source address. A common example of this is a node requesting an IP address from a DHCP/BOOTP server, where the initial DHCP discover packet will look something like this: Directed Broadcasts A directed broadcast is used when a single node needs to communicate will all other nodes on a particular subnet. Because there is both classful and classless subnetting, subtle distinctions were made between the types of directed broadcasts: o o Network Broadcast Used by classful networks (i.e. class A, class B, class C) where the network broadcast address is composed of the classful network with all the host bits sets to 1. Used to send packets to all nodes on that classful IP subnet. For example: Class A: (last three octets are set to all 1, for a value of 255) Class B: (last two octet are set to all 1 ) Class C: (last octet is set to all 1 ) All-Subnets Directed Broadcast Originally intended to communicate with groups of subnets within a classful networking scheme. Deprecated with advent of classless networking. For example: To communicate with all subnets apportioned within the classful /16 network (i.e x/24 through x/24), the all-subnets broadcast address would have been used historically, but with classless networking there is a conflict since it is not possible to distinguish between the use of for allsubnets and its use for subnet-broadcast to x/24 1 The Address is also sometimes referred to as a limited broadcast address, but it is an obsolete form and such packets are generally discarded. 1

2 o Subnet Broadcast Used by classless networks, where the broadcast address is composed of the variable length network with its remaining hosts bit set to 1. Used to send packets to all nodes on that subnet. For example: Subnet /27 ( bits network, 5 bits host) where the subnet broadcast address would be (the 5 host bits are set to 1 for a value of 31). A common example of this type of broadcast is NetBIOS name resolution. Today, only subnet broadcasts remain truly relevant. RFC 1812 goes on to explain circumstances under which router should pass broadcast traffic; generally, routers rarely pass broadcast traffic across subnet boundaries, both for the purpose of minimizing broadcast traffic, and for preventing the forwarding of broadcast traffic from one subnet to an unrelated (uninterested) subnet. For example, the broadcast address would be interesting to all nodes on the x/24 subnet, but it would not be interesting to nodes on the x/24 subnet. There are, however, two very practical instances where broadcasts from subnet are required to be forwarded to another subnet, namely DHCP and NetBIOS. IP Helper DHCP Relay The IP Helper DHCP relay is designed to transport DHCP broadcast requests received on one SonicWALL interface to a specific DHCP server as designated by a Host Address Object. Consider the following network: The PRO 1260 Enhanced is configured for one Primary LAN interface ( ) and three PortShield interfaces ( , , and ). The first two PortShield interfaces are assigned to the LAN Zone. The third PortShield interface is assigned to the WLAN, and it hosts a single SonicPoint for wireless users. The network had a LAN based DHCP server ( DHCPServer ) in place prior to the integration of the PRO 1260 Enhanced, and it was serving the single scope ( x/24). The network administrator preferred to continue using that DHCP server rather than activating DHCP services on the PRO 1260 Enhanced. 2

3 With IP Helper DHCP relay, the network administrator can configure three additional scopes on the DHCP Server for the x, x, and x subnets and have the SonicWALL forward the requests from the PortShield interfaces to the DHCP Server. Assuming the DHCP server is a Microsoft Windows server, the list of defined scopes in this configuration would look like: And scope options might be defined as follows ( x PortShield1 subnet selected): Important: When configuring a DHCP scope on an external DHCP server for requests being forwarded from a WLAN Zone assigned interface (e.g x PortShield3) be sure that the scope does not intersect with the automatic addressing of the SonicPoints connected to that interface. For example, if on PortShield3 you declare that 2 SonicPoints will be present, the top 2 usable addresses of the subnet will be allocated by the SonicWALL to the SonicPoints (i.e and ). The top end of the DHCP scope you define on the external DHCP server for this subnet should therefore be or lower. Relay Agent Identification When IP Helper s DHCP relay forwards discover and request broadcasts from clients, it adds relay agent detail to the DHCP packet so that the DHCP server knows from which scope to serve the address. For example, DHCP requests received on PortShield1 would have a relay agent value of added before being sent by IP Helper to the DHCP server, requests received on PortShield2 would have relay agent value of added, etc. This way, the DHCP server can select the scope appropriate to the request as defined by the relay agent value. Configuring IP Helper for DHCP IP Helper configuration is performed from the Network > IP Helper page of the UI, and begins by selecting and applying the Enable IP Helper checkbox. Next, select and apply the Enable DHCP Support checkbox. Note: IP Helper DHCP Support can only be enabled if the SonicWALL s internal DHCP Server is not active. If the internal DHCP server is active, the IP Helper DHCP option will not be available, and will only be made available upon deactivating the SonicWALL s internal DHCP server. The next step is to add the policies necessary to forward the DHCP discover and request broadcast packets received on the applicable interfaces to the designated DHCP server. If a host Address Object for the target DHCP server does not yet exist, create one: 3

4 The DHCP server may now be selected in the three policies you will need to create to support the configuration depicted above. Click the Add button below the IP Helper Policies table, and add the following three policies: When defining IP Helper DHCP policies: The From: field must be an interface. Allowable interfaces are: o TZ Series Enhanced: LAN, OPT, WAN o PRO 1260 Enhanced: LAN, OPT, WAN, all PortShield interfaces o PRO 2040/3060 Enhanced: X0, X1, X2, X3, X4, X5 o PRO 4060/5060: X0-X5, VLAN sub-interfaces The To: field must be a Host Address Object, and it may reside on any Zone. After creating these policies, the resulting IP Helper table should look as follows: 4

5 IP Helper NetBIOS Relay The IP Helper NetBIOS relay operates differently from the DHCP relay in that it translates NetBIOS subnet broadcasts from a one or more selected source subnets to NetBIOS broadcasts bearing addresses that will be interesting to one or more selected destination subnets. The IP Helper NetBIOS relay acts specifically on UDP 137 (NetBIOS Name Service) and UDP 138 (NetBIOS Datagram) broadcast traffic to enable broadcast node (b-node) style name resolution (e.g. Network Neighborhood) across subnet boundaries. IP Helper NetBIOS relay is particularly important to PRO 1260 Enhanced PortShield installations because of the potential for network segmentation. Consider the same sample network as before: Assume that prior to the installation of the PRO 1260 Enhanced, all the hosts on the network were on a single IP subnet ( x/24). The PRO 1260 Enhanced was configured with three PortShield interfaces to segment the network for functional and security purposes, but now the network administrator discovers the need to pass NetBIOS broadcast traffic among all four subnets (or segments) protected by the PRO 1260 Enhanced. If PC-2 (NetBIOS name PC-2 ) attempts browse a share on PC-A, it will send a NetBIOS Name Service (NBNS) query to the layer 2 destination broadcast address (FF:FF:FF:FF:FF:FF) and to its subnet broadcast address ( ) on UDP port 137. Without IP Helper, the SonicWALL would drop this broadcast traffic. But with IP Helper, it is possible to define where the broadcast traffic should go, and to translate it accordingly. 5

6 When the IP Helper NetBIOS relay receives a NetBIOS broadcast packet, it translates the subnet broadcast address to match the subnet (or subnets) of its policies configured destinations. Some considerations about the NetBIOS relay and it policies: When IP Helper forwards a packet, it decrements the TTL (time to live) specified in the source IP header by a value of 1 2. Microsoft operating systems generally specifies a default TTL value of 128. NetBIOS policy source and destination must be a Network Address Object, or a Group of Network Address Objects. NetBIOS policy source and destination cannot overlap. In other words, you cannot specify a policy from Network Address Object PortShield Interface 1 Subnet to PortShield Interface 1 Subnet, or from Network Address Object LAN Primary Subnet to Group mysubnetgroup if mysubnetgroup contains LAN Primary Subnet as a member. The same source cannot be specified in multiple policies. In other words, if you want NetBIOS broadcasts from LAN Primary Subnet to be relayed to 3 different destinations subnets, rather than creating 3 policies, you would create a Group comprising the 3 destination Network Address Objects. Configurations requiring the relaying of NetBIOS broadcasts to both local and VPN subnets require special consideration. See the IP Helper NetBIOS Relay with VPNs section. Defining Destination Groups With these considerations in mind, the goal should be to design the destination Groups for each of our four source subnet from we will be relaying NetBIOS broadcasts to all other subnets. The four Groups to create would look like: Now these groups can be selected as the destinations in the four IP Helper NetBIOS policies you will create for each of our four source subnets. 2 Versions of SonicOS Enhanced prior to would decrement the TTL to a fixed value of 4. This would sometimes cause the relayed NetBIOS broadcasts packets to expire on routed destination networks. Upgrading to SonicOS Enhanced or higher is recommended for networks requiring NetBIOS relay support. 6

7 Configuring IP Helper for NetBIOS IP Helper configuration is performed from the Network > IP Helper page of the UI, and begins by selecting and applying the Enable IP Helper checkbox. Next, select and apply the Enable NetBIOS Support checkbox. Next, click the Add button below the IP Helper Policies table, and add the following four policies: The resulting table will look as follows (DHCP policies from previous section included): 7

8 With these policies in place, all NetBIOS broadcast traffic received on any one of the four segments will be relayed to the other 3 segments. For example, NetBIOS broadcast traffic sourced from PortShield Interface 1 Subnet ( ) will be translated to: , and sent out the LAN interface , and sent out the PortShield2 interface , and sent out the PortShield3 interface IP Helper NetBIOS Relay with VPN VPN Policies will auto-create IP Helper NetBIOS relay policies if the Enable Windows Networking (NetBIOS) Broadcast checkbox is selected on the Advanced tab of the VPN Policy. The source of the IP Helper policy will be the local network selected on Network tab of the VPN Policy. If your network requires that you forward NetBIOS broadcasts both to VPN destination subnets, as well as to local destination subnets, the Enable Windows Networking (NetBIOS) Broadcast should not be used on the VPN policy. An alternative configuration will be described in this section. Consider the following network: Here we have the same sample network as was reviewed in the IP Helper NetBIOS Relay section above, but we ve added a site-to-site VPN connection. There is a requirement to forward NetBIOS broadcasts among all subnets both local and remote. Assume the PRO 1260 Enhanced has a VPN Policy with the local network defined as the Group Firewalled Subnets (which comprises x, x, x, and 192, x) and a destination network of Subnet. The remote TZ 170 has a complementary VPN policy configured. 8

9 If the VPN policy on the PRO 1260 Enhanced had the Enable Windows Networking (NetBIOS) Broadcast option selected, that would auto-create the IP Helper NetBIOS policy from Firewalled Subnets to the Subnet destination Network Address Object. This would preclude any of the Firewalled Subnets from being used in another IP Helper policy for the relaying of NetBIOS traffic among themselves. Important: If your network requires the relaying of NetBIOS to both local destination subnets and VPN destination subnets, do not select the Windows Networking (NetBIOS) Broadcast option on your VPN policy. If this option is enabled, attempts to create the IP Helper policies for your local networks will fail because of the source overlap. Conversely, attempts to enable this option after the definition of the IP Helper policies for your local networks will result in failure to auto-create the VPN related IP Helper policies. Instead you must manually craft the appropriate destination groups for NetBIOS relaying. Instead of using the Enable Windows Networking (NetBIOS) Broadcast option on the PRO 1260 Enhanced, the Subnet Network Address Object should be added to each of the four destination Groups defined in the previous section, resulting in the following: As long as the TZ 170 only requires the forwarding of NetBIOS broadcasts across the VPN (and not to another local subnet, such as the OPT subnet), the Enable Windows Networking (NetBIOS) Broadcast should be used on its VPN policy for the auto-creation of the IP Helper NetBIOS policy. 9