pptpd VPN: No internet access after connecting
I’ve followed the instructions in this tutorial to set up a vpn server, so that I can connect to that and surf the internet virtually from another location. So far from windows, I can connect to it but there is no internet access. The ip addresses that I used in the conf file is exactly the same as in the tutorial
localip 192.168.0.1 remoteip 192.168.0.100-200 Same for the DNS which is 8.8.8.8. (Everything you need to know about what I’ve done is already in that link) What do you think could be the problem ?
@meccooll: Sorry for my previous comment, that netstat worked like a magic. I’m through now but HTTPS websites not getting opened, the browser says SSL Connection Problem, do you have any idea ?
3 Answers 3
If your main purpose of setting up the VPN server is to access website, So traffic has to be forwarded out of the VPN server’s public network interface.Thus, kindly enable port forwarding by editing the sysctl.conf file. I assume “net.ipv4.ip_forward” is commented in the /etc/sysctl.conf file:
Add or find and comment out the following line
Save, close the file and run the following command to make the changes take effect.
The following iptables firewall rules allow port 1723, GRE and perform NAT
iptables -I INPUT -p tcp --dport 1723 -m state --state NEW -j ACCEPT iptables -I INPUT -p gre -j ACCEPT iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE In the last rule replace “eth0″ with the interface connecting to the internet on your VPN server. Finally the following rule is required to ensure websites load properly
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -s 172.20.1.0/24 -j TCPMSS --clamp-mss-to-pmtu Replace 172.20.1.0/24 with the IP address range used in the “remoteip” option in the /etc/pptpd.conf this firewall rule is used to ensure a proper MTU value is used to prevent fragmentation.
The following command solved my problem (No internet) using PPTPD on Ubuntu 14.x
iptables -I INPUT -p tcp --dport 1723 -m state --state NEW -j ACCEPT iptables -I INPUT -p gre -j ACCEPT iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -s 10.0.0.0/24 -j TCPMSS --clamp-mss-to-pmtu sudo iptables-save sudo iptables -P FORWARD ACCEPT sudo iptables -P OUTPUT ACCEPT sudo iptables-save Please note: I used this IP address range 10.0.0.0/24 in my /etc/pptpd.conf use the range that matches your config as well.
We had identical symptoms, but all the Iptables where set as above. It was possible to connect, the connection was stable, it did allow to login to the pptp server via ssh and, in the remote machine, even to resolve DNS (noticeable via browers and ping — as it did resolve correctly the IP), but webpages did not load, neither was possible to connect to other severs via ssh. This made clear that the tunnel was ok to the pptp server.
The problem was the fact that I had in this machine two independent up-links exposed to internet (ie. mainInf and support), both configured via netplan (no problem with that) but, despite connecting to the pptp server using the IP address of the 1st up-link (i-face called mainInf), my default gateway was running in the seccond up-link (support).
The solution was to adjust the NAT to the correct output gateway and that allowed packets to reach other servers it was initially (not working)
iptables -t nat -I POSTROUTING -o mainInf -j MASQUERADE (have in your mind that, in our case, the connection to the pptp server is via an IP allocated in the mainInf adapter/uplink) and after changing to the same adapter/uplink as the default gateway (support), it worked:
iptables -t nat -I POSTROUTING -o support -j MASQUERADE Hence, if you can stability the VPN connection, ping or connect the pptp server (via ssh in our case), but cannot reach any IP that is not in that server, you probably have a routing/forwarding issue.
4 helpful commands for troubleshoting:
- watch iptables -t nat -L -nv
- watch iptables -L -nv
- route -n
- tcpdump -i -s 0 tcp port 1723 or proto 47 (read more here)
pptpd VPN: нет доступа в интернет после подключения
Я следовал инструкциям в этом руководстве, чтобы настроить сервер vpn, чтобы я мог подключиться к нему и просматривать Интернет практически из другого места. Так далеко от окон, я могу подключиться к нему, но нет доступа в Интернет.
IP-адреса, которые я использовал в файле conf, точно такие же, как в руководстве
localip 192.168.0.1 remoteip 192.168.0.100-200 То же самое для DNS, который 8.8.8.8.
(Все, что вам нужно знать о том, что я сделал, уже есть в этой ссылке)
Как вы думаете, может быть проблема?
2 ответа
Если вашей основной целью настройки VPN-сервера является доступ к веб-сайту, то трафик должен перенаправляться из общедоступного сетевого интерфейса VPN-сервера. Таким образом, включите переадресацию портов, отредактировав файл sysctl.conf. Я предполагаю, что «net.ipv4.ip_forward» комментируется в файле /etc/sysctl.conf:
Добавьте или найдите и закомментируйте следующую строку
Сохраните, закройте файл и выполните следующую команду, чтобы изменения вступили в силу.
Следующие правила брандмауэра iptables разрешают порт 1723, GRE и выполнять NAT
iptables -I INPUT -p tcp --dport 1723 -m state --state NEW -j ACCEPT iptables -I INPUT -p gre -j ACCEPT iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE В последнем правиле замените «eth0» на интерфейс подключения к интернету на вашем VPN-сервере. Наконец, для правильной загрузки сайтов необходимо следующее правило
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -s 172.20.1.0/24 -j TCPMSS --clamp-mss-to-pmtu Замените 172.20.1.0/24 диапазоном IP-адресов, который используется в параметре «remoteip» в /etc/pptpd.conf. Это правило брандмауэра используется для обеспечения правильного значения MTU для предотвращения фрагментации.
Следующая команда решила мою проблему (без интернета) с использованием PPTPD на Ubuntu 14.x
iptables -I INPUT -p tcp --dport 1723 -m state --state NEW -j ACCEPT iptables -I INPUT -p gre -j ACCEPT iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -s 10.0.0.0/24 -j TCPMSS --clamp-mss-to-pmtu sudo iptables-save sudo iptables -P FORWARD ACCEPT sudo iptables -P OUTPUT ACCEPT sudo iptables-save Обратите внимание: я использовал этот диапазон IP-адресов 10.0.0.0/24 в моем /etc/pptpd.conf используйте диапазон, который соответствует вашей конфигурации.
У нас были идентичные симптомы, но все Iptables были настроены так, как указано выше. Было возможно подключиться, соединение было стабильным, оно позволяло войти на сервер pptp через ssh и, на удаленном компьютере, даже разрешить DNS (это заметно через браузеры и ping — поскольку он правильно разрешил IP), но веб-страницы не загружались, и невозможно было подключиться к другим серверам через ssh. Это дало понять, что туннель для сервера pptp в порядке.
Проблема заключалась в том, что на этой машине у меня было два независимых восходящих канала, открытых в Интернет (например, mainInf и поддержка), оба настроены через netplan (с этим проблем нет), но, несмотря на подключение к серверу pptp с использованием IP-адреса 1-й восходящий канал (i-face, называемый mainInf), мой шлюз по умолчанию работал во втором восходящем канале (поддержка).
Решением было настроить NAT на правильный выходной шлюз, что позволило пакетам достигать других серверов, как это было изначально (не работало).
iptables -t nat -I POSTROUTING -o mainInf -j MASQUERADE (имейте в виду, что в нашем случае соединение с сервером pptp осуществляется через IP-адрес, выделенный в адаптере mainInf / восходящей линии связи), и после перехода на тот же адаптер / восходящий канал, что и шлюз по умолчанию (поддержка), он работал:
iptables -t nat -I POSTROUTING -o support -j MASQUERADE Следовательно, если вы можете стабилизировать VPN-соединение, проверить связь или подключиться к серверу pptp (в нашем случае через ssh), но не можете получить доступ к IP-адресу, которого нет на этом сервере, у вас, вероятно, есть проблема с маршрутизацией / пересылкой.
4 полезных команды для устранения неполадок:
- смотреть iptables -t nat -L -nv
- смотреть iptables -L -nv
- маршрут -n
- tcpdump -i -s 0 TCP-порт 1723 или proto 47 (подробнее здесь)