Port Mapping


Port mapping is a the general mechanism for changing IP addresses and TCP/UDP ports for packets that pass through the FireBrick, and where necessary changing them back as they reply. This is used for address translation as well.

The port mapping table is checked for all new sessions, after the packet has been routed and filtered. Port mapping applies to both stealth and non stealth traffic, and causes the traffic to become non-stealth.

The port mapping rules check :-

  1. Source interface
  2. Target interface
  3. Protocol
  4. Source IP address
  5. Target IP address
  6. Target ports (TCP/UDP) or ID (ICMP)
If a match is found then the port mapping rule sets :-
  1. New target interface (may be ANY to allow normal routing rules to apply)
  2. New target IP address (optional)
  3. New target port (optional)
  4. New source IP address (optional)
  5. New source port may be implicitely set if source IP is changed

Changing target IP and port

If a range of target IP addresses was specified, and a new target IP addresses is specified, then this is mapped as a block change. The first matching IP maps to the specified target. The next one maps to the specified target plus 1, etc.

The same is true for target port ranges and new target ports.

If the new target port/IP is blank, then they are not changed.

If the matching target IP range is blank, then packets to the FireBrick are matched (note, you must give the mapping rule a name).

The change to target IP and/or port does not change the source address. Replies will have to come via the FireBrick for the change to be un-done correctly, otherwise if the replies can reach the original source without going via the FireBrick, then they will not match and will not work correctly. For this reason, it is often necessary to change the source address as well (to the FireBrick or an address routed via the FireBrick) so as to ensure replies will be un-mapped.

Changing source IP

The source IP can be changed. Just the specified IP is used, even if the matching source IPs are a range. If the new source IP is blank, then the source IP is not changed.

If the source IP is set, then the source port number (for TCP/UDP) or ID (for ICMP) is also changed.

These changes are reversed when the reply returns via the FireBrick.

ICMP errors

ICMP error messages have their content checked for existing sessions, and port mapping is also reversed, not only in the header of the ICMP error, but also the contents showing the original packet. All checksums are adjusted accordingly. This only applies for TCP, UDP, and ICMP.

Forced routing

If you wish to force routing of packets that would normally be handled only as stealth, you can create a port map with no change or source or target IP/ports. This forces the packet to be routed. Note that this will only work if the packets reach the FireBrick - in a stealth mode this would mean the original target IP would have to have responded to an ARP or be via a gateway which responded to an ARP allowing the packet to be sent via the FireBrick.

Another option would be to use proxy ARPs to force traffic via the FireBrick as routed traffic.

Special port maps

There are two special port maps if no others match. These are for DNS relaying and syslog relaying - i.e. traffic sent to the FireBrick specifically is relayed to a DNS or syslog server if defined in the setup. DNS is UDP/TCP port 53, and syslog is UDP port 514. These are only mapped if the server is defined in the FireBrick. The source port is changed to the FireBrick (NAT).

Fragments

It should be noted, that whilst port mapping can re-direct packets, and in some cases session tracking can work out a fragment is part of a redirected session, normally fragments cannot be handled by port mapping and so may be dropped or simply routed as normal if they pass filtering rules.

Other protocols

Protocols other than UDP, TCP and ICMP are session tracked and can be IP mapped using port mapping or NAT. However, as these protocols do not have a port change, there is no way to track different sessions between two IP addresses. The session is assumed for each unique pair of IPs and protocol. As such IP mapping cannot track multiple sessions causing replies to be misdirected.