[SOLVED] VPN down due to iptables changes?

[The_Great_Sephiroth]

Got a strange issue here. I recently reloaded my laptop from scratch and all has been good EXCEPT PPTP VPN.

[The_Great_Sephiroth]

I have read a LOT of posts on this subject and there seems to be a lot of confusion. How do I get it so when I click a VPN connection in NetworkManager it does whatever it needs to do to make the proper helpers load and then unload them when finished? Seems like these were disabled before a proper solution was in place. I keep seeing people solve this on servers by using more iptables rules, but in a workstation environment where firewalld manages things this makes that approach nearly useless. Oh, and I still don't understand this even after reading loads of posts across the web on the matter, and a lot of them end in things like "I don't know what I did, but it works now". Even less helpful.
_________________
Ever picture systemd as what runs "The Borg"?

[The_Great_Sephiroth]

So I am assuming this was a knee-jerk reaction by the kernel devs since they were criticized? I mean 194 views and not one response? Is there a way to revert this so I can actually work? VPN is a part of the IT life and right now I cannot use any VPN. Every time I try that stupid message gets logged.
_________________
Ever picture systemd as what runs "The Borg"?

[Hu]

If criticizing the kernel developers could provoke changes, I think there are some other areas where we would see substantial change.

I've had no problems with OpenVPN. I never get that message. I never use NetworkManager, either. I am aware my post is not particularly helpful, but since you have already removed yourself from the unsolved threads list (by replying to yourself) and you seem rather agitated, I felt I should point out that you are, in fact, apparently alone in this problem.

If you need helpers, you can use the iptables CT target to install them. Do you actually need helpers or are you only active here because the message suggests that you might need them? If you do need them, what symptoms led you to that conclusion?

[The_Great_Sephiroth]

What led me to the problem was that I upgraded the kernel using the old config and now whenever I attempt to make a PPTP connection that message is logged and the connection fails. Every. Single. Time. I have found posts all over with this issue (just google the message) and nobody has an answer. Some threads just trail off, others have users state that suddenly it's working again, and others have gone to extreme lengths of reinstalling the OS to get nowhere.

My agitation comes from updating to a new "stable" kernel and none of the software which manages firewalls is apparently capable of dealing with this change. This cripples me. I either disable firewalld and use a generic one from scratch, written by hand, or I can no longer connect to VPNs, requiring me to drive to locations now. Something is broken and I can't figure it out. It's not a change I made. If I revert to 4.9.72, it works again. I compared kernel configurations and they're the same, so something didn't magically go away. Plus, I do not get that message on 4.9.72, only 4.9.76.

I am not mad with any individual or the kernel devs. I am aggravated because a change was made which my software cannot apparently handle and I am now stuck.
_________________
Ever picture systemd as what runs "The Borg"?

[mike155]

I can understand that you are angry when things change unexpectedly!

Since it's open source, we can look at the source code: the message changed on 2017-02-26 in kernel 4.9.13. The old message was:

[Hu]

Based on the lead that mike155 posted, I examined the kernel source in this area. If I read this right, you can return to the old semantics by setting the sysctl nf_conntrack_helper to true. This probably reintroduces the security problems that prompted the change, but could be a useful workaround until you fix your configuration. Could you check your logs to confirm that the old message about deprecation has been appearing under the old kernel?

Based on the message logged, it reads to me like the solution is to use the iptables CT target to explicitly load the required helpers when a relevant packet is seen. You could also switch to a PPTP-free VPN, though that is more invasive.

[The_Great_Sephiroth]

Sadly, most VPNs are PPTP due to that being supported virtually everywhere. I know it is insecure, but try finding a VPN technology that is supported under Linux and Windows. It's nearly impossible. For people who are part of an AD domain but are mobile, PPTP is life. You can sign in with PPTP, the laptop connects to the PPTP server, then automatically authenticates the login credentials and the user is in. I like OpenVPN but I am fairly sure I cannot integrate it that way, which would be an issue. I'd have to login with cached credentials, then bring up the VPN, but at that point I do not have the redirected documents and such.

Now, I'd rather use this new stuff, but I don't know how. Again, it isn't *my* configuration. I use firewalld to manage iptables with NetworkManager. I set each connection to a different firewall zone. My office and client locations (wireless) are in the "work" zone which allows SMB and other things into my system. Starbucks or other hotspots are in the "public" zone so when those connections come up only the bare minimals are allowed in. The alternative to this is a billion BASH scripts and each time I connect to a wireless network I have to run a script as root. Not appealing.

Maybe I am misunderstanding this though. I thought that this "CT" target was part of iptables. This sent me down the path of "the most widely used firewall manager doesn't support the new change and is breaking my life". Is this something I load as a module? Am I missing something? I am still about as clear as mud on how to use the CT target from within firewalld and make things "just work" like they did all these years prior.

*UPDATE*

OK, so I believe I figured out what to do, but I do not know whether or not it is correct. I found this article for firewalld and the automatic helpers when searching for "firewalld ct target". It defaults to "system" which, in a correctly configured kernel, disables helpers. Apparently I can set this to "no" and it handles the packets in prerouting, or I can set it to "yes" and it handles them the old, insecure way. I am going to set this to "no" and see what happens after a brief reboot.

*UPDATE*

Found the issue. I cannot use that info. It applies to firewalld 4.4 and above, and the latest stable in Gentoo is 4.3.3, so the firewall is so old it cannot make use of the kernel change. This is the issue. In other words, the kernel change was made before the software was stabilized and made available, thus breaking everything for a user who depends on firewalld. I'm going to see if I can get any info on how "stable" the current testing version is and maybe unmask it.
_________________
Ever picture systemd as what runs "The Borg"?

[mike155]

Did you try to append 'net.netfilter.nf_conntrack_helper=1' to /etc/sysctl.conf and reboot? Does it solve your problem?

[The_Great_Sephiroth]

I don't want to use the old method if it is being deprecated. I want to make the software work with the new method. That solution is a fall-back solution in the event that I cannot make the software work.
_________________
Ever picture systemd as what runs "The Borg"?

[szatox]

I'm a bit lost, can you summarize your current situation and goals?
What is the problem with pptp and firewall? I get it fails due to missing helper, what rules you used to have there? Maybe we could figure out another way to handle it.
E.g. if pptp became problematic due to firewall issues and you need a vpn that works with windows well, perhaps l2tp/ipsec could do the trick? From the limited things I heard, it seems to be "the" vpn there.

[Hu]

[The_Great_Sephiroth]

For Windows sign-on, it has to be L2TP, PPTP, SSTP, or one other, I forget at the moment. I know I can install OpenVPN, but it means you have to login, start the software, then make the connection. I need a connection on demand prior to login. That's my issue.

I did want to report success. Updating firewalld to 0.5.1-r2 and setting that value to "no" made firewalld create prerouting rules to handle GRE and whatever else it need to, and everything is good again. So far firewalld seems stable too, so the solution is to update to at LEAST firewalld version 0.4.4 and set the value for automatic helpers to "no". This way your iptables rules are configured in a way which works and those helpers are NOT automatically loaded. Security and functionality.
_________________
Ever picture systemd as what runs "The Borg"?