The FireBrick® has to be able to handle stealth routing, normal routing, source routing, IP/port mapping and network address translation. This means the normal simple rules applied to normal routing tables are not quite up to the job.
Computers communicate on the internet by sending messages (packets) from their IP address to another IP address. On this basic principle the whole of the internet is based. Getting a web page involves your computer sending packets from its IP address to the IP address of a web server somewhere else in the world, and that web server sending packets back to your computers.
The trick is how the packets get to the right place. With an address like "25 Arcacia Avenue, NORWICH, UK", it is easy to see that there are different parts that define the location in every closer steps. The 25 is meaningless to the sorting office handling the mail being sent from New York to that address, but the UK bit matters. As it gets closer more bits of the address matter until your postman actually looks for a house with 25 on the door.
With the internet, it is a bit like that, but the addresses are not as obvious for people to understand.
Somehow the computers on the network need to know when to send things to other machines on the same network and when to send them to the router for the outside world. In either case, they also need to know where on the local network to send the information. This is all based on the IP address.
You will have noticed that all of the computers on your local network have similar IP addresses. Usually the same first three numbers, and then even the last numbers may be in a small range. This is no accident, and is part of how local networks are managed.
A network is set up with a subnet mask. This is a number (e.g. 255.255.255.0) which is used to restrict the IP addresses. When the mask has 255 in it that means that the number must match, and when it is 0 then any number will do. So if you have 192.168.1.25 as an IP address and a mask of 255.255.255.0, then 192.168.1.59 is on the same network as the first the numbers are the same and the last can be any number. This gets more complicated when the mask is not only 255 and 0. Other numbers constrain the range using binary maths. Fortunately, if you set up an IP and netmask in the FireBrick® subnet settings it will tell you the actual range of IP addresses that is covered by that configuration.
All computers on a network must have different IP addresses, and the same netmask, and must be on the same network (which depends on the netmask). When sending a packet to another IP address on the same network the computer will try and find it directly using an Address Resolution Protocol (ARP). This is a special packet that is sent, and asks "who has IP address 192.168.1.59". The answer specifies which computer it is on the network so that packets can be sent.
To send information to addresses that are not on the network, the computer sends to a gateway address. This is set up in the computer as the address on the local network of the router - the gateway to the internet. The computer then uses ARP to find the router and sends the packet to it.
A router however has a potentially more complicated job. It will have one or more network connections, and may have other types of connections such as a leased line, or ISDN dialup (or in the case of the FireBrick®Plus, tunnels).
This means it is not a simple question of sending everything you don't know to a gateway.
Normally each network interface has an IP address and netmask. This makes part of routing simple - if the packet is for an address on any of these interfaces then send to that interface directly.
Then, there is normally a list of routing rules. These say that if the packet is going to a specific range of addresses (using an IP address and netmask) then send the packet to a specific interface or other router.
Conventional routing will usually find the most specific match and works only on where the packet is being sent (the destination IP address).
The FireBrick® subnet control page lets you define the subnets attached to the WAN and LAN connections, specifying an IP address and netmask.
The FireBrick® is also very flexible and actually allows the same IP addresses to exist on LAN and WAN.
| Security | Defines the security level controlling who can view/edit this subnet |
| Name | Give the subnet a name. Generally this is any name you like, but can use used to restrict DHCP |
| Side | Select if WAN or LAN |
| IP | Define the IP of the FireBrick®. |
| Mask | Define the subnet mask. May be entered as a mask (e.g. 255.255.255.0) or bit count (e.g. 24) |
| DHCP Client | IP, Mask, and other settings are set automatically by DHCP |
| Stealth | The same addresses exist on the other side of the FireBrick® and so ARPs should be sent through |
| NAT | This a private subnet, and packets from it must be translated |
| DHCP Server | Define the range of addresses to allocate as a DHCP server |
| DNS servers |
Define two DNS servers to be
allocated by DHCP. If blank, the firebrick acts as a DNS relay. |
| Bootp server |
Define bootp server IP and filename - for advanced use. |
| DHCP Exclude | Do not accept/issue specific general settings in DHCP mode |
| Special | Various special DHCP settings described in the DHCP section |
| Profile | When the subnet is valid |
It may seem odd having a profile for subnets, but this can be used to allow multiple redundant routing. i.e. two FireBrick®s can share a single IP, with one dependant on a profile based on being able to ping the other (on a different IP). This allows for one FireBrick® to normally be a "gateway" and the second to be a backup if the first fails.
This means that the order of routing rules is very important. The way routing is done is as follows :-
As with filters, routes can be moved around by clicking on the green dot and then selecting the destination.
Routing is done on where the packet is from as well as where the packet is to. It is also important to say which connection the packet came from and which it must go to (WAN or LAN, etc). This is important as there could be the same addresses both sides and you may want to route them differently.
| Security | Defines who can view and edit this route |
| Name | Give the route a name |
| Direction | Specify when the packet is coming from (may be multiple interfaces) |
| Sent to | Specify where the packet is to be sent to. Can be Any, in which case further routing rules are checked (used to force NAT or proxy ARP) |
| Source IP | The range of IP source addresses - blank for any |
| Source DHCP | Indicates that this range is in fact DHCP allocated. A DHCP allocation on any interface in the source direction will cause this range to be changed |
| NAT | This indicates that any packets following this route are to be translated with NAT |
| Target IP | The range of IP target addresses - blank for any |
| Target DHCP | Indicates that this range is in fact DHCP allocated. A DHCP allocation on the sent-to interface will cause this range to be changed |
| Proxy ARP | Indicates that any request on the direction interfaces for the target range of IPs is to be answered by the FireBrick®. |
| Gateway | Specify the gateway - relevant where the packets go to another router on the LAN or WAN |
| Gateway DHCP | Indicates that the gateway is set by DHCP. A DHCP allocation on the sent-to interface will set this |
| Weight | The weighting for this route, normally 100%. This can be used to allow sessions to follow different routes based on probability. |
| Profile | When this route is valid |
If you configure a subnet on an interface, then this means that the FireBrick® has a real IP address, and that all of the addresses on that subnet are on that side of the FireBrick®. If the FireBrick® receives an ARP from that side for another address on that side then the FireBrick® ignores it (not sending to the other side). Also, broadcast packets (being sent to the first or last address on a subnet) are treated as being for the FireBrick® itself - so it will answer broadcast pings and DHCP requests. The log/filter options allow broadcasts to be stopped.
If you want the FireBrick® to have the same subnet each side and to pass ARP requests and data using stealth, but still want it to have an IP address, then you can mark the subnet as stealth. This means that the FireBrick® considers itself to have the IP address you have said, but that it still sends ARP requests and broadcast messages to the other side as it did not have a subnet of its own. This is useful if you have a FireBrick® in the middle of a network without the rest of the network knowing, but still want to give the FireBrick® an IP address.
If the FireBrick® sees ARP requests for addresses that are not on any subnet then is passed them through (but the log/filter options allow this to be disabled).
It is important to realize that stealth packets do not go through the routing table. If you need them to you must set a proxy ARP route.
The FireBrick® can be configured to automatically direct such packets to the router by responding for them when an ARP request is sent. This is the Proxy ARP setting in the routing table. It causes the range of target addresses specified to be answered by the FireBrick® on the source interface. When packets are received for those addresses they are routed according to the routing rule - which may be to send to a specific interface or to send to another router.
Once the packet is routed and a session is established, that route remains in place for the session (important is routes change on the fly, such as switching to/from ISDN backup, etc).
Private addresses have been reserved for this purpose and are 10.X.X.X, 172.16-31.X.X and 192.168.X.X. You should not use any other addresses for private networks.
The FireBrick® can be configured with subnets each side - e.g. a private network on the LAN and the public network on the WAN. This means packets can be routed from one side to the other with no problem.
The issue is that the private addresses will not work in the internet - they are not real addresses, and replies could not get back.
In this case, simply mark the LAN subnet as NAT. This means that all messages from your computers on their private addresses have the source address changed to that of the FireBrick® as they are sent out. Replies coming back have the destination changed back to the private address. This only applies where a specific routing rule is not found, so if you add special routing rules, and still need NAT then you have to set the NAT checkbox in the routing entry. It also means you can have rules which stop NAT happening to/from certain addresses by adding a routing rule.
Some protocols and some games can't cope with this type of operation and require real addresses - in particular ftp will need passive mode set or cleared to operate correctly.
Note, that whilst NAT will map IP addresses for protocols other than ICMP, TCP, and UDP, there is no way to track multiple sessions as the FireBrick cannot allocate a port or ID. As such NAT for such protocols can only be relied on where there is only one session at a time. If multiple sessions, then replies may go to the wrong one depending on the last session that was active.
This cannot work with private addresses, so a facility called portmapping is provided to allow IP/ports on the FireBrick® to be mapped to ports on specific machines on your network.
Port mapping is quite general purpose, and can also allow outgoing translations (accessing one IP actually accesses another), so could be used to force use of web proxies, etc.
Like most such tables the first match is applied. If out of time profile the entry is skipped and a later match is found.
Port mapping rules apply to all sessions, even stealth sessions, and if matched force the session to be routed. As such, port mapping rules can be used to hi-jack stealth traffic. By setting a target of Any in the port map, you can hi-jack traffic and force it to follow the normal routing rules, without necessarily changing the IPs or ports !
| Security | Defines who can edit or view this portmap |
| Name | Name the portmap |
| Direction | Allows the existing routed/stealth direction of the packet to
be checked. This can be multiple selections |
| Map to | Says where the packet is to go instead - Any means that the packet is routed |
| Source IP | The range of source IPs to check - blank for Any |
| Map to | The new source IP - blank for no change, 255.255.255.255 means set to the FireBrick® itself |
| Target IP | The range of target IPs to check - blank for Any |
| Map to | The new target IP - blank for no change |
| Protocol | The protocol to check |
| Target port | The range of target ports to check - blank for any |
| Map to | The new target port - blank for no change |
| Profile | When the port map applies |