[Firehol-support] Masquerading happening on simple router?

Carlos Rodrigues carlos.efr at mail.telepac.pt
Mon Oct 17 02:52:02 BST 2005

On 10/15/05, Costa Tsaousis <costa at tsaousis.gr> wrote:
> So you are suggesting that there is no 'snat' or 'masquerade' in your
> firewall config and still traffic gets SNATed to your firewall IP?
> If yes, do you have a trasparent proxy in your firewall?

As I said in another message, my firewall config does have masquerade
on other router blocks: between two private networks and "world" and
between them and "dmz".

It was the masquerade setup on these four router blocks that was
causing the problem. Somehow, it was also being applied to the
"world-to-dmz" and "dmz-to-world" router blocks, even though I haven't
defined masquerade for these (no masquerading/snat defined between
these two interfaces anywhere).

In all the four places where "masquerade reverse" is defined, the LAN
connected to the output (router's "outface") interface has only one
subnet, and since adding transforming those lines into "masquerade
reverse src ${subnet_attached_to_outface}" solves the problem, it is
clear that there is more traffic being matched by these rules than
what's expected.

Both private networks and the DMZ are VLANs over a *single* NIC, with
another NIC (world) connecting to the outside, so we can say that
there is in fact masquerading defined between the NIC that connects to
the DMZ and the NIC that connects to the outside.

Applying masquerading at the physical interface level ignoring virtual
(non-aliased) interfaces is either a bug or a caveat of masquerading
(at least from FireHOL's rule generation). From the line in the
documentation that I mentioned in the other post, I concluded that
this was a caveat. Anyways, I'd suggest this to be made more explicit
if indeed it is "expected behavior".

BTW, by inspecting "iptables -t nat --list", I see that having
"masquerade reverse" defined in two router blocks with the same
outface generates two exacly equal masquerade rules. Shouldn't FireHOL
generate only one rule in these cases? (This is rather insignificant,
but I'm curious).

> Please, make a test: add
> log 'some text'
> to the route command in world-to-dmz above and examine the log. Is SRC=
> valid?

I can do this in an instant, if it still makes sense after my explanation above.

Carlos Rodrigues


More information about the Firehol-support mailing list