Routing Information Protocol: Notes

Routing Information ProtocolI decided to write a follow-up to the article on RIP to clarify some issues. RIP version 1 does not support classless routing, whereas RIP version 2 does. To understand the implications of this, consider the historical classful network architecture. A class A network has an 8-bit network ID and the first octet is from 0 to 127. A class B network has a 16-bit network ID and the first octet is from 128 to 191. A class C network has a 24-bit network ID and the first octet is from 192 to 223. This system served its purpose in the early stages of the Internet, but it lacked scalability in the face of the rapid expansion of the network in the 1990s. The class system of the address space was replaced with Classless Inter-Domain Routing (CIDR) in 1993. CIDR is based on variable length subnet masking (VLSM) to allow allocation and routing based on arbitrary-length prefixes.

IP Classes
Class First Decimal Value Addresses Hosts per Network
Class A 1-128 1.0.0.0-128.0.0.0 16.7 Million
Class B 128-191 128.0.0.0-191.255.255.255 65534
Class C 192-223 192.0.0.0-223.255.255.255 254
Class D 224-239 224.0.0.0-239.255.255.255 Multicast addresses
Class E 240-255 240.0.0.0-255.255.255.255 Experimental addresses

Classless Networks

The advantages of classless networks should be obvious. Assume we currently have one class C network: 192.168.1.0. We have 100 hosts, and we would like to split our network into two separate networks, each with 50 hosts. We could set up a new network at 192.168.2.0. This would be overkill, however, since each network allows for 254 hosts (all permutations of 1s and 0s in the final octet except 0 and 255, as we don’t want addresses that are all ones or zeros). A potentially better solution would be to divide 192.168.1.0 into two separate subnets. To do this, we move our netmask two bits to the right. Doing this gives us 4 new combinations, but 2 of them are useless – 00 and 11 – so we are left with 01 and 10 as the rightmost bits of our two subnets. The subnet masks for our networks are 192.168.1.128 and 192.168.1.192, or in CIDR notation, 192.168.1.128/26 and 192.168.1.192/26.


Problems with RIP Version 1

Where it becomes a problem is if we are running RIP version 1. Let’s assume we have a router (Router A) for our first subnet (192.168.1.128) and a router (Router B) for our second subnet (192.168.1.192). Let’s further assume that there is a third router (Router C) with a path to both routers. RIP version 1 uses classful subnetting, so it will look at the first octet to determine what the subnet mask is. In this case, it will see that the first octet is 192, and assume it is a class C network with a subnet mask of 255.255.255.0. It will update the routing tables to show Router A and B both with a network ID of 192.168.1.0. Router C will then assume that it has two paths to the same network (instead of paths to 2 separate networks), and, as a result, if it wants to send an update to, say, 192.168.1.194 (which is on Router B’s subnet), it may send the update to Router A instead.

Since we probably don’t want to abandon classless networking, the solution is to use RIP version 2, or RIPng (an extension of RIP version 2). Each supports classless networking and therefore will allow us to create new subnets.


External Links:

Classless Inter-Domain Routing at Wikipedia

pfSense Virtual IP Addresses: Part Two

In the previous article, I covered setting up pfSense virtual IP addresses with Proxy ARP and CARP. In this article, I will cover pfSense virtual IP addreses with IP Alias and Other types.

pfSense Virtual IP Addresses: IP Alias

pfSense virtual IP addreses

Setting up a pfSense virtual IP address with IP Alias in pfSense 2.0.

