Hi Chris, On Tue, 13 Nov 2012, Chris Wilson wrote: > On Tue, 13 Nov 2012, Jozsef Kadlecsik wrote: > > > Please note, I believe only the second example you wrote is relevant. > > Starting VPN just out of the blue *after* connections are built up is just > > not the right thing. > > I don't want to argue too strongly for the VPN case because I didn't > experience it myself. I found it while researching to understand this problem, > and it was never solved (properly and reported) by the sysadmin who > experienced it. > > The problem I have with that is that I don't know how to configure the Linux > firewall and devices behind it correctly to avoid this. > > Devices behind the firewall are trying to establish connections with devices > outside, constantly. The firewall reboots. As soon as networking is up and > iptables allows the devices' packets to pass, they start creating conntrack > entries, even if the VPN is not up and therefore the packets are being routed > out of the wrong interface. Ahh, the niceties of living systems! :-)) > 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. > * disable IP forwarding until the VPN comes up. Affects all non-VPN traffic as > well. > > * keep the internal interface down until VPN comes up. Affects all non-VPN > traffic as well. > > * shoot lusers/device vendors in the head. Maybe the best option? > > * flush the existing conntrack entries when the VPN comes up. > > * any others? Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary -- 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
