It is normally used where there are a set of private addresses on one side of the FireBrick and a single address on the other, and access from the private side is to be mapped via the single public address.
NAT is normally set by flagging NAT on a subnet. This means that all traffic from IP addresses on that subnet is flagged to be translated. In addition, routing entries can be used to mark specific traffic as NAT or non NAT and this takes priority over the subnet setting.
This only applies to routed traffic.
Once traffic has been marked as NAT, then routing rules are applied as normal. The source address is then mapped to the FireBrick's address on the destination interface and the source port (TCP/UDP) or ID (ICMP) is changed.
Reply packets to the FireBrick reverse these changes as per normal port mapping.
Where the traffic goes via a tunnel, there is no source address, and so the NAT is actually applied at the far end of the tunnel when the packet emerges to go via an ethernet interface. This can mean a duplicate IP in a trackeroute of packets via a FireBrick tunnel.
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.