IP aliasing is the ability to associate more than one IP address to a network interface. With it, one node on a network can have multiple connections to a network, each serving a different purpose. In a sense, it is the reverse of some of the other scenarios envisioned with virtual IP addresses, in which traffic for one IP address can be directed to several different nodes. IP Alias is:

  • New to pfSense 2.0 (and later)
  • Can be used or forwarded by the firewall
  • Allows entire IP addresses to be added to an interface
  • Works on Layer 2 (Data link layer)
  • Can be in a different subnet than the real interface IP
  • Will respond to a ping request if allowed by firewall rules
  • Can be stacked on top of a CARP VIP to bypass VHID limits and lower the amount of CARP heartbeat traffic. Stacked IP Alias VIPs will synchronize via XMLRPC.
  • Can be used with CARP to add additional subnets to CARP, e.g. Add one unique IP Alias from the new subnet to each node, then add CARP VIPs. Must be added to each node individually as these will not synchronize via XMLRPC or else an IP conflict would occur.


To set up a VIP using IP Alias, start at Firewall -> Virtual IPs and once again click on the “plus” button to add a new virtual IP address. Select “IP Alias” as the “Type” with the radio buttons at the top. For “Interface“, select “WAN” (it should be the default). At “IP Addresses“, type an address at “Address” (everything else should be grayed out). At “Description“, add a description if desired. Click on the “Save” button to save the changes, and then on the next screen, click on “Apply changes” if necessary.


pfSense Virtual IP Addresses: Other

“Other” is the only option of the four provided for VIPs in pfSense 2.0 that can be used if routed to the firewall without needing ARP/Layer 2 messages. Its properties are:

  • Can only be forwarded by the firewall
  • Can be in a different subnet than the interface
  • Cannot respond to pings
  • Can be added individually or as a subnet to make a group of VIPs (As of 2.1)
  • Can be used with CARP, e.g. subnet routed to external CARP VIP

Notably, both IP Alias and Other can be used for clustering (master firewall and standby failover firewall).
To add a virtual IP of type “Other”, again navigate to Firewall -> Virtual IPs and click the “plus” button to add a new virtual IP address. At type, choose “Other” with the radio buttons. At “Interface“, select “WAN” (the default). At “IP Addresses“, type an address at “Address” (all other options are grayed out). At “Description“, add a description if desired. Then press “Save” to save the changes and press “Apply changes” if necessary.

As you can see, setting up pfSense virtual IP addresses is almost trivially easy. The more difficult task is deciding which type of VIP is suited for your requirements and choosing accordingly. The official pfSense documentation site has a table which lists some of the features of the different pfSense VIP types, and I am reprinting it here:

VIP Features Table

VIP Features
VIP Type Version NAT Binding ARP/L2 Clustering In Subnet Subnet Mask ICMP Single/Group
CARP 1.x+ Yes Yes Yes Yes Yes Yes Yes Single
Proxy ARP 1.x+ Yes No Yes No No n/a No (1) Either
Other 1.x+ Yes No No Yes (2) No n/a No (1) Either
IP Alias 2.0+ Yes Yes Yes See Notes No No Yes Single

1: ICMP Column represents responses from the firewall itself without NAT. With 1:1 NAT, any VIP will pass ICMP through to the target device. On 2.1+ ICMP can also be used as a protocol in port forward entries.
2: “Other” type VIPs are for routed subnets, and CARP is irrelevant, so they work

External Links:

What are Virtual IP Addresses? at doc.pfsense.org

Firewall Configuration: Aliases

One of the main functions of any firewall is to carry out port forwarding and firewall security rules, and pfSense, like any firewall, is capable of performing these functions, which can be found on the “Firewall” menu of the pfSense web interface. In this article, the first in a series covering pfSense firewall configuration, I cover creating an alias in pfSense.

Firewall Configuration: Aliases

Firewall configuration

Firewall -> Aliases page in the pfSense web GUI.

A good description of aliases can be found from the pfSense web GUI page for Firewall -> Aliases:

Aliases act as placeholders for real hosts, networks or ports. They can be used to minimize the number of changes that have to be made if a host, network or port changes. You can enter the name of an alias instead of the host, network or port in all fields that have a red background. The alias will be resolved according to the list above. If an alias cannot be resolved (e.g. because you deleted it), the corresponding element (e.g. filter/NAT/shaper rule) will be considered invalid and skipped.

