New! From version 0.98.4 on!
Destination address translation in output direction
Since IPFIREwall version 0.98.4 the behaviour of the combination
DNAT/filter in the output direction has changed.
Before such version, the filter was applied after the address
translation, that is the match was performed on the real destination
address.
From version 0.98.4 on, the filter is applied on the original
packet as it is composed by the generating application, and just then
the network address translation is applied.
This allows the filter to block the communication basing on the original
destination address.
This choice has the following consideration at its base: since the
output DNAT rules are setup by the administrator, why perform
the filter check against the destination address chosen for the redirection
by the administrator?
That is, if the administrator redirects all web traffic to a proxy cache
by means of an output Destination Address translation rule, why should he
block the packets addressed to the proxy?
Starting from this observation, we thought about a scenario in which the
filtering on the original destination address wolud be quite useful.
Let's suppose the case in which the administrator of the workstation A wants to block the connection
towards the web site X, with the constraint that, being in a local area network,
all the web traffic passes through a web proxy/cache P.
If the traffic towards X is not blocked in the proxy, we have to block it directly in
the workstation A, obviously.
This is not possible in the IPFIRE-wall versions prior to 0.98.4.
This is possible with iptables bothering with the conntrack match:
-m conntrack --ctorigdst
.
In IPFIRE-wall 0.98.4 it is as simple as inserting a classical OUTPUT denial rule.
This thanks to the filter being applied before the OUTPUT DNAT translation.
A couple of ingredients are still missing to complete the scenario.
- The administrator shall insert an OUTPUT DNAT rule redirecting the web traffic to the proxy;
- the administrator himself shall block all traffic directed to the proxy directly. This because a user could in this example force its web browser to bypass the output dnat rule added at the previous step.
OUTPUT PACKET FLOW from IPFIRE-wall version 0.98.4 on.
|APPLICATION| -- generates output packet -- |FILTER| -- [OUTPUT DNAT] ....