Koozali.org: home of the SME Server
Obsolete Releases => SME Server 9.x => Topic started by: brianjbarber on March 05, 2018, 12:58:31 PM
-
I'm sure this has been asked before and I assure you that I have looked thoroughly for an answer before posting here. If I missed the answer in my travels, please be kind.
I have been using e-smith/smeserver for years and haven't had a problem with internal Windows clients connecting to remote VPN hosts using PPTP. I upgraded to v9 and now none of them can connect. When I did the upgrade, I backed up the old server, did a fresh install on a new one and restored the backup; therefore, the settings should be the same (in theory). Upgrading to v9 on new hardware is the only major change that has been implemented.
In my searching for an answer to the VPN issue, I have seen forum posts and smeserver documentation that suggests that GRE passthrough in smeserver is not possible. Is this true? How have you folks enabled this for Windows clients on your networks? I tried portforwarding 1723 to the remote VPN host, but this didn't do the trick.
-
There used to be code in the masq template fragments that associated GRE with any port forward of port 1723 for inbound PPTP - but outbound shouldn't need any rules unless you've implemented one of the solutions for blocking all outbound traffic for data privacy or security.
I found this post on the centos forums from someone with the same problem. He found that one of the pieces needed for PPTP passthru had been disabled by default for security reasons in centos itself. He shows how to enable it (on Centos 7). There is probably a more "SME-Friendly" way to do this, too:
https://www.centos.org/forums/viewtopic.php?t=63180
-
I'd add that you'd really try to replace pptpd with something more secure.. pptp is not.
-
I'd add that you'd really try to replace pptpd with something more secure. pptp is not.
If I were king, I would have done this long ago. Sadly, I don't have any control over the remote host.
-
There used to be code in the masq template fragments that associated GRE with any port forward of port 1723 for inbound PPTP - but outbound shouldn't need any rules unless you've implemented one of the solutions for blocking all outbound traffic for data privacy or security.
I found this post on the centos forums from someone with the same problem. He found that one of the pieces needed for PPTP passthru had been disabled by default for security reasons in centos itself. He shows how to enable it (on Centos 7). There is probably a more "SME-Friendly" way to do this, too:
https://www.centos.org/forums/viewtopic.php?t=63180
Thanks for the guidance. I don't recall implementing anything that blocks data security or privacy. I tried to keep the firewall as transparent as possible. I'd like to know if anything changed in this area between smeserver 8 and 9.
Regarding the CentOS solution, thanks so much for finding this for me. I will try this in my lab at home this evening and report back.
-
PPTP
<Shakes head and thinks fondly of the dodo>
Without trying to be funny, you really should be trying to give the remote end a decent sized kick in the pants. PPTP is so bust you may as well not bother and do it all in plain view. You have zero protection. If you have anything that legally affects transmission of data you haven't got a leg to stand on quite frankly. It really is that serious.
Tell the far end they can accept responsibility for any sue balls you face.
Note Apple recently kicked PPTP in to touch permanently. You should be doing the same.
My 2c worth.
-
Without trying to be funny, you really should be trying to give the remote end a decent sized kick in the pants...
Tell the far end they can accept responsibility for any sue balls you face.
Note Apple recently kicked PPTP in to touch permanently. You should be doing the same.
Thank you for taking the time to reply, but as I said earlier, I have zero control over what is running at the other end. I also have an inflexible business requirement to get this working. Do you have a solution to offer?
-
My experience is that PPTP VPN works (subject to the security issues) from a "lone" PC to an SMEServer fine, but from a PC in a network controlled by a gateway SMEServer to an SMEServer under V8 sometimes worked and sometimes didn't (possibly dependant on CPU / Kernel Version, etc - the problem is one of timing I think). Under V9 it has never worked. My main user has gone to Ipsec modems.
You could try making the SMEServer on the client side just a server, not a gateway - that might work.
-
Thank you for taking the time to reply, but as I said earlier, I have zero control over what is running at the other end. I also have an inflexible business requirement to get this working. Do you have a solution to offer?
I don't wish to appear to be difficult. Just trying to get you to think of the security implications.
Regrettably I don't have a secure solution that fits your requirements.
It would be like telling you how to use a front door lock when I know all your windows are open with big signs next to them "saying please rob me"
I've written ipsec and l2tpd/ipsec contribs that work and Daniel has written openvpn solutions for this very reason (although they are server solutions). They are typical of what you should be using. If you are transmitting data to/from Europe you should be also be considering the effect of GDPR on your data that is being knowingly transmitted insecurely.
If you want to carry on regardless you probably ought to look at your iptables logs and use tcpdump etc to look at where the packets are going.
My guess is SME was designed originally to be a pptp server, and that you may need some custom iptable rules to allow passthrough instead.
Like I said, I am not try to be difficult. Just realistic and giving you best advice.
B. Rgds
John
-
@brianjbarber,
I don't know why the remote site is using PPTP, but you may want to take GDPR (https://en.wikipedia.org/wiki/General_Data_Protection_Regulation) into account as argumentation to ditch PPTP or refuse to work with PPTP at all due to your personal liability.
Simple fact, IF you are even REMOTELY aware of any possible weaknesses, you are fully liable. Period.
-
Given all this sage advice cannot be actioned, then I have previously used the following to route the PPtP connections to an internal Windows server, it may give you a hint on what & where to check:
vpnserver="10.0.0.7"
/sbin/iptables -N pptp
/sbin/iptables -A pptp -p tcp --destination-port 1723 --dst $vpnserver -j ACCEPT
/sbin/iptables -A pptp -p 47 --dst $vpnserver -j ACCEPT
/sbin/iptables -I FORWARD -j pptp
/sbin/iptables -t nat -N pptp
/sbin/iptables -t nat -A pptp -i eth1 -p tcp --dport 1723 -j DNAT --to $vpnserver:1723
/sbin/iptables -t nat -A pptp -i eth1 -p 47 -j DNAT --to $vpnserver
/sbin/iptables -t nat -A PREROUTING -j pptp
-
Or you could simply use SoftetherVPN, and ignone SME Server build in PPTP.
https://wiki.contribs.org/SoftEther_VPN
https://wiki.contribs.org/SoftEther_VPN (https://wiki.contribs.org/SoftEther_VPN)
-
Given all this sage advice cannot be actioned,
Anything CAN be done. It is all about will.
If the client is European then they fall under GDPR. If you knowingly assist them in running a system that is known to be insecure then you can be liable. Giving him a 'solution' which is insecure is not best advice.
I personally would have it in black and white that I had advised the client of their responsibilities and liabilities and suggest they change provider soonest. And if they weren't going to change, I'd probably leave them to it.
It really IS that serious.
Regrettably burying your head in the sand doesn't wash in front of a judge.
I'm not trying to be unkind. Just trying to give the correct answer (even it if isn't what they want to hear), and prevent the OP, and his client, from getting sued.
Telling him anything else effectively makes me complicit too.