The term “forwarding” may be used to describe some different techniques. (At least some of these uses may not be very precise/technical/proper.) There may also be other names provided for these other methods of traffic handling: See Routing Traffic for more details about some of the other techniques.

Basic Traffic Forwarding/Routing


This is commonly performed by a device called a “router”.

This section is mainly about forwarding “layer three” network traffic, such as IPv6 and IPv4 packets (based on the IP addresses). When software is analyzing “frames” of “layer 2” traffic (such as Ethernet traffic) to determine whether or not to pass on traffic (by analyzing the MAC addresses to make decisions), the term generally used is bridging.

Forwarding involves a system which accepts traffic which may have a destination routed (IP) logical address that is not on the same network as the destination logical link layer (EUI-48 MAC) physical address. So, a clear distinction is being made here between a (layer 3) “logical” address (such as an IP address used by the IP protocols of IPv6 and IPv4), and a (layer 2) “physical” address such as a MAC address (which is more commonly focused on when discussing protocols such as Ethernet).

To clarify that with an example, an IP packet may have a destination IP address of a device which is not part of the local subnet, but that IP packet may be forwarded by a router on the local subnet. The reason the router will receive that traffic (to be able to forward it on) is because the IP packet is included as part of an Ethernet frame that does have a destination address of a device (presumably the router) which is on the local network.

The device on the local network will verify accept the Ethernet frame and will check the IP and notice the destination address of the IP packet. If forwarded is enabled, the IP packet may be forwarded to another network to help get the packet to the desired destination.

