Hi Jozsef,
On Tue, 13 Nov 2012, Jozsef Kadlecsik wrote:
The VPN cannot be brought up until networking is up, so the only ways I
can see to prevent this are:
* the firewall ruleset forbids packets destined for VPN addresses to
leave via the public interface. But the VPN destinations not be known
until the tunnel comes up and the VPN server declares to the client
which subnets should be routed through it. It might even change every
time. Or it might be the default route. Should we then forbid all
packets from leaving on the public interface? How will the VPN
communication happen then?
But *something* selects which traffic is forwarded via the VPN tunnels.
As egress-ingress filtering, the same selection can be used to allow the
proper interfaces only.
The VPN software may decide, based on configuration received from the
remote server, what traffic is routed. Almost all tunneled VPNs work this
way; the only exception I can think of is IPsec. OpenVPN and anything
PPP-based (PPTP and L2TP) all create an interface with a subnet and mask
assigned by the server, and the kernel automatically routes all traffic
for that subnet through the VPN. But what address will be assigned? Often,
only the VPN server knows, and sometimes only at the moment of assignment.
We could say "you must know which subnet will be assigned in order to
write your policy" which is technically correct, but not user friendly.
I'm very heartened to see that you want to make the default behaviour
(without resort to external tools) more user-friendly :)
Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
