FireBrick FB6402, Руководство пользователя

Страница: 70 / 196

Session Handling
53
Tip
It is possible, of course, to use rule-sets and rules to control exactly when NAT applies rather than
using the NAT setting on the PPPoE config. However, if the PPPoE connection only has one IPv4
address assigned, as is often the case, then setting NAT on the PPPoE config is usually the simplest
way to achieve the configuration.
7.4.6. NAT with other types of external routing
Where NAT is needed for other types of external routing, you can set NAT using explict rule-sets and rules.
A simple rule-set at the end of all rule-sets can easily be set up to identify traffic being sent to a specific target
interface and set the NAT setting.
Tip
It is recommended that you use PPPoE where possible rather than an external router which may
additionally perform an additional layer of NAT.
7.4.7. Mixing NAT and non NAT
In some cases you may have a combination of real routed IPv4 addresses and some RFC1918 private addresses.
These could be on different interfaces and subnets.
Typically in such cases you want to use NAT for external communications only when using the private
addresses, but non-NAT when using the public addresses. The logic can be complicated where there may be
fallback arrangements, such as a dongle, which may have to use NAT for all traffic even the normally public
routed addresses if the dongle does not have routing for these addresses.
The recommended way to handle this is a rule-set at the end of rule-sets for handling NAT, in which a specific
rule is created to match traffic being sent to the external interface (e.g. PPPoE) which is from an RFC1918
address and setting NAT mode in such cases. Using this arrangement ensures that traffic internally between
RFC1918 and public IP addresses can continue without using NAT internally.
Tip
For fallback arrangements such as a dongle where all traffic needs to use NAT, simply set the NAT
mode on the dongle configuration. This saves having more complex rule-sets to handle the fallback
case.
7.4.8. Carrier grade NAT
Carrier grade NAT (CGN) is where an ISP provides end users with a private address and provides a further
level of NAT in the network (within the carrier).
Ideally you should try and make use Internet connections without CGN, but if you have to then you are likely to
encounter additional issues with NAT. CGNs do often include some ALGs, but they bring all of the issues with
NAT to a new level. As ever we recommend using PPPoE to avoid an extra layer of NAT in a broadband router.
In some cases the FireBrick may be expected to provide a carrier level of NAT in terms of number of sessions
handled. Whilst the FireBrick does not have any ALGs, it can be very effective, and it supports overloading
of ports. This means that the allocation of ports for NAT allows multiple sessions that are to different target
IP addresses and ports to come from the same port on the FireBrick, allowing use of the same port multiple
times. This allows a lot more sessions that would otherwise be expected based on number of TCP and UDP
ports available. This overloading of ports is automatic and part of the way the FireBrick handles NAT.
7.4.9. Using NAT setting on subnets
For backwards compatibility with older FireBricks there is a NAT setting on the subnet config. The idea is that
a subnet defined as an RFC1918 private block can simply be tagged as NAT. The effect is that any traffic from
that subnet has NAT set by default. Again, this can be overridden by firewall rules.