The following steps will create the minimal configuration necessary for an operational rXg.
First you must setup your WAN DNS address record. An operational rXg requires that the WAN IP address be associated with a DNS address record. To accomplish this, you must setup an address record with either your WAN DNS server or a dynamic DNS service. In either case, you must choose a domain name that you will use with your rXg and configure the server with the address record or tell the dynamic DNS service to expect address for that domain name updates from the rXg.
With a DNS record in place, you must now access the rXg management console. The easiest way to accomplish this is to connect a laptop computer configured for DHCP to the default LAN port of the rXg. Power on the rXg and your laptop. If the physical connection is good, the laptop computer should obtain an address of 192.168.5.x. Open a web browser and open the location https://192.168.5.1/admin/. At this point, your browser should bring up a security warning regarding the invalid nature of the SSL certificate on the rXg. Bypass the warning and continue on to the site.
Since this is the first time you are logging into the console on this newly installed rXg, the console will redirect you to a special page tha allows you to create the first administrative account(s). Clicking on the "Create" link at the upper right quadrant of the table will bring up an form for you to fill out. When you are done filling out the form, click the create button at the bottom of the page and a new row will appear in the table showing the administrative account you just created.
Now that you have an administrative login created, you should click on any of the links at top of the menu bar. This will bring up the licensing page. You must obtain a valid license for this rXg before continuing. To obtain a license, email email@example.com, copy your account manager, and include your Installation Unique Identifier in the request. Once you have obtained the license from us, you can edit the record in the rXg to install the license.
Using the system menu, choose device options. At a minimum you must configure the domain name and the time zone. The domain name option should be set to the WAN DNS address record that you selected and configured on either your external DNS server or the dynamic DNS service that you plan to use. The time zone option should be set to your local time zone where the rXg is installed.
Another item of the system menu that must be configured is the SSL certificate. By default, the rXg will use a self-signed certificate that is only useful for permitting initial, demonstrative access to the console and portal. While it may appear to be functional, the self-signed certificate must be changed during installation and cannot be used in production under any circumstances. In order to obtain a signed SSL certificate you must first create a new SSL keychain specifying the name only. Now create a new certificate signing request for the key chain that you just created, filling out the form in it's entirety. Do not click on the self sign checkbox. Now you should be able to show the CSR that you created. Submit the CSR to a signing authority to obtain a signed certificate and intermediate keychain which you should paste into the SSL keychain that you created. More detailed instructions can be found in a SSL installation FAQ.
Using the network menu, you must configure the WAN interface. By default, the WAN interface is set for DHCP. In addition, you must configure the WAN bandwidth. The rXg is configured for a default download bandwidth of 5 Mbps and an upload bandwidth of 512 Kbps. A simple way to find reasonable values is to configure the settings to their maximum and run a speed test. For maximum effectiveness, you should configure these settings to be slightly less than the actual bandwidth of your WAN pipe.
If you wish, you may choose to modify the LAN address as well. If you choose to change the LAN address, make sure you modify the DHCP pool setting under the Services menu as well.
Finally, if you are using dynamic DNS, you must configure the Dynamic DNS client. Using the services menu, choose the DNS menu item. Create a new dynamic DNS client and choose the protocol that is appropriate for your provider. You must specify the login and password for your dynamic DNS account and the host that you wish to update. In the vast majority of instances, the host that you wish to update should be the host configured in the system options.
You now have an operational rXg. Traffic will pass between the LAN and the WAN. The next step is to configure the policies and billing mechanisms to begin generating revenue.
Your hardware clock is wrong. There are several reasons why this may be the case. Usually this happens if you have run a full reset on you BIOS or if the battery on your motherboard has died and your machine lost power.
There are two ways to correct this problem. One way is to hard reboot the machine, go into the BIOS and set the time to the right time. The second is to get the WAN port of the rXg connected to the Internet and allow the rXg software to synchronize the clock with network time protocol servers. By default, the WAN port on a fresh rXg installation is set for DHCP. The problem will be resolved simply connecting the WAN port to a DHCP enabled network with Internet connectivity and rebooting the rXg.
Note that if the motherboard battery has died, you will run into the same problem again when you reboot. It is highly recommended that you correct the root cause of the situation to avoid network disruption at a future time.
Before you initiate a factory reset, you should backup your configuration. In addition, it is strongly recommended that you keep a copy of your SSL private key, intermediate and signed certificates as these will be lost when you perform a factory reset.
Login to the rXg web management console. Click on the System menu tab. On the system dash board, there is a button for resetting the rXg to factory configuration. You must wait up to four minutes for the factory reset to occur.
If you cannot reach the rXg web management console, contact WAV support personnel for further assistance.
Many operators choose to deploy rXg in virtual environments due to the numerous benefits that virtual environments offer. While rXg has been successfully used for demonstration purposes in a broad spectrum of virtual environments, RG Nets only officially supports VMware ESXi 5.1 and later for production environments.
The bare minimum configuration for a virtual environment for testing purposes is 2 virtual Ethernet interfaces, 4 GB of virtual RAM and 30 GB of virtual disk space. For testing purposes, the first Ethernet interface should be bridged to the outside world and will be chosen by the rXg for the WAN port. The second interface should be connected to a host-only network and will be chosen by the rXg for the LAN port.
For production systems, the minimum virtual environment configuration to support 100 SULs is two virtual Ethernet interfaces, 4 GB of virtual RAM and 30 GB of virtual disk space. Naturally, both virtual Ethernet interfaces must be bridged to the outside world in order for traffic to pass.
Some additional notes:
If there is a choice of drivers in the virtual environment, please choose Intel gigabit Ethernet (e1000). In VMware ESXi, this is the default and required adapter.
If there is a VLAN configuration in the virtual network, please make sure that "all VLANs" are passed to the rXg. In VMware ESXi this is accomplished by setting the VM Port Group to 4095.
The rXg is an extremely resource intensive system and demands real-time responsiveness from the underlying hardware. The rXg should only be used in a virtual environment with sufficient over provisioning in order to prevent packet loss.
The rXg software distribution can be installed on RG Nets, Inc., provided turn-key gateway appliances or installed as a virtual appliance in a virtual machine environment. RG Nets, Inc., turn-key gateway appliances make it easy for operators to get up and running quickly by racking in a single device. The virtual machine environment is appropriate for operators who wish to have the rXg feature-set execute on their own hardware.
Installing the rXg software will completely erase all data, including but not limited to the operating system, user data, configuration as well as anything else present on the target persistent storage device. Do not proceed unless you are willing to lose all data on the device. In addition, if the installation process fails, it is more than likely that your hardware will be left in an unusable state. Proceed with caution.
If the installation target is a physical machine such as an RG Nets, Inc., supplied turn-key gateway, you must have a USB CDROM drive or USB memory stick loaded with the rXg image, keyboard and monitor to proceed. In addition it is highly recommended that you have a serial terminal or laptop with a serial port present in case problems occur during the installation process.
In order to create a bootable USB memory stick, please see the article titled "How do I create a bootable USB memory stick using the rXg USB image file?"
If the installation target is a virtual machine, then the virtual machine environment should be configured with to meet the following minimum requirements: 2 Ethernet ports, 2 CPUs, 2 GB of RAM, 20 GB of disk space. The stated minimum requirements are needed to support 100 simultaneous login sessions. The CPU count and GB of RAM should be increased by 1 for every additional 100 additional simultaneous login sessions that need to be supported. Additional Ethernet ports may be defined as needed.
In some cases, the clock frequency of the target machine must be stabilized before proceeding. Intel SpeedStep, AMD Cool 'n' Quiet, or other similar power-saving technologies that vary the processor speed may cause problems with the rXg software. If you are installing to a physical machine, use the BIOS to disable all such mechanisms. If you are installing to a virtual machine, hard code the clock frequency if possible. For VMware workstation, please see the following tech note:
To obtain a copy of the rXg ISO please visit https://support.wavonline.com/ and use your WAV credentials for access. You should begin downloading the rXg ISO immediately. The ISO is nearly 500 MB and you should plan accordingly for the download time. The MD5 of the ISO is available at the same download site. Please check the MD5 of the ISO that you have downloaded before proceeding.
If you plan on installing to a physical turn-key gateway appliance using the CD image, you will need to burn the ISO file to a CD-R or DVD-R. Make sure that you burn the ISO file as an image, not as a file, because burning as an image is a critical step in making the resulting CD-R bootable. Once you have the CD-R burned, you should check it by reading it with your computer. If you only see a single file in the root directory of the CD-R, then you have burned it incorrectly as a file and you will need to repeat the process and burn as an image.
Make sure you have a monitor and keyboard, as well as your install media plugged into your gateway appliance hardware. You will now need to reconfigure the basic input output system (BIOS) of the appliance hardware to boot from the appropriate media type. To accomplish this, you will need to interrupt the power-on-self-test (POST) process. Power on the appliance. As it begins to boot, you will need to press the 'del', 'F1', 'F2' or 'F12' key on your keyboard to enter the BIOS setup menu. The BIOS should notify you which key you need to press. Once in the BIOS, you will need to change the boot priority. Each BIOS publisher has their own unique mechanism for accomplishing this. If a label such as "Boot," "Boot Sequence" or "Boot Priority" cannot be found, look under "BIOS Features" or "Advanced BIOS Features." If you search Google you will find many resources to help you navigate this problem, such as:
When you have completed configuring the BIOS with the proper boot order, you must make sure that you save your changes and exit. This will usually cause the appliance hardware to reboot. Upon reboot, the appliance should begin booting from the install media. You will know that this is working properly when the console reports that it is booting FreeBSD. If you do not see messages saying that FreeBSD is booting, you have not properly completed one of the steps above. Repeat the procedure and follow the instructions carefully until FreeBSD boots from your install media.
If you are installing to a virtual machine, you will need to use the CD image. You should connect the virtual CDROM device of your newly configured virtual machine. Newly created virtual machines will boot off of the virtual CDROM by default because the virtual hard drive is not yet bootable. If you are attempting to reinstall the rXg, the easiest way to get the virtual machine to boot off of the virtual CDROM is to delete the virtual hard drive and recreate it. Once you do this, the virtual machine will then boot off of the virtual CDROM because the hard drive will be in the same state it was in when the virtual machine was newly created.
Once the turn-key gateway or virtual machine boots off of the install media, you will see a boot loader countdown. After the count down timer expires, you will be you will arrive at the rXg install menu. Moving beyond this step will completely erase all data on your appliance. Press the 'enter' to continue the installation. The entire of the installation process is completely automated so pressing 'enter' is the point of no return.
Once completed, the system will automatically reboot. At this point, you will need to disconnect the install media. If using a CD, you may wish to eject the rXg CDROM from the USB drive before disconnecting it because many USB CDROMs do not have a manual, unpowered eject process. For virtual machines, you may now disconnect the virtual CDROM drive from the rXg ISO at this point.
Now you are ready to connect to the admin console and move on to the rXg first-boot and basic configuration procedure.
Default LAN and WAN interfaces:
WAN - first defined Ethernet port
LAN - last defined Ethernet port
You should now follow the procedure for boot strapping an rXg found in the FAQ titled "What are the steps for initial rXg configuration?"
It may sometimes be necessary to re-install an rXg appliance OS stack. This can be accomplish via CD as outlined in a different FAQ, or via a USB memory stick.
This FAQ outlines how to create a bootable USB memory stick with the rXg OS and software stack.
1. Download the latest USB image file. The file will end with the .img file extension.
2. Have a USB memory stick at least 1GB in size.
Conceptually the process is simple. You download the USB image file, then write that image to the physical USB device on your computer. The process for writing to a physical device depends upon the OS of the computer used to write the image file. This process COMPLETELY ERASES the contents of the USB memory stick.
1. Download the latest USB image. Save to your local computer.
2. Download the following disk image utility for windows: http://sourceforge.net/projects/win32diskimager/files/latest/download
3. Extract the zip file to a folder on your local computer.
4. Insert the USB stick into your computer and obtain what drive letter windows assigns to your device.
5. Open the folder containing the win32diskimager and double click on 'Win32DiskImager'
6. Accept any OS warning to run the program. Ignore any startup errors from the program.
7. In the 'Image File' section, click the blue folder icon and browse to the location of the USB image downloaded earlier, click Save.
8. In the 'Device' section, choose the appropriate drive letter for your USB device. BE VERY CAREFUL ON THIS STEP!
9. Click the 'Write' button.
10. The process is complete, you now have a USB memory stick that will boot and install rXg onto your gateway.
11. Eject the USB memory stick and remove from your computer.
1. Download the latest USB image. Save to your Desktop.
2. Open the Terminal application (Applications->Utilities)
3. Type the following commands into the terminal:
# become the super user
# to find the appropriate drive device (disk2, disk3 etc)
# if the disk already has an OS-X mountable partition, unmount it, but do not "eject" the drive, if not, click ignore when inserting it
diskutil unmountDisk /dev/diskX # where X is obtained from the diskutil list command above
# write the image to the USB stick BE VERY CAREFUL WITH THE FOLLOWING STEP!
dd if=~/Desktop/file.img of=/dev/rdiskX bs=64m # where file.img is the filename of the image you downloaded and X is the number of the USB device
4. After the last dd command above is finished, the terminal will return to a prompt and writing the image is complete.
5. Close the Terminal application.
6. Remove the USB memory stick from your computer.
Only Intel Ethernet interfaces are officially supported by RG Nets. Other interfaces types may work but are unsupported and your mileage may vary. When installing using VMware, you MUST select the e1000 adapter. The vmxnet adapter types are NOT supported.
The rXg requires a minimum of two Ethernet interfaces (one for the WAN and one for the LAN). Additional Ethernet interfaces may be required in order to support multiple uplink control scenarios. For example, if the operator wishes to have the capability to load balance and/or failover between two WAN uplinks, then a minimum of three Ethernet interfaces is required. Additional Ethernet interfaces may also be assigned for LAN connectivity. Physically separate Ethernet interfaces are sometimes needed to fulfill compliance requirements (e.g., for credit card processing or property management system interfaces).
In general we have found that motherboard integrated Intel Ethernet controllers work best. Many white box "server" motherboards have 4 integrated Ethernet ports on them. PCI-e network interface cards may be used to increase the number of Ethernet ports available on the rXg when the ports available on the motherboard are insufficient.
The only officially support persistent storage devices are Intel 500+ series SSDs or better. The rXg software is specifically optimized to use a high-speed SSD as the persistent storage. The rXg will install on rotational persistent storage and this is suitable for testing purposes. However, only Intel SSDs are supported for the purposes of deploying a production rXg. When using VMware, multi-tier shared storage is OK if the cache drives are Intel SSD's. The VMware VSAN product works well. HP Store Virtual VSA also works. Physical SAN with Intel SSD cache drives are also OK.
The rXg requires very high random write performance on the persistent storage subsystem. Every aspect of the persistent storage subsystem should be able to sustain at least 20 MB/sec (megabytes per second) while performing 4K random writes. Intel SSD's are the only reasonable way to achieve the level of performance and stability required. Other possibilities include RAID arrays (e.g., RAID 10 with 6 physical disks), hybrid storage systems that utilize large amounts of DRAM cache, etc. The use of these other forms of persistent storage in anything other than test environments is not supported.
The size of the persistent storage must also be considered if long term storage of logs is desired. The rXg may be configured to save utilization logs forever if desired. However, the size of the persistent storage must be large enough to support the desired length of time that the logs are to be stored, with a MINIMUM storage period of 1 year. The operator must commit 20 GB of USABLE storage for every 100 SULs per 1 year of data stored. Note that some space is lost when partitioning a drive due to manufacturer drive sizing and the need to carve some space out for SWAP. You must account for this when selecting a drive for your installation.
The rXg is designed to utilize multiprocessor and multicore hardware. For the purposes of testing, at least two "real" processors must be present in the hardware. For any production deployment with more than 100 SULs, at least four "real" processes must be present. By "real" processor we mean that the processors or CPU cores present on the system are actual processors or actual cpu cores and not hyper threaded or SMT virtual processors. Furthermore, all CPUs are assumed to be 64-bit capable (AMD64 / x86-64). Intel processors perform better for our application than AMD processors.
The rXg leverages all available RAM in order to achieve maximum performance. The more RAM that is available, the better the rXg will perform. For the purposes of testing, 4 GB of RAM is the minimum that the rXg will tolerate. Production environments must have at least 8 GB of RAM in order to be supported. In general, it is a good idea to put as much RAM into the hardware that will fit into the hardware.
The power budget required by the components used to build an rXg as specified by this document are dominated by the CPU. The SSD will typically draw less than 1W. The RAM may draw a few W per GB. The CPU will draw 100W or more. Entry level rXgs will require the 220W to 250W power supplies that are typically found in most basic server chassis. Power supplies for larger rXgs should be scaled accordingly.
The rXg is designed to operate in a high performance environment. CPU cores are constantly spinning and packets are always being moved in and out of RAM. Thus, cooling becomes an important issue. It is much easier to cool a physically larger machine than a smaller one. Thus it is highly recommended that the operator use 4U or larger chassis. While it is certainly possible to use deploy using 1U chassis, the density of 1U chassis usually requires that the unit be placed into a rack with sufficient airflow and cooling. Unless there is an extreme need for density, 1U chassis are to be avoided.
Many white box manufacturers sell reasonably priced "barebones" systems that have matched power supply, motherboard and chassis combinations with reasonable cooling. Examples include the Intel SC5650 and SC5660 as well as the Supermicro 5046 and 7046. One problem with "barebones" servers is that most only include one or at most two onboard Ethernet ports and thus PCI or PCI-e expansion cards must be acquired in order to have sufficient Ethernet interfaces.
For Minimum Hardware specifications, please use the license calculator.
The rXg traffic shaping mechanism is implemented as a set of HFSC queues. This mechanism automatically guarantees fair service across the end-user population. Consider the following example:
10 Mbps symmetric uplink
2 Mbps symmetric rate limit traffic shaping enforcement
Most end-users utilize the network at the enforced maximum rate limit for a small fraction of the amount of time that they are using the Internet. This enables oversubscription and oversubscription is the fundamental basis for RGN profitability in direct revenue models.
What happens when end-users start utilizing the network more or when the operator chooses to heavily oversubscribe? Well if you do not have an rXg running the network you will probably end up with random starvation. Most other traffic shapers will start dropping packets whenever the rate limit is reached and hope that CSMA/CD will just "work out." This works reasonably well for low oversubscrption ratios but fails miserably with highly oversubscribed networks. Some of the end-users will end up pulling 2 Mbps and others will end up with 15 Kbps (or 0 Kbps ... severe frustration in either case) in a highly oversubscribed network scenario unless you have an advanced traffic shaper like the rXg.
The rXg automatically enforces fair use of the uplink over the end-user population. If all 50 end-users were to try to pull 2 Mbps at the same time (and hence, the uplink is fully saturated), then each and every end-user would be allocated 1/50 of the 10 Mbps uplink (approximately 200 Kbps). If only a small fraction of the end-user population tries to pull 2 Mbps at any given time (and hence, the uplink is not saturated) then those end-users will pull 2 Mbps while the rest pull at whatever rate they can. This enforcement of fairness is fully automatic. If you specify a rate limit then fair use will be enforced automatically without any additional configuration.
Most of the improper traffic shaping configurations that I have come across are per-IP queuing setups with reasonable (like 2 Mbps) limits and small (like 256 Kbps) guarantees. This is an attempt by the operator to achieve what the rXg does completely automatically for you. The right way to go about doing the above is to simply create the 2 Mbps limit and leave out the guarantee. The rXg will automatically enforce fairness so no guarantee needs to be specified.
Given this information you are probably now wondering why there is a guarantee configuration option at all. Guarantees are only to be used when you want the rXg to be unfair. By default the rXg will be extraordinarily fair as described above... far more fair and far more capable than the vast majority of traffic shaping systems that you can buy. What if you have a server (e.g., a PBX) behind the rXg? Well perhaps you want that server to get an unfairly large amount of bandwidth allocated to it... this is when you want to use the guarantee.
For more information and to see pretty graphs describing how this works please look at the rXg integrated help page on traffic shaping.
Are you having trouble with SIP and NAT? Some SIP trunks only support a handful (or sometimes only one) VoIP clients behind NAT. Some others cannot deal with NAT at all. Still others fail to play nicely with span-NAT scenarios. RG Nets engineering has incorporated a SIP proxy rXg to help operators with SIP over NAT issues.
Look at the Services :: Advanced view to take advantage of this feature. Please note that the SIP Proxy requires configuration of a Transit Traffic Forward enforcement on the rXg or configuration of the VoIP client to use the rXg as an outbound proxy. The former approach is appropriate for high transient scenarios (enterprise guest access, hospitality, transit hubs, Internet cafes, etc.) whereas the latter is appropriate for fixed wireless broadband and other ISP scenarios.
The rXg can be configured to automatically download DPI signatures from a third-party site on a regular basis. This feature supports many of the common DPI rule and signature repositories such as the official Snort rules as well as the Emerging Threats and Emerging Threats Pro.
The use case possibilities are endless, but most of you asked for this feature for the purpose of deploying fully automated egress filtering to mitigate upstream ISP discontent and possible uplink disconnect due to zero day malware infection activity on publicly accessible networks. Look for "Remote DPI Signatures" under Identities :: Event Triggers and read the integrated manual entry to get started.
Force safe search to be enabled for all Google searches. Safe search is enabled by creating custom DNS for www.google.com per this article:
In the rXg, go to Services->DNS.
Create a new DNS Zone with the following fields: Name: www.google.com Domain Name: www.google.com Master Hostname: ns.www.google.com. Hostmaster Email: firstname.lastname@example.org
You will then need to create three new DNS records with the following fields:
# This is the DNS A record for ns.www.google.com
Dynamic Data: Uplink IP
Data: *** LEAVE THIS BLANK ***
# This is the DNS NS record for the www.google.com zone.
Name: www.google.com NS
Host: *** LEAVE THIS BLANK ***
Dynamic Data: *** LEAVE THIS BLANK ***
# This is the DNS A record that will resolve www.google.com to Google VIP for safe searches.
Host: *** LEAVE THIS BLANK ***
Dynamic Data: *** LEAVE THIS BLANK ***