netio: A Network Benchmark Tool

netio

netio in action under pfSense 2.1.5.

netio is a network benchmark utility for OS/2 2.x, Windows, Linux and Unix. It measures the net throughput of a network via TCP and UDP protocols using various different packet sizes. For netio to run a benchmark, one instance has to be run on one computer as a server process, while another instance is used on another computer to perform the benchmark. Starting with version 1.20, multi-threading support is required. While this does not affect anyone using the program under Linux or BSD, it did mean that DOS was no longer supported.

netio: Installation and Use

To install netio under pfSense, navigate to System -> Packages, and scroll down to netio in the list. Press the “plus” button to begin installation, and on the next screen, press “Confirm” to confirm installation. netio should complete installation within a few minutes.


Once netio is installed, there will be a new item on the Diagnostics menu called “netio“. If you navigate to it, you will find two tabs: “Client” and “Server“. The “Client” tab, appropriately enough, is to configure netio to run as a client, while “Server” will allow it to act as a server. On the “Client” tab there are two settings: “Server” (for the IP address or hostname netio will connect to) and “Port” (for the port that netio will connect to). On the “Server” tab, there is only one field: “Port“, to specify the port netio will bind to (the default is 18767). Press the “Save” button at the bottom to save settings.

Running netio at the command prompt under Windows 8.1.

Whether you run netio as a client or server, netio requires another node with which to connect. As a result, you are going to have to download netio, which you can do from the official netio site. The zip file contains both the source code and binaries for several platforms, including Windows, Linux, BSD, OS/2 and Mac OS X. Select the right binary for your platform and run netio from your system’s command prompt/shell.

At the risk of stating the obvious, if you are running netio under pfSense as a server, then you want to be running it under the other system as a client, and vice-versa. To test netio, I decided to run it under pfSense as a server (I kept the default port and just pressed “Save”). In Windows, I typed:

win32-i386 -t 192.168.2.1

where win32-i386 is the name of the windows executable, -t specifies the TCP protocol, and 192.168.2.1 is the IP address of the server (my pfSense box). The output of netio can be seen in the screenshot on the right.

And here we are running it under Linux Mint 17.

One problem with this program is that it seems if you connect with one protocol (e.g. TCP), you cannot connect to the server again with another protocol (e.g. UDP). If you try to do this and you get an “error code 10060” message, try restarting the server and then attempt a client connection a second time.

Did I mention that netio supports several platforms? This last screenshot shows what happened when I ran netio under Linux on an old IBM Lenovo M51 running Mint Linux 17. The only shortcoming is that the binary for Linux is version 1.30 of the program, not the latest version (1.32). Thus if you want the latest version under Linux, you’ll have to compile it yourself.


External Links:

The official netio site

Traceroute Utility in pfSense

Traceroute Explained

Traceroute

The traceroute command in action under Windows.

In computer networking, traceroute is a computer network diagnostic tool for displaying the route and measuring transit delays of packets across an Internet Protocol network. The history of the route is recorded as the round-trip times of the packets received from each successive host in the route; the sum of the mean times in each hop indicates the total time spent to establish the connection. Ping, on the other hand, only computes the final round trip time to the destination, not the intermediate times. It is defined in RFC 1393.

Traceroute sends a sequence of three ICMP echo request packets addressed to a destination host. The time-to-live (TTL) value, also known as hop limit, is used in determining the intermediate routers being traversed towards the destination. Routers decrement packets’ TTL value by one and discard packets whose TTL value has reached zero. When a packet is discarded because its TTL value reached zero, the router sends an ICMP Time Exceeded message back to the source. Traceroute, on the other hand, sends packets with gradually increasing TTL value, starting with a value of 1. The first router receive the packet, decrements the TTL value and drops the packet. The router sends an ICMP Time Exceeded message back to the source. When the source receives this ICMP message, it sends out a new set of packets with a TTL value of 2. This way, traceroute is able to build a list of routers that the packets traverse, until the destination is reached and returns and ICMP Echo Reply message. The timestamp values returned for each router along the path are the latency values, typically measured in milliseconds.


While traceroute under Windows (invoked with the tracert command) uses ICMP and the original specification called for using ICMP, the command did not initially work well because of the interpretation of RFC 791 (the Internet Protocol RFC) by routing equipment vendors. Thus to fix this, Van Jacobson wrote a variant to traceroute that worked so well and reliably, it was ported to many systems and used as the default. The Van Jacobson version used outbound UDP datagrams from the host running traceroute instead of ICMP. This was the default on any system using the Van Jacobson version of the command, including most BSD and UNIX-type systems. Systems using the Van Jacobsen version also use destination port numbers ranging from 33434 to 33534. The utility under Unix usually has an option to instead use ICMP echo request. If a network has a firewall and operates both Windows and Unix systems, both protocols must be enabled inbound through the firewall for traceroute to work and receive replies. Some traceroute utilities use TCP packets (e.g. tcptraceroute or layer four traceroute).

Using Traceroute in pfSense

Traceroute

Using traceroute in the pfSense web interface.

