HA active/active, firewall rules stop working 8.202

I agree with point 1, NAT rules with addresses configured on the ASG must
be bound to the correct host definitions and NOT to self created definitions.

But I don't get the second point with normal rules. Why to you think this won't work?
The Interface Host definitions are used to see if rules belong to FORWARDING
or the INPUT/OUTPUT chains. So as long as you don't want to allow traffic IN or OUT
the ASG itself, binding a host definition to an interface should be fine...

I know that there are installations out there, which have WRONG wiring,
e.g. an host is reachable via eth0 and eth1 and its random, which interface is chosen.
But in that case the network design is broken, not the ASG [:)]

Cheers
 Ulrich

for point1, we dont use DNAT or SNAT.

And for your 2nd point, we have more then 60 rules with host/network definitions bound to an interface, and only 1 rule that give problems (that i know off) since 2 weeks and sometimes during the day.

But I don't get the second point with normal rules. Why to you think this won't work?
The Interface Host definitions are used to see if rules belong to FORWARDING
or the INPUT/OUTPUT chains. So as long as you don't want to allow traffic IN or OUT
the ASG itself, binding a host definition to an interface should be fine...

I agree, "should be fine" - but, it isn't always.  In fact, almost always, there's no advantage to binding definitions to an interface unless it's to fix a mistake.

I seem to recall a situation where someone had masqed a VPN Pool on the Internal interface to be able to reach an internal server.  But, you know iptables and I don't, so perhaps you can explain why it's always OK to bind to an interface.

I'm a math guy, so I always look to maximize the number of degrees of freedom - that would be enough justification for me to avoid resticting a definition to an interface.

Cheers - Bob

Its just what you configure, there no magic or randomness here.

If you bind a SRC Host definition to an interface, then the traffic must be received from that interface.
If you bind a DST Host definition to an interface, then the traffic must be send to that interface.

There are not VPN interfaces in WebAdmin, so you can't bind Host Definitions to VPN interfaces,
so VPN traffic can't match here.

Also IPSec traffic going through an IPSec Tunnel will not match such Host definitions,
even if they arrive or will be send via that interface. But thats not an technical issue,
that was a design decision to be v7 compatible.

I think most issues related to Host Definitions happen, because the wiring is wrong,
e.g. connection eth0 and eth1 to the same switch port and its random, which way
packets are going... Thats probably the issue in that case too.

Why do people want that? Well its a "bit" more secure. However you can get the same effect
by enabling the Spoofing Protection...

Cheers
 Ulrich

BTW: Since 8.200 its possible to disable that ARP requests
for local IP addresses will be answered by all interfaces:
"/usr/local/bin/confd-client.plx set interfaces advanced arp_ignore 1"

OK, so, do you agree that it's extremely, extremely rare that it's a good idea to bind a definition to an interface, and that it's more likely to cause problems for anyone that's not intimately familiar with iptables internals?

Cheers - Bob

No I didn't say that [[:)]] Its a kind of spoofing protection, but more granular.
But like everywhere, if you increase the complexity the changes increase that
something will break...

And I'm not saying that its our product [[:)]] You get what you configure.
In above issue again, problem was, that two interface are connected to
the same LAN segment and thats just a broken network setup...

Cheers
 Ulrich


It

Beheerder, what happens if you set 'Interface: >' in the definitions used in the firewall rule that stops working?  Or, did Ulrich look at your configuration and see that you had two interfaces connected to the same physical network?

Thanks, Ulrich.  I appreciate that explanation, and I understand a little better what's happening.  Nonetheless, for just about everyone outside of your group, certainly for those untutored in iptables internals, binding to an interface can lead to what they will perceive as unanticipated problems.  

Cheers - Bob

Yes, problem was with two network segments directly connect to each other.

I would like to change the default behavior with arp_ignore on our installations,
to disable the announcement on all interfaces. So ARP requests are only
answered if the IP address is configured on the Interface the ARP request
was received. You can do this via command line since 8.200:
"/usr/local/bin/confd-client.plx set interfaces advanced arp_ignore 1"

But thats the default behavior of the Linux Kernel, to answer ARP requests on
all interfaces. And I bet, if we would change the default behavior, there will be
as many people screaming that their setup stopped working as there are now,
screaming that the packet filter rules wont work as expected [;)]

Cheers
 Ulrich

Ulrich, maybe you could comment on Always bind to >.

Cheers - Bob