Fate of the packet filter ?

[tct]

What is to become of the OpenVPN built-in packet filter (PF) ?

Options for the future of the PF :

• Drop it - OpenVPN should not be a firewall.
• Keep it - OpenVPN can be more than a VPN.

If "Drop it" then close this ticket.

If "Keep it" then Why / How ?

Summary of key points :

• The PF is not built-in , it is only available via a plugin.
• The PF is IPv4 only.
• The PF is not widely used.
• Maintaining the PF code is an unwanted developer burden.

The rest is only optional ideas

Why :

• Present the user with a unified VPN/PF interface.
• If OpenVPN is to maintain a packet-filter then it should be in-house .
• Other reasons ..

How :

Requires two new Server side options: eg. --pf-enable and --pf-allow $CIDR

Rules:

• DEFAULT ALLOW All.
• If --pf-enable then DROP all data channel packets.
• If --server-(ipv6) then ALLOW server(v6) host IP.
• If --server-(ipv6) & --client-to-client then ALLOW server(v6) CIDR (See note 5).
• If push "route(-ipv6)" then ALLOW route(v6) CIDR.
• If --server(-ipv6) & push "redirect-gateway-(ipv6) then ALLOW ALL (Disable client PF).

Customisation:

• Requires --client-config-dir
• Include DEFAULT --client-config-dir template.
• ALLOW by --pf-allow CIDR (See Note 1).
• Mutually exclusive to any --push redirection (See note 4)
• Option: --pf-enable route-only , which would DROP server subnet(v6) and only ALLOW pushed routes.

Note 1: If the user wants to over-ride Rules then they can use their real firewall. eg netfilter.

Note 2: IPv6 may also require some built-in rules.

Note 3: --mode server required (otherwise use your OS PF).

Note 4: If the client redirects their own gateway then the prior server rules will have priority.

Note 5: Having enabled --client-to-client , this is the one place where an OpenVPN PF has value. Who can see who ?

[Gert Döring]

also, #636

[tct]

Superseded by #1379