SonicOS Simulating Transparent Mode for Multiple Subnets Introduction One of the recent enhancements made to SonicOS Enhanced was the ability to support transparent or bridge mode. This refers to the capability to support address within the same subnet space on both an external (WAN) and internal (LAN) interface. A limitation to this feature is that the firewall may only support one transparent range so if a scenario is encountered which requires support for additional transparent ranges, a workaround must be utilized. Fortunately SonicOS Enhanced truly is a Swiss army knife ; it s rich array of features and configuration options provide the flexibility to integrate into even the most complex and demanding environments. Real-World Application A web-hosting provider wishes to firewall web servers in transparent mode to provide web hosting without host headers (each site has it's own address). This avoids a potential scenario where some Content Filtering Provider intentionally blacklists one of the hosted sites but inadvertently blocks access to all other sites by virtue of them sharing the same IP address. In this scenario assuming the web hosting service provider has a successful growing business, there is a continual requirement for additional IP addresses. When requesting additional public addresses from a COLO, frequently the additional address space is not contiguous nor falls within previously assigned address space(s). Functional Requirements The example in figure 1 below illustrates the type of functionality that is required in the aforementioned scenario. Notice that the COLO has supplied two Internet feeds to the web-hosting service provider and that each has a separate class-c subnet associated with it. Also notice that in this hypothetical configuration the firewall is configured to support both subnets in transparent mode. Figure 1 Since at this time SonicOS Enhanced does not support a second transparent range outside the scope of the primary WAN subnet, it cannot be configured precisely as the graphic illustrates. There are however several methods of implementing a workaround that will provide nearly identical functionality and should be suitable for most situations.
Solution #1 This solution is useful in situations where the use of a stub subnet for routing between the COLO/ISP s router and the SonicWALL WAN interface is not an option. It is the most cumbersome of all the solutions in terms of internal addressing and configuration data entry but provides an acceptable workaround without any changes to the currently used WAN addressing except for the subnet mask. The following table shows the breakdown. The first network (highlighted in blue) will be used as the stub subnet between the COLO/ISP s router and the SonicWALLs WAN interface. Since network number.128 (highlighted in yellow) contains the most hosts, it will be used as the primary subnet for the internal interfaces (X0 & X3). The remainder of the subnets will be supported as secondary subnets on their respective interfaces. This solution utilizes a new feature in SonicOS 3.0 called Static ARP to accomplish the goal. Through the use of static ARP publishing, the SonicWALL can be configured to support secondary subnets on a single physical interface. Figure 2 below illustrates this configuration. Figure 2 2
Solution #2 This scenario utilizes different physical interfaces for each subnet. In this and the other three example workarounds you will need the cooperation of the COLO/ISP in terms of providing you with a stub subnet (/30) for purposes of routing between their router(s) and the SonicWALLs WAN interface(s). Figure 3 below illustrates this configuration. Figure 3 Solution #3 This scenario utilizes the same physical interface to support multiple subnets. Like the first solution, this solution also utilizes the new Static ARP feature in SonicOS Enhanced 3.x. Figure 4 below illustrates this configuration. Figure 4 3
Solution #4 The final solution uses VLAN technology to partition multiple subnets. It utilizes another new features in SonicOS 3.x enhanced; VLAN support. The use of this solution requires a VLAN capable switch to which the servers will connect to. All but one of the switch s ports are grouped into two VLANs and the remaining port is configured to trunk all VLANs. The SonicWALLs X0 interface is configured with two sub-interfaces to support the incoming VLAN trunk. To demonstrate the flexibility of all three solutions, Figure 5 shows a variation that utilizes only one upstream router. The router is configured to route multiple class C subnets to a single IP assigned to the firewalls X1 interface. Realize that this is just one variation; many are possible. Figure 5 Lab Setup Before implementing this or any other solution into production, it s a good idea to familiarize oneself with the various details involved in configuring it. For this lab setup solution #4 will be detailed in a step-by-step manner. Solution #4 was chosen because it utilizes most of the configuration options of the other solutions, exposes you to some practical usage of the new VLAN functionality in SonicOS Enhanced 3.x, and because it s the most scalable and practical of the solutions. Figure 6 illustrates the setup. 4
Figure 6 1. Configure your VLAN switch for two VLANs. Assign them VLAN ID s of 11 and 12 respectively. Configure the switch to trunk both VLANs to one port and connect that port to the SonicWALLs X0 interface. 2. Assign a static IP address to server #1 of 11.1.1.2. Use a mask of 255.255.255.0 and 11.1.1.1 as the default gateway. Connect this sever to a port in VLAN 1. 3. Assign a static IP address to server #2 of 12.1.1.2. Use a mask of 255.255.255.0 and 12.1.1.1 as the default gateway. Connect this server to a port in VLAN 2. 4. At the SonicWALL, go into the Network>Interfaces configuration page and click the Add Interface button. In the popup window that appears enter the following values: 4.1. Zone: LAN 4.2. VLAN Tag: 11 4.3. Parent Interface: X0 4.4. IP Assignment: Static 4.5. IP address: 11.1.1.1 4.6. Subnet Mask: 255.255.255.0 5
5. Click the OK button to save your settings. It should look something like this: 6. Create another sub-interface and assign it an IP address of 12.1.1.1 and a VLAN tag of 12. All other parameters are the same as the first sub-interface you created. When done it should look something like this: 6
7. Got to the Firewall> Access Rules configuration page and create a rule in the WAN > LAN intersection that allows ping from any source to 11.1.1.2 and 12.1.1.2. You may create an address object group to accomplish this with one access rule. When done it should look something like this: 7
8. Go to the Network>NAT Policies configuration page and locate the two auto-created NAT policies that NAT the X0:V11 and X0:V12 subnet to the WAN Primary IP. Disable them. It should look something like this: 9. Connect a laptop to a switch or hub outside of the firewall. Assign it a public address on the same network as the WAN interface of the SonicWALL. Figure 6 above shows actual Comcast Cable Internet Service public addresses. Change your addressing accordingly. 10. Next, enter the static routes that will configure your laptop to access the 11.1.1.0/24 and 12.1.1.0/24 networks via the SonicWALLs WAN IP address. Open a command prompt and enter the following commands: ROUTE ADD 11.1.1.0 MASK 255.255.255.0 SonicwallWanIP ROUTE ADD 12.1.1.0 MASK 255.255.255.0 SonicwallWanIP 11. Be sure and substitute whatever you SonicWALLs WAN IP address is for the SonicwallWanIP parameter. 8
Optional: 1. Go into the IIS manager program and then open the Default Web Site Properties window. Configure the following options: a. Documents tab. Add index.shtml to the list of default documents. It should look like this: b. Click the OK button when done. 2. Using notepad or some other text editor, create a new file in the c\inetpub\wwwroot directory and call it Index.shtml. Edit this file and enter the following lines (you can copy and paste): <script language="javascript"> var ip = '<!--#echo var="remote_addr"-->' function ipval() { document.myform.ipaddr.value=ip; } window.onload=ipval </script> <H3>Your IP Address is: <form method="post" action="" name="myform"> <input type="text" name="ipaddr" readonly> </form></h3> </HTML> 3. Save the file. Its function is to display the source IP address of any client accessing the site. Test the setup by opening a browser to http://localhost. It should display your IP address on the web page. Testing From the laptop try and ping 11.1.1.2 and then 12.1.1.2. You should get responses in both cases. From servers 11.1.1.2 and 12.1.1.2 access the website on the external laptop. You should see the original IP addresses of both servers. Document Created: 06/07/2005 Last Updated: 06/17/2008 Version 1.1 9