OpenBSD Journal

Using ifstated to monitor links and dynamically adjust PF config on event

Contributed by pitrh on from the states of confusion dept.

Sevan Janiyan writes:

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)


Comments
  1. By Anonymous Coward (87.151.94.150) on

    Hm, could this be used for pf + dynamic interfaces (like tun or pppx)? I'm currently trying to figure out how to do packet filtering when using VPN (isakmpd + ipsecctl + npppd), i.e. OpenBSD as a VPN box for iOS/Android when you have to use unsecured/untrusted wireless networks.

    isakmpd's tagging feature sounds nice, but using ifstated + some vpn anchor also sounds good as well.

    What would you choose?

    Comments
    1. By Giancarlo Razzolini (177.92.58.144) on

      > Hm, could this be used for pf + dynamic interfaces (like tun or pppx)? I'm currently trying to figure out how to do packet filtering when using VPN (isakmpd + ipsecctl + npppd), i.e. OpenBSD as a VPN box for iOS/Android when you have to use unsecured/untrusted wireless networks.
      >
      > 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.

  2. By Tom (87.81.212.14) on

    I noticed in the article this config:

    # 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
    1. By Giancarlo Razzolini (128.90.102.224) on

      > I noticed in the article this config:
      >
      > # 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.

    2. By sthen (2001:4b10:1002:cc01:f2de:f1ff:fef9:a752) on

      > I noticed in the article this config:
      >
      > # 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...

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]