[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem load balancing incoming connections

First of all, thanks a lot for your reply and useful suggestions.
On Fri, 19 Nov 2004, Daniel Hartmeier wrote:
>   2) If the rule contains a reply-to option, the packet is routed out
>      the specified interface.
>      New (since 3.5) is the little detail that the packet, now
>      attempting to pass out the 'right' interface, is again filtered
>      by pf! This was necessary for certain setups so the packet gets
>      a chance to create a new state there. In your specific case, it
>      isn't necessary, but harmful.
It may well be needed for my final setup. The ruleset I attached was a 
test one, based on the PF guide example in the "Address Polls and Load 
Balancing" section, with the addition of some rules suggested in your 
> > pass out on $ext_if1 route-to ($ext_if2 $gw_if2) from $ext_if2 to any
> > pass out on $ext_if2 route-to ($ext_if1 $gw_if1) from $ext_if1 to any
>      I don't understand the purpose of these rules, BTW. The rules
>      contradict the comment (did you intentionally swap $ext_if 1 and
>      to in the route-to arguments?).
This comes from the PF guide example as well. I guess it is intended to 
re-route packets that go out through the wrong interface.
>        pass in on $ext_if1 from any to $intweb \
>          tag from_ext_if1 keep state
>        pass in on $ext_if2 from any to $intweb \
>          tag from_ext_if2 keep state
>   d) use 'reply-to' on dedicated 'pass out on $int_if keep state', based
>      on the tags added, like
>        pass out on $int_if reply-to ($ext_if1 gw_if1) \
>          from any to $intweb tagged from_ext_if1 keep state
>        pass out on $int_if reply-to ($ext_if2 gw_if2) \
>          from any to $intweb tagged from_ext_if2 keep state
This has done the trick. At least as far as incoming connections to the 
internal webserver are concerned. However, there remains a problem. 
Traffic from the Internet to the firewall itself is still not working as 
desired. Somehow, the default route is still being used for outgoing 
packets in this case. For example, if I ping the IP of the second 
interface (not the one with the default route), the echo reply packet is 
sent out through the default interface. Even if I use a reply-to rule 
pass in log-all on $ext_if2 reply-to ($ext_if2 $gw_if2) \
     net proto icmp all icmp-type $icmp_types keep state
the result is not the expected. See the output of tcpdump:
Nov 19 17:12:01.557537 rule 11/0(match): pass in on rl0: > icmp: echo request
Nov 19 17:12:01.557633 rule 11/0(match): pass out on tun0: > icmp: echo reply
Nov 19 17:12:01.557679 rule 11/0(match): pass out on rl0: > icmp: echo reply
Yes ... the packet is duplicated on the other interface, and in fact it 
gets lost or discarded, because the pinging host reports packet loss.
> Make sure you have 'keep state' on _all_ 'pass' rules, and that you have
> 'flags S/SA' on all 'pass proto tcp keep state' rules. Your current
> ruleset violates both of these principles, further complicating things.
> Daniel
I was really desperate to get anything to work, so I decided to start with 
a very simple ruleset. In reality, my final setup will have to approach a 
series of other points:
1. Fault-tolerance. A very simple one. Something that avoided the packets 
going to the wrong interface (when it goes down) would be sufficient. Do 
you think "ifstated" could be used for that purpose (I am thinking about 
using some anchors to have the ruleset updated when something bad 
2. ACK priorization. Again, following the recommendations in your site, 
I will need rules with queue specifications. That reminds me of the 
second suggestion in your message dated from last year, where you say:
"don't use route-to on internal interface, but let all connections get 
routed to the external interface with the default route, and use route-to 
with a rule like:
pass out on $ext_if1 route-to { $ext_if1, $ext_if2} \
     from any to any keep state
Is this still the recommended setup for 3.5 and 3.6? If so, how could one 
add queue information for 2 interfaces with different bandwidth limits?
3. Most likely, I will get an IP address for each interface and the same 
next-hop from my DSL ISP. So for instance, If I have 2 dsl conncetions, I 
will get something like:
IP1 -> IPnh
IP2 -> IPnh
Also IP1 and IP2 will probably be from the same network. Do you see this 
as potential problem (as far as PF is concerned)? 
Thanks a million for any additional help.