To use traceroute from the pfSense web interface, first browse to Diagnostics -> Traceroute. At “Host”, set the host to the IP address or hostname of the machine you are trying to trace. At “Maximum number of hops”, set a maximum number of hops for the trace to traverse. At “Use ICMP”, you can check this check box (if not, traceroute will use UDP). Then press the “Traceroute” button to perform the function. The output of the traceroute function will appear below the button.

Note that traceroute can sometimes take a long time to complete. You can click the browser’s stop button at any time to cancel the traceroute and display the results. It should be noted that multi-WAN is not supported by this utility.


External Links:

Traceroute at Wikipedia

How Traceroute Works at InetDaemon.com

Why traceroute sends UDP packets and not ICMP ones? from Stack Overflow

Traceroute at doc.pfsense.org

Port Forwarding with NAT in pfSense

Firewall Configuration: NAT port forwarding

Firewall -> NAT configuration page in the pfSense web GUI.

In computer networking, Network Address Translation (NAT) is the process of modifying IP address information in IPv4 headers while in transit across a traffic routing device. In most cases, it involves translating from the WAN IP address to the 192.168.x.x addresses of your local network. In this article, I will describe how to set up NAT port forwarding.

NAT and firewall rules are distinct and separate. NAT rules forward traffic, while firewall rules block or allow traffic. In the next article, I will cover firewall rules, but for now keep in mind that just because a NAT rule is forwarding traffic does not mean the firewall rules will allow it.

NAT Port Forwarding

NAT port forwarding rules can differ in complexity, but in this example, let’s assume we set up an Apache server at 192.1.168.125 on the local network, and we want to direct all HTTP traffic (port 80) to that address. First, browse to Firewall -> NAT. The options are “Port Forward“, “1:1” and “Outbound“. Select the “Port Forward” tab. Click the “plus” button in order to create a new NAT port forward rule. “Disable the rule” and “No RDR” can be left unchanged. For “Interface” you can choose WAN and LAN; we are concerned about incoming requests from the Internet, so you can keep it as WAN.


For “Protocol”, there are five choices: TCP, UDP, TCP/UDP, GRE, and ESP. TCP stands for Transmission Control Protocol, and is the transport level protocol of the Internet protocol suite. This is usually what we want to use. Next is UDP, or User Datagram Protocol, another transport level protocol which is also part of the Internet protocol suite. It is suitable for purposes where error checking and correction are either not necessary or are performed in the application. GRE stands for Generic Routing Encapsulation, a tunneling protocol that can encapsulate a wide variety of network layer protocols inside virtual point-to-point links. It can be used, among other things, in conjunction with PPTP to create VPNs. ESP stands for Encapsulating Security Payload, a member of the IPsec protocol suite which provides authenticity, integrity and confidentiality protection of packets. In this port forwarding scenario, you can leave the protocol unchanged (TCP).

Firewall Configuration: NAT

Adding a NAT port forwarding rule.

For “Source“, you can specify the allowed client source. Typically you can leave it as “any”, but there are several choices: “Single host or alias“, “Network“, “PPTP clients“, “PPPoE clients“, “L2TP clients“, “WAN subnet“, “WAN address“, “LAN subnet“, and “LAN address“. In this case, you can leave the default (any) unchanged.

For “Source port range“, we want to redirect HTTP traffic (port 80), so choose HTTP for the from and to drop-down boxes. “Destination” offers the same choices as “Source” and can be left unchanged. “Destination port range” should be changed to HTTP for the from and to drop-down boxes. For “Redirect target IP“, specify the web server the traffic to be forwarded to (in our case, 192.168.1.125). For “Redirect target Port“, choose HTTP. Next is “No XMLRPC Sync“; enable this option to prevent this rule from being applied to any redundant firewalls using CARP. This option can be left unchecked now. “NAT Reflection” can be enabled or disabled, usually it is disabled. “Filter Rule association” will automatically create a firewall rule and associate it to this NAT rule. Check this box to avoid having to create a separate firewall rule. Add a description if you wish, and press “Save” to save the changes. The port forwarding rule set up should now be in effect.

NAT Port Redirection

In this case, we passed traffic from port 80 on the source to port 80 on the destination, which is the classic port forwarding scenario. But there’s no reason you can’t redirect traffic to a different port. There are two reasons you might want to do this:

[1] Security: A good way to thwart hackers is to put services on non-standard ports. For example, everyone knows the standard port for FTP is 21, but an outsider is unlikely to find your FTP server if you place it on port 69, or better yet, an even higher port number (e.g. 51782). The same can be said of SSH. Users will have to know the port in order to access it.

[2] Single Public IP Address, more than one computer with the same services: Smaller networks with only a single public IP address may be stuck if the want to expose a lot of public services. For example, imagine that we want to have two separate FTP servers, but on two separate computers. With port redirection, we create two different NAT rules: the first rule will redirect port 51782 to port 21 on FTPServer1, and the second will redirect port 51783 to port 21 on FTPServer2. We can then remote into two separate FTP servers on two different computers using the same IP address.


External Links:

Port Forwarding Troubleshooting at doc.pfsense.org

© 2013 David Zientara. All rights reserved. Privacy Policy