When a computer/device is forwarding routable traffic, it checks the “destination” logical address. If the destination address is not assigned to the NIC that received the traffic, and if forwarding is enabled, then the computer determines which NIC is used to communicate with the destination address. If the traffic needs to be forwarded (and isn't blocked by firewall rules), the computer may create and send a new frame that contains the same IP packet. If that new frame is being sent on another NIC, this process can effectively allows the traffic to reach one or more additional devices.

(If forwarding is not enabled, the typical action is for the packet to be discarded because the destination address doesn't match the device which is processing the IP packet.)

With at least some implementations, such traffic may not work until forwarding is explicitly enabled. (Otherwise, the device receiving the traffic does not forward on traffic with a destination routed (IP) address that is not on the device. This, at least in many cases, probably means such traffic is simply ignored.)

In at least some implementations, it may be possible to forward some types of traffic while not forwarding other types of traffic. (For example, with OpenBSD, there are separate sysctl values for net.inet.ip.forwarding and net.inet.ip.mforwarding and net.inet6.ip6.forwarding and net.inet6.ip6.mforwarding.) Such control may be available by just using options specifically about forwarding traffic. (There may also be other options that may further control now network traffic is handled.)

An additional possibility that may affect what options are available is that software on a device may interfere with forwarded traffic. For example, in addition to enabling forwarding, if a firewall is running then the firewall may block the forwarding (unless the firewall is configured to forward the traffic). (With a common OpenBSD setup, this means that in addition to the sysctl values, pf rules may need to be applied. (If NAT isn't needed, perhaps using pf is also not needed to effectively enable forwarding?)

[#wypernic]: A rule: Per NIC, traffic must be either in or out, not both

(The following rule probably won't be an issue with simple cases. However, it can be impactful if people are trying to improve things by designing and trying to implement some sort of elaborate, fancy traffic routing.)

A common rule of forwarding traffic is that the traffic must not be forwarded out the same device that the traffic was received on. This initially makes full sense: other devices on the same link will have already received the traffic, and so won't need another copy. However, this may also apply to traffic even if the device receiving the (link layer) traffic applies translation. Other items on the link may not have received the traffic with the translated address, but a device implementing this rule may refuse to forward on the translated traffic.

(This can be a problem: It can be worked around through a complicated setup involving forwarding traffic out a virtual interface which results in the traffic being received on another virtual interface. In this case, the device may not keep track of the traffic close enough to realize that the translated traffic was received before. In such a case, the ignorant implementation of firewall software that handles this traffic may allow the traffic. However, this sort of elaborate work-around is not straightforward traffic handling.)

[#fwtrfhow]: Implementations (how to forward traffic)
Enabling Traffic Forwarding in OpenBSD
Seeing current values of settings

This may not be strictly necessary, but sometimes it's nice to know how things were before setting how things are about to be.

To see the list of sysctl values related to forwarding, run:

sudo sysctl | grep -i forwarding

This may provide output such as the following:


That shows the sysctl options and the current values that are set. Another way to view the current values set for just the Unicast forwaridng options for IPv6 and IPv4 packets is to run the following two commands:

sysctl net.inet.ip.forwarding
sysctl net.inet6.ip6.forwarding
Making changes for the short term

To change the values temporarily, to have immediate effect, run these two commands:

sudo sysctl net.inet.ip.forwarding=1
sudo sysctl net.inet6.ip6.forwarding=1

The latter command may show some output such as:

net.inet6.ip6.forwarding: 0 -> 1

That output shows the old value and the new value: Those values could be the same. Verifying the changes can be done without superuser access: To verify that the values took place, run these two commands shown above, but without the equal signs and without the values after the equal signs. (Running the commands as a superuser is not needed when changes aren't being made, so you may simply run “ sysctl net.inet6.ip6.forwarding ” for IPv6, and/or drop the references to 6 to get information about IPv4 traffic handling.) The output may show the exact parameter that was passed to the sysctl command. For example, for IPv6, the results may look like:

Making long term changes
To make the changes occur long term, back up /etc/sysctl.conf, see if that file currently has any such sysctl values that need to be changed, and then place the desired sysctl values into that file. (Details on these steps are provided next.)
Backing up the /etc/sysctl.conf file

This is simply to back up the file that is about to be changed.

Quick backup guide for files that are about to be changed
ls -td1 /origbak/ver* | head -n 1

(If the output of this command is “ls: /origbak/ver*: No such file or directory” then /origbak/ver1 may be used. If the output had said “/origbak/ver36” then we would be using the next higher number: “/origbak/ver37.”)

In this example code, we will be using /origbak/etc/ver2/.

mkdir -p /origbak/ver2/etc
chmod go-rwx /origbak/ver2/etc /origbak/ver2 /origbak
cp -p /etc/sysctl.conf /etc/pf.conf /origbak/ver2/etc/.

(Note: perhaps an easier way to back things up would be to use the cpytobak program.)

Then, the rest of the following example is simply an example of how to set a sysctl. (Be sure not to forget the “ -a ” parameter!)

cpytobak /etc/sysctl.conf
echo net.inet6.ip6.forwarding=1 | sudo -n tee -a /etc/sysctl.conf
echo net.inet.ip.forwarding=1 | sudo -n tee -a /etc/sysctl.conf

Note that changing that file does not cause the new forwarding rules to become applied until after the system reboots. For changes to happen more immediately, see the section on making immediate changes that are temporary. (The changes described in that section are considered temporary since they only last until the system is rebooted, or until other immediately-applied changes are implemented.)

Recall that firewall software may need to be configured (with firewall rules) and enabled in order for traffic to be getting forwarded in the desired fashion. On a new installation of OpenBSD, simply enabling forwarding may not be enough to really get forwarding to work. Running the firewall software may also be needed. (Newer versions of OpenBSD may be running that software automatically.)

[#fwtrfmsw]: Enabling traffic forwarding in Microsoft Windows
Overview of requirements

This is built into multiple operating systems, including consumer operating systems. Many professionals are familiar with some Microsoft software (built into at least some operating system products) called “Routing and Remote Access”, and may think that RRAS is needed to support this feature However, simple traffic forwarding is available without requiring the RRAS service. This feature is documented to work with Windows XP and newer, and Win2K, and possibly NT. (Windows Server 2000 documentation showing IPEnableRouter, MS KB Q230082: “How To Enable TCP/IP Forwarding in Windows 2000” and MS KB Q315236: “How to Enable TCP/IP Forwarding in Windows XP”. Blog about Hyper-V and routing indicates that RRAS is not needed.

This has been known to require a reboot of the computer (and not just logging off of the user). (That was with Windows Server 2008 SP1, which did have RRAS installed.) However, article on Eabling IP Packet Forwarding says “Sometimes you have to restart or log out of Windows to enable the modification.” So perhaps a reboot is not always required?

How to enable routing in Microsoft Windows
Registry interaction

This involves changing a registry key. Command line options are available. Inside the HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters key is a value called IPEnableRouter which is a DWORD type and needs to contain the data of: 1. Using information from the section about editing the registry from the command line, after viewing and saving and then deleting the old value, the desired new value can be added with:

REG ADD HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters /v IPEnableRouter /t REG_DWORD /d 1
Check if this routing option has been effectively enabled yet

Some testing indicates a likelihood that the routing is not enabled, although it may be worth checking so that the remaining steps may be able to be skipped.

IPConfig /ALL | FIND /I "IP Routing Enabled"
If not yet enabled: Perhaps: try logging off (and then re-check)
If not yet enabled, reboot

Some experience does seem to suggest that this seems likely that this may be the case.

Actually, it seems likely that there is probably a slicker way of doing this. e.g. Perhaps only a service needs to be restarted? page says “Once you start network support, IPEnableRouter is reset to 0.” (Perhaps that is a hint on how to get this option to be sufficiently enabled?)

However, at the time of this writing, the author of this text has not yet located any such slicker way. So, for the time being, reboot. Instructions for doing this may be found in the section about shutting down, and/or restarting, a computer.

After the restart, it might make sense to re-check that the option is reported as being enabled, and to do this before proceeding to the next step.

Test/verify functionality

In an environment where system states are being documented, which is generally sensible for any business or similar organization, enabling this forwarding is likely a system change that is worthy of being documented.

[#rrastrfw]: An alternative approach: Using RRAS for traffic forwarding (and NAT)

Another approach may be to use RRAS. An advantage to using this approach is that, in addition to traffic forwarding, using RRAS may support Network Address Translation (“NAT”), if that is desired.

Installing Routing (feature from RRAS)

The first step to using RRAS (on a computer with a freshly installed copy of the operating system) is to install RRAS.

Note that installing RRAS will require rebooting the operating system. Also, uninstalling RRAS will also require rebooting the operating system.

With Windows NT 4.0, this was a download. Newer operating systems may have this as a role, or part of a role. With Windows Server 2008, this is part of a role called “Network Policy and Access Services”. (See , so details are provided in the section about Installing Roles and Features in Microsoft Windows Server operating systems.

The following screenshots were taken from an installation from Windows Server 2008.

Add Roles Wizard Choose “Network Policy and Access Services” Choose “Next >”. On the “Introduction to Network Policy and Access Services” window, simply press “Next >” again.

Some notes: RRAS by default is rather inactive until it gets configured. Also, by default it processes IPv4 traffic but not IPv6 traffic

After RRAS is installed, the Server Manager may look like it is complaining about the newly installed “Network Policy and Access Services” role. Clicking on “Go to Roles” may go to the Roles page that clarifies slightly, showing that Server Manager may be complaining about a “Network Policy and Access Services”-related System Service, or two. ([Server Manager showing Hyper-V and “Network Policy and Access Services”, and complaining about one System Service related to routing], [Server Manager complaining about a couple of system services related to “Network Policy and Access Services”], [Server Manager complaining about a System Service or two (scrolled down further)]) Likely RasMan (a.k.a. “Routing Access Connection Manager”) will have a “Manual” “Startup Type” and could be “Running”, in which case the related services may be reported as “1 Running, 1 Stopped.” However, on a re-installation of RRAS, it may have a status of being “Stopped”. Also, there may be “RemoteAccess”, a.k.a. “Routing and Remote Access”, which may have a “Startup Type” of Disabled, and so it is quite unsurprising that its status is “Stopped”. This is all normal, and not a concern. ([Both RRAS services stopped])

The Administrative Tools now has “Routing and Remote Access” which runs: %SystemRoot%\system32\rrasmgmt.msc (which then runs "C:\Windows\system32\mmc.exe" "C:\Windows\system32\rrasmgmt.msc")

IPv6 support
“What's New in Routing and Remote Access in Windows Server 2008”: “IPv6 support” states, “By default, Routing and Remote Access is configured to accept only Internet Protocol version 4 (IPv4) connections. In Windows Server 2008, you can use the Routing and Remote Access Microsoft Management Console (MMC) to configure IPv6 routing and connections.” (The referenced page at TechNet providerse further instructions.)
Adding a desired configuration

To keep things simple, these directions will assume that there is no desired pre-existing configuration. Right click on the name of the server.

[RRAS option in Administrative Tools (from an 800x600 screen)])

[UAC for MMC])

[UAC for RRAS])

[“Welcome to Routing and Remote Access”])

Deleting any pre-existing configuration

This probably will not be necessary. However, if RRAS had previously been installed and then uninstalled, without removing the old configuration, this could conceivably be necessary.

If “Configure and Enable Routing and Remote Access” is greyed out, then choose “Disable Routing and Remote Access” in order to lose the old configuration

Creating a new configuration

Check out the list of potention “Action”s: Either right-click on the name of the server, or select the server and then check out [RRAS's Action menu for a server (when the server is still unconfigured)].

Choose “Configure and Enable Routing and Remote Access”. On the welcome screen, choose “Next >”. Then choose “Custom configuration” and select “Next >”.

[“Routing and Remote Access Server Setup Wizard” Welcome screen]: choose “Next >”

[“...”]: The general recommendation is to choose “Custom configuration”. That will show more options, and easily allows installation of any combination of multiple roles at once (if desired).

[“Custom Configuration” properly selected]

[“RRAS services that may be configured]

Now comes the slightly tricky part: Actually choosing what roles are desired. There are multiple possible different answers that may be correct in different circumstances, so this will largely depend on what is being attempted. e.g. [“NAT” and “LAN routing” selected] or [“LAN routing” selected].

[“NAT” and “LAN routing” selected]. [“LAN routing” selected].

[“NAT” and “LAN routing” selected]. Select Finish.

“The Routing and Remote Access service is ready to use.”. A “Start service” button is selected. Do go ahead and use that button (instead of the other button, “Cancel”). [RRAS starting up RRAS's service]. [RRAS service finishing initialization].

[RRAS screen after a Configuration has been made].

At this point, the system should be ready to test out the results and/or make further changes to the configuration.

[#ciostrfw]: IOS traffic forwarding

Note: Cisco IOS is something that a lot of people have received customized training with. People unfamiliar with IOS may want to start with an introduction to using IOS. Resources: seeing Cisco IOS output, introduction to Cisco, Cisco IOS basic usage guide.

A router using IOS forwards IPv4 traffic by default. (No IPv4 traffic will be forwarded until basic configuration has been performed, including setting IPv4 addresses, has been complete. However, once that is done, no special command is needed to tell the router than IPv4 should be getting forwarded according to the device's routing tables.)

For IPv6, traffic forwarding is disabled until the router is configured to enable IPv6 traffic forwarding, which is done with this command:

ipv6 unicast-routing
If traffic still isn't working

There may be multiple causes of traffic not working. Realize that if forwarding was just enabled, then that step was probably one of the necessary steps, so it was worthwhile even if the traffic isn't yet flowing completely as desired. The next step is likely to identify and rectify other causes that may be preventing traffic from flowing as desired. Here may be some of them.

[#pvadyout]: Using acceptable addresses

Another possible cause of traffic not seeming to flow as desired might be that the traffic is being rejected. If the newly installed operating system is using an acceptable address, such as a public IP address, and other computers are not using an acceptable address, then the newly installed operating system may be forwarding the traffic but the traffic may be rejected because a private IP address is being used. If this is the case, then the rejected traffic may be visible when monitoring the outgoing traffic of the network interface, and noticing both an unacceptable address and a lack of return traffic.

One solution is to assign other computers with accepted addresses (which may be infeasible with IPv4, due to a scarcity of publicly accessible and easily routable IPv4 addresses). The section about network addressing may have details about how to implement new addresses.

Another solution may be to use NAT. This solution is rather strongly opposed, particularly when using IPv6, by some people. This sort of functionality has often been implemented by IPv4 firewalls, so details are in the section about firewalls: subsection about NAT.

[#annewnet]: Remembering both directions (a.k.a.: announcing new subnets)

Remember to handle traffic routing in both directions. Many communications over the Internet involve two-way connectivity, including TCP handshakes and ICMP (since receiving ICMP replies are generally desirable). For two machines to successfully communicate, traffic from both needs to be successfully routed all the way from one machine to another. This is a standard rule of networking, but is being explicitly mentioned because of a violation of that rule may frequently exist during part of the process of adding a new subnet. A device, which could very possibly be an older device that has been serving equipment for quite a bit of time, may not know how to route traffic to a newly created subnet. Testing two-way communications, from equipment on the newly created subnet, will find that communication is not working. The issue might not be with the newly created subnet, but rather an entirely different device.

An example, to describe why this is needed

For example, let's imagine we have a brand new subnet. On this subnet is a standard (physical or virtual) “computer”. (This computer is only connected to the new subnet.) This computer is going to want to be able to communicate with a pre-existing network, which will be called the “main network”. To do so, this computer will be trying to communicate with a gateway device. (It is very possible that this “gateway device” is the “default gateway” for the computer that is only connected to the new subnet.) This gateway device will have multiple NICs and is expected to serve as a traffic forwarding device.

The traffic forwarding device's IP address is used as the “default gateway” for the standard computer. So, the computer communicates to this traffic forwarding device, and that device sends the traffic to the main network.

Now, what if this traffic is really meant for a remote system on the Internet? The traffic will go to the “default gateway” of the main network. (Since settings for a “default gateway” are subnet-wide, the “default gateway” on the main network can be a completely different device than the traffic forwarding device that was the “default gateway” for the new subnet.) So, the default gateway receives traffic from an unexpected subnet. That does not necessarily need to be a problem: the main network's default gateway may receive and/or forward the traffic. However, if the main network's default gateway doesn't know about the new subnet, it won't know to send traffic back to the initial “traffic forwarding device”. The result is that replies may not be seen. (Since TCP requires dual-direction communication to establish a connection, no TCP traffic will work in such a scenario.)

The necessarily solution is that the main network's “default gateway” needs to know what to do with the traffic that is meant for the new subnet.