Firewall configuration

Here, I create a sub-alias called “allhosts”.

With this in mind, here is how you can set up an alias in pfSense. First, browse to Firewall -> Aliases. Click the “plus” button to add a new alias. The first field is “Name“. Here, you should type in a name for the alias. At “Description“, you can add an optional description. Next, select an alias type at “Type“. Depending on which type you choose (Host, Network, Ports, URL, or URL Table), you will have different fields which must be filled out to complete the configuration. Selecting “Host(s)” as an a type allows you to create an alias that holds one or more IP addresses. Selecting “Network” allows you to create an alias that holds one or more networks (i.e. ranges of IP addresses). Selecting “Ports” allows you to create an alias that holds one or more ports. Selecting “OpenVPN Users” allows you to create an alias that holds one or more OpenVPN usernames. Selecting “URL” allows you to create an alias that holds one or more URLs. And selecting “URL Table” allows you to create an alias that holds a single URL pointing to a large list of addresses. This can come in handy if you need to import a large list of IP addresses and/or subnets. When you are done entering the configuration data for whichever type you selected, press “Save” to save the changes, and if necessary, press “Apply changes” to apply the changes.


Firewall configuration

An example of using an alias in adding a NAT port forwarding rule.

It is also possible to set up sub-aliases, which potentially make firewall management even easier. For example, if we have three hosts – host1, host2, and host3 – all of which must connect to our FTP server. We could set up a sub-alias called allhosts composed of host1, host2, and host3.

Once you have added an alias, you can use it wherever there is a red text box in the pfSense GUI. Just type the name of the alias and it can be invoked.

That covers firewall configuration of aliases under pfSense. In a future installation, I will cover NAT and firewall rules.


External Links:

Aliases from the pfSense wiki at doc.pfsense.org

pfSense Setup: Part Four (Setting up a DMZ)

DMZ

The optional interface configuration page in the pfSense web GUI (which is similar to the WAN and LAN config pages).

In the first three parts, I covered booting and installing pfSense, general configuration options in the pfSense web GUI, and configuring WAN and LAN interfaces (also with the web GUI). In this part, I cover using an optional interface to create a DMZ.

In networking, a DMZ (de-militarized zone) is a place where some traffic is allowed to pass and some traffic is not. The area is separate from the LAN and WAN. In simple terms, a DMZ looks like this in relation to the rest of the network:

Internet traffic | <- DMZ <- LAN

Unsafe Internet traffic is allowed to enter the DMZ, but not the LAN. To configure it, we will need an optional interface.

Configuring the DMZ

From the web GUI, browse to Interfaces -> OPT1. If “Enable Interfaces” isn’t checked, check it. Set “Description” to DMZ. Under “Type”, choose “Static” as the address configuration method. For “IP address”, enter an IP address and the subnet mask (the subnet should be different than the subnet for your LAN). For example, if your subnet for the LAN is 192.168.1.x, it could be 192.168.2.x for the optional interface.

For “Gateway”, leave this option set to “None”. The last two options are “Block private networks” and “Block bogon networks”. Ensure that these two options are unchecked; we don’t want the system to block access from the Internet to the DMZ. Finally save changes by pressing the “Save” button.


Now that the DMZ is configured, your DMZ will allow WAN access. Your DMZ will also allow access from the LAN, but it won’t be permitted to send traffic to the LAN. This will allow devices on the Internet to access DMZ resources without being able to access any of your LAN. This could be useful, for example, for setting up an e-mail or FTP server.

You could now attach a switch to your DMZ interface. This would enable you to connect multiple machines to the DMZ.

External Links:

Setting Up a DMZ in pfSense


The Rest of the Guide:

Part One (installation from LiveCD)

Part Two (configuration using the web GUI)

Part Three (WAN and LAN settings)

Ad Links:


© 2013 David Zientara. All rights reserved. Privacy Policy