Solving the problem of connecting PPTP VPN via LTE from Yota
To connect remote offices to corporate networks and telephony in the absence of wired providers, we use LTE from Yota and all-in-one routers DrayTek Vigor 2920VN.
The other day I came to set up the next set of DrayTek 2920 + Yota LU150. This modem itself is a mini-router, and by default it issues an IP address connected to it via a USB host from the subnet 10.0.0.0/24, which in my case intersected with the local network. In the modem settings at % modemip% / network, you can change the range - 192.168.0.0/24 and 172.16.0.0/24 are available to choose from.
Changing the range to 172.16.0.0/24, I set up the router according to the standard, already tested scheme. And here - a bummer: the Internet works, and the VPN tunnel to the central office does not rise. By the way, at that time everything works on the same router with the same modem in one of the remote offices. Devilry? No, the engineers do not believe the devil!
At first the suspicion fell on the VPN server (FreeBSD + poptop) in the central office. After seeing the log, I stated the failure of the GRE packets from the DrayTek side. Stirlitz alert. I plugged the modem into my laptop directly, created a VPN connection using Windows 7 standard tools - it also does not work, giving error 619. I checked it through my home provider - everything works. Just in case, I returned the range of addresses on the modem to the previous 10.0.0.0/24 - the same picture. So, the cause of the problem is Yota.
')
Time 2 am. I call support. The boy at the end of the wire clearly does not really understand what a VPN is, carries nonsense about routing, and as a solution proposes to connect an external IP. Okay, I postpone the solution of the problem until the next day - should I be there in the afternoon, even if on a day off, is there someone from the second line of support?
The day is coming. I call support. Switch to line 2. I present the essence of the problem. I am immediately asked the question - “have you, a good citizen, changed the IP range on the modem”?
The case turned out to be in the latest version 3.7 LU150 modem bug (namely, all modems with old firmware are automatically updated to this version): when changing the range, it ceases to skip the GRE traffic, and changing back does not help. This problem is solved by manually changing the modem's firmware to a test 3.7.4, which was kindly sent to me by a tech support officer, saying goodbye: “the problem seems to be solved in this firmware, but you don’t change the IP range on the modem anyway.”
Nowhere in the web of this firmware in the public access was not found, so I post it here. (link removed at the request of the company Yota. Anyone who has encountered the described problem can receive the firmware via a call to the support).
At the moment, this problem is present in all modems from Yota, so you should not change the network settings of modems before fixing the bug - they mentioned in the support that this is not the only cant that fits when the settings are changed.
The other day I came to set up the next set of DrayTek 2920 + Yota LU150. This modem itself is a mini-router, and by default it issues an IP address connected to it via a USB host from the subnet 10.0.0.0/24, which in my case intersected with the local network. In the modem settings at % modemip% / network, you can change the range - 192.168.0.0/24 and 172.16.0.0/24 are available to choose from.
Changing the range to 172.16.0.0/24, I set up the router according to the standard, already tested scheme. And here - a bummer: the Internet works, and the VPN tunnel to the central office does not rise. By the way, at that time everything works on the same router with the same modem in one of the remote offices. Devilry? No, the engineers do not believe the devil!
At first the suspicion fell on the VPN server (FreeBSD + poptop) in the central office. After seeing the log, I stated the failure of the GRE packets from the DrayTek side. Stirlitz alert. I plugged the modem into my laptop directly, created a VPN connection using Windows 7 standard tools - it also does not work, giving error 619. I checked it through my home provider - everything works. Just in case, I returned the range of addresses on the modem to the previous 10.0.0.0/24 - the same picture. So, the cause of the problem is Yota.
')
Time 2 am. I call support. The boy at the end of the wire clearly does not really understand what a VPN is, carries nonsense about routing, and as a solution proposes to connect an external IP. Okay, I postpone the solution of the problem until the next day - should I be there in the afternoon, even if on a day off, is there someone from the second line of support?
The day is coming. I call support. Switch to line 2. I present the essence of the problem. I am immediately asked the question - “have you, a good citizen, changed the IP range on the modem”?
The case turned out to be in the latest version 3.7 LU150 modem bug (namely, all modems with old firmware are automatically updated to this version): when changing the range, it ceases to skip the GRE traffic, and changing back does not help. This problem is solved by manually changing the modem's firmware to a test 3.7.4, which was kindly sent to me by a tech support officer, saying goodbye: “the problem seems to be solved in this firmware, but you don’t change the IP range on the modem anyway.”
At the moment, this problem is present in all modems from Yota, so you should not change the network settings of modems before fixing the bug - they mentioned in the support that this is not the only cant that fits when the settings are changed.
Source: https://habr.com/ru/post/160961/
All Articles