Dear All,
How should one configure the firewall in order to be able to connect from my machine (Fedora 21) to another machine (MS Windows) via VPN PPP? Perhaps, after some updates, the possibility of establishing such a VPN PPP has become blocked by the firewall.
Thanks in advance,
Paul
On 02/18/2015 12:54 PM, Paul Smith wrote:
How should one configure the firewall in order to be able to connect from my machine (Fedora 21) to another machine (MS Windows) via VPN PPP? Perhaps, after some updates, the possibility of establishing such a VPN PPP has become blocked by the firewall.
What type of VPN? Both PPTP and IPSec/L2TP use ppp. Neither should be affected by stock firewall rules if the Fedora machine is initiating the connection.
You should check /var/log/audit/audit.log (and/or "setenforce permissive" and test again) for SELinux related errors. Otherwise, probably /var/log/messages and /var/log/secure will have useful data.
On Wed, Feb 18, 2015 at 10:05 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
How should one configure the firewall in order to be able to connect from my machine (Fedora 21) to another machine (MS Windows) via VPN PPP? Perhaps, after some updates, the possibility of establishing such a VPN PPP has become blocked by the firewall.
What type of VPN? Both PPTP and IPSec/L2TP use ppp. Neither should be affected by stock firewall rules if the Fedora machine is initiating the connection.
You should check /var/log/audit/audit.log (and/or "setenforce permissive" and test again) for SELinux related errors. Otherwise, probably /var/log/messages and /var/log/secure will have useful data.
Thanks, Gordon, for your reply.
The type of VPN is PPTP. With the firewall disabled, I can establish a VPN connection, but if the firewall is enabled, no VPN connection is possible.
Paul
On Thu, Feb 19, 2015 at 10:46 PM, Paul Smith phhs80@gmail.com wrote:
How should one configure the firewall in order to be able to connect from my machine (Fedora 21) to another machine (MS Windows) via VPN PPP? Perhaps, after some updates, the possibility of establishing such a VPN PPP has become blocked by the firewall.
What type of VPN? Both PPTP and IPSec/L2TP use ppp. Neither should be affected by stock firewall rules if the Fedora machine is initiating the connection.
You should check /var/log/audit/audit.log (and/or "setenforce permissive" and test again) for SELinux related errors. Otherwise, probably /var/log/messages and /var/log/secure will have useful data.
Thanks, Gordon, for your reply.
The type of VPN is PPTP. With the firewall disabled, I can establish a VPN connection, but if the firewall is enabled, no VPN connection is possible.
The issue may be related to the following:
https://ask.fedoraproject.org/en/question/63759/pptp-connection-fails-after-...
Paul
On 02/19/2015 02:57 PM, Paul Smith wrote:
The issue may be related to the following:
https://ask.fedoraproject.org/en/question/63759/pptp-connection-fails-after-...
That's odd. GRE packets should be "RELATED" to the initial pptp connection. Was there actually a change in firewalld? I don't see one. This sounds like a kernel bug.
On Fri, Feb 20, 2015 at 5:51 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
The issue may be related to the following:
https://ask.fedoraproject.org/en/question/63759/pptp-connection-fails-after-...
That's odd. GRE packets should be "RELATED" to the initial pptp connection. Was there actually a change in firewalld? I don't see one. This sounds like a kernel bug.
The truth, Gordon, is that after changing the firewall configuration as described in the referred site, the issue was fixed.
Paul
On 02/20/2015 10:00 AM, Paul Smith wrote:
The truth, Gordon, is that after changing the firewall configuration as described in the referred site, the issue was fixed.
Yes, I understand that. But it sounds like GRE was allowed previously because it was "RELATED" to the pptp TCP connection before a kernel upgrade, but afterward it required a rule to allow it unconditionally (which is bad).
I can't test that because I don't have any PPTP servers available, because PPTP is very bad security-wise.
It would be useful to remove the rules that you added and verify that the PPTP connection fails. Then, boot an older kernel which was known to previously work and test the connection. If it works, then there's a kernel bug that should be reported.
On 02/20/2015 11:27 AM, Gordon Messmer wrote:
On 02/20/2015 10:00 AM, Paul Smith wrote:
The truth, Gordon, is that after changing the firewall configuration as described in the referred site, the issue was fixed.
Yes, I understand that. But it sounds like GRE was allowed previously because it was "RELATED" to the pptp TCP connection before a kernel upgrade, but afterward it required a rule to allow it unconditionally (which is bad).
I can't test that because I don't have any PPTP servers available, because PPTP is very bad security-wise.
It would be useful to remove the rules that you added and verify that the PPTP connection fails. Then, boot an older kernel which was known to previously work and test the connection. If it works, then there's a kernel bug that should be reported.
You could restrict permitting GRE to the IP of the VPN gateway if you want more security, e.g.
firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p gre -d <ip-addr-of-gateway> -j ACCEPT firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -p gre -d <ip-addr-of-gateway> -j ACCEPT firewall-cmd --reload
---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - The light at the end of the tunnel is really an oncoming train. - ----------------------------------------------------------------------
On Fri, Feb 20, 2015 at 7:51 PM, Rick Stevens ricks@alldigital.com wrote:
The truth, Gordon, is that after changing the firewall configuration as described in the referred site, the issue was fixed.
Yes, I understand that. But it sounds like GRE was allowed previously because it was "RELATED" to the pptp TCP connection before a kernel upgrade, but afterward it required a rule to allow it unconditionally (which is bad).
I can't test that because I don't have any PPTP servers available, because PPTP is very bad security-wise.
It would be useful to remove the rules that you added and verify that the PPTP connection fails. Then, boot an older kernel which was known to previously work and test the connection. If it works, then there's a kernel bug that should be reported.
You could restrict permitting GRE to the IP of the VPN gateway if you want more security, e.g.
firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p gre -d <ip-addr-of-gateway> -j ACCEPT firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -p gre -d <ip-addr-of-gateway> -j ACCEPT firewall-cmd --reload
Excellent idea, Rick! Thanks!
Paul
On Fri, Feb 20, 2015 at 7:27 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
The truth, Gordon, is that after changing the firewall configuration as described in the referred site, the issue was fixed.
Yes, I understand that. But it sounds like GRE was allowed previously because it was "RELATED" to the pptp TCP connection before a kernel upgrade, but afterward it required a rule to allow it unconditionally (which is bad).
I can't test that because I don't have any PPTP servers available, because PPTP is very bad security-wise.
It would be useful to remove the rules that you added and verify that the PPTP connection fails. Then, boot an older kernel which was known to previously work and test the connection. If it works, then there's a kernel bug that should be reported.
Thanks, Gordon, for your reply.
If the issue is caused by the kernel, cannot one speculate that is deliberated in order to increase security? As Rick has just suggested, one can restrict the GRE service to certain IPs, while allowing the GRE service globally would leave the computer less secure (as the older versions of kernels did, if your suspicion is correct).
Paul
On 02/21/15 04:58, Paul Smith wrote:
On Fri, Feb 20, 2015 at 7:27 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
The truth, Gordon, is that after changing the firewall configuration as described in the referred site, the issue was fixed.
Yes, I understand that. But it sounds like GRE was allowed previously because it was "RELATED" to the pptp TCP connection before a kernel upgrade, but afterward it required a rule to allow it unconditionally (which is bad).
I can't test that because I don't have any PPTP servers available, because PPTP is very bad security-wise.
It would be useful to remove the rules that you added and verify that the PPTP connection fails. Then, boot an older kernel which was known to previously work and test the connection. If it works, then there's a kernel bug that should be reported.
Thanks, Gordon, for your reply.
If the issue is caused by the kernel, cannot one speculate that is deliberated in order to increase security? As Rick has just suggested, one can restrict the GRE service to certain IPs, while allowing the GRE service globally would leave the computer less secure (as the older versions of kernels did, if your suspicion is correct).
Paul
I don't use PPTP either, but it would seem worthwhile to file a bugzilla for completeness.
On 02/20/2015 12:58 PM, Paul Smith wrote:
If the issue is caused by the kernel, cannot one speculate that is deliberated in order to increase security? As Rick has just suggested, one can restrict the GRE service to certain IPs, while allowing the GRE service globally would leave the computer less secure (as the older versions of kernels did, if your suspicion is correct).
It might help to understand how RELATED traffic is handled. Some protocols have helpers in iptables so that when a connection will result in traffic that's not explicitly allowed, that traffic can be marked as "related" to the existing valid connection, and allowed without an explicit pre-defined rule.
For example, if you request a file by FTP, the client opens a TCP port and tells the FTP server to send the file to that port. An iptables helper can recognize that and allow the server to connect to that port, without a pre-defined rule for that server or that client port.
Likewise, when you connect to a PPTP server, the GRE packets should be related to that session, and therefore allowed. You shouldn't need to specifically allow those packets.
That's how a stateful firewall is supposed to function, and offers the best security.
Or I could be wrong and something that I'm not seeing did change in firewalld. But it's hard for me to tell, because I can't readily boot an old kernel and connect to a PPTP server in order to determine if a kernel change is the cause.
On Thu, Feb 19, 2015 at 10:57 PM, Joe Zeff joe@zeff.us wrote:
On 02/19/2015 02:46 PM, Paul Smith wrote:
The type of VPN is PPTP. With the firewall disabled, I can establish a VPN connection, but if the firewall is enabled, no VPN connection is possible.
Check your firewall settings, then, and see if the port is open.
Thanks, Joe. Is there some graphical tool for that?
Paul
On Thu, Feb 19, 2015 at 11:12 PM, Joe Zeff joe@zeff.us wrote:
Thanks, Joe. Is there some graphical tool for that?
I'm sure that there is, but it may depend on your DE. I use Xfce and system-config-firewall but YMMV.
The solution suggested in the following address works fixed the issue:
https://ask.fedoraproject.org/en/question/63759/pptp-connection-fails-after-...
Paul
On 02/19/2015 03:22 PM, Paul Smith wrote:
On Thu, Feb 19, 2015 at 11:12 PM, Joe Zeff joe@zeff.us wrote:
Thanks, Joe. Is there some graphical tool for that?
I'm sure that there is, but it may depend on your DE. I use Xfce and system-config-firewall but YMMV.
The solution suggested in the following address works fixed the issue:
https://ask.fedoraproject.org/en/question/63759/pptp-connection-fails-after-...
If you want that change made permanent to your firewall, don't forget to do
firewall-cmd --runtime-to-permanent
or add the "--permanent" flag to the "--add-rule" lines. Otherwise you'll need to repeat it each time you reboot or restart the firewall. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - If this is the first day of the rest of my life... - - I'm in BIG trouble! - ----------------------------------------------------------------------
On Thu, Feb 19, 2015 at 11:40 PM, Rick Stevens ricks@alldigital.com wrote:
Thanks, Joe. Is there some graphical tool for that?
I'm sure that there is, but it may depend on your DE. I use Xfce and system-config-firewall but YMMV.
The solution suggested in the following address works fixed the issue:
https://ask.fedoraproject.org/en/question/63759/pptp-connection-fails-after-...
If you want that change made permanent to your firewall, don't forget to do
firewall-cmd --runtime-to-permanentor add the "--permanent" flag to the "--add-rule" lines. Otherwise you'll need to repeat it each time you reboot or restart the firewall.
Thanks, Rick, for your advice. Indeed, one has to make the change permanent to the firewall.
Paul
-
Ed Greshko -
Gordon Messmer -
Joe Zeff -
Paul Smith -
Rick Stevens