Contributed by pitrh on from the states of confusion dept.
It’s possible to misuse NAT to load balance outbound traffic across multiple internet connections from different service providers,see the Load Balance Outgoing Traffic section of PF FAQ.
The shortfall with this configuration is when implemented alongside unstable links, forwarding will continue to be attempted over the links which are down, this will cause issues such as long hangs for users behind the NAT while connections time out. To mitigate this,ifstated
can be used to smooth things over.
Read the rest at geeklan.co.uk, Sevan's blog site.
(Comments are closed)
By Anonymous Coward (87.151.94.150) on
isakmpd's tagging feature sounds nice, but using ifstated + some vpn anchor also sounds good as well.
What would you choose?
Comments
By Giancarlo Razzolini (177.92.58.144) on
>
> isakmpd's tagging feature sounds nice, but using ifstated + some vpn anchor also sounds good as well.
>
> What would you choose?
Ifstated can be extended with a external daemon that can run threaded simultaneous tests and even maintain a database with events and logs. That's my setup. I've developed a python daemon that receive questions and answer then. Ifstated change states conforming the answers and run all the necessary commands, some of which, are also python scripts. But of course they can be anything you want. You're only limited by your imagination.
By Tom (87.81.212.14) on
# keep https traffic on a single connection; some web applications,
# especially "secure" ones, don't allow it to change mid-session
pass in on $int_if proto tcp from $lan_net to port https \
route-to ($ext_if1 $ext_gw1)
You can use 'sticky-address' to resolve this and still specify both gateways as such:
pass in on $int_if proto tcp from $lan_net to port https \
route-to { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } \
round-robin sticky-address
That should ensure https connections stay on the same connection.
Comments
By Giancarlo Razzolini (128.90.102.224) on
>
> # keep https traffic on a single connection; some web applications,
> # especially "secure" ones, don't allow it to change mid-session
> pass in on $int_if proto tcp from $lan_net to port https \
> route-to ($ext_if1 $ext_gw1)
>
> You can use 'sticky-address' to resolve this and still specify both gateways as such:
>
> pass in on $int_if proto tcp from $lan_net to port https \
> route-to { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } \
> round-robin sticky-address
>
> That should ensure https connections stay on the same connection.
If you have truly symmetric links, with the same speed, sure, use stick-address. In my setups, which rarely have symmetric links, I favor one of them for most traffic and leave the other simply for failover. There is also the least-states that could be used instead of the round-robin option, which can balance the links a little better.
By sthen (2001:4b10:1002:cc01:f2de:f1ff:fef9:a752) on
>
> # keep https traffic on a single connection; some web applications,
> # especially "secure" ones, don't allow it to change mid-session
> pass in on $int_if proto tcp from $lan_net to port https \
> route-to ($ext_if1 $ext_gw1)
>
> You can use 'sticky-address' to resolve this and still specify both gateways as such:
>
> pass in on $int_if proto tcp from $lan_net to port https \
> route-to { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } \
> round-robin sticky-address
>
> That should ensure https connections stay on the same connection.
Speaking as the writer of this part of the faq, it's more complicated than that. You also need to enable source-tracking, because (as the manual says), normally "Associations are destroyed as soon as there are no longer states which refer to them".
And then you need to consider how long to maintain source-tracking states - too high and you blow out kernel memory use - too low and you have more risk of users losing sessions...