- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ever since the Feb 5 update, I have to restart my router four/five times a day to get it to allow incomming port forwarding to work again. Can't figure out why this is the case, but NEVER had to do that before the Feb 5 update push.
I fear saving the configuration and doing a refresh because I have nearly 50 address reservations for the home network for a home theater and whole house CONTROL4 system. The thought of having to recreate all those address reservations and MAC Address assignments is daunting. Especially because the last time I received an automatic router update, Verizon stompted my config and though I save it regularly, the router refused to load the file and I had to rebuild from scratch! Address Reservations, Port Forwarding Rules, Parental Controls, Firewall settings. All of it.
Here we go again! I sure wish verizon would give us the option of taking a firmware push! I don't like to fix what isn't broken!
Anyone else having issues since the push of Feb 5?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is nutz! **bleep** it Verizon. I had a perfectly good working quantum router! Now, I have an unstable, non functioning router!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some of the pushes are to enable new servcies or the like.
How many support calls do you think they would get if the had people on all different configs and firmware versions.
And I thought the main thing in the last update was related to 5GHz ssid naming.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Completely reset router, and rebuilt all my Address Reservations, Port Forwarding Rules, etc. Now the router at least forwards correctly for all ports defined EXCEPT the LLTP VPN. It works for 30 miutes, then stops forwarding VPN traffic to my VPN Server. Reboot the router, and traffic flow again!
I'm at the end of my rope with Verizon. I had a perfectly working router on February 4th. Now I don't!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Four hours on the phone with Level 2 engineering.
Apparently, the Feb 5, 2016 firmware update also contained a payload that disables INBOUND VPN connections to the customer's home network. So though I have the correct port forwarding rules to allow my home VPN server to accept and create an INBOUND VPN L2TP Tunnel, the latest firmware push detects and disables this ability, or so they told me.
I created a VPN server on my Mac Mini at home. I also use VPN to run my CONTROL4 home automation app which requires a paid subscription to access the CONTROL4 controller at home, or they advise connecting to your home network with VPN, and then you can use the app without paying for their remote service.
So now in Verizon's great wisdom, they feel that establishing a VPN connection to your home network is a security risk and have shut it down, by trickery and backdoor of the customer's premise equipment, sneaking it in through a firmware update meant to separate wifi 2.4ghz and 5ghz SSIDs.
So I ask those advanced readers of this forum... Do you have home VPN services and are you also experiencing the shutdown of this capability? Or are the level 2 engineering dumping a story on me since they can't tell me why it works for about an hour when the router reboots, but then stops!
Remember folks, this is only for the G1100 Quantum Gateway Router (not actiontec)...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Wow. First they chisel a permanent hole for their TR-069 management traffic that can't be deactivated and then they disable inbound VPN?
Strictly speaking, I seem to recall some prohibition against running "servers" in their terms of service. The problem with that in the modern world is that the distinction between an application that is a server and an application that is merely a client has blurred quite a bit. Modern versions of Microsoft Windows start something on the order of hundreds of background processes at boot time, many of which exist to listen for something happening via a network interface.
VPNs are less challenging to provision properly than ever before, but they're still a pain. I'm surprised they've seen so much activity that they're calling that a security risk.
Note: You might consider trying either something like Chrome Remote Access or any of the LogMeIn products, as they might let you get at least to computers within your home enclave. Any VPN using a "rendezvous" server initiated by a host on your internal network will probably work. It's too bad that doing it according to the RFCs seems to be discouraged.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can't use the RDP type products to solve this problem. I have a CONTROL4 home automation solution and in order for me to use the iOS app, I have to be able to connect remotely to my home network. VPN has always worked for me very well, stable and easy. Until the Feb 5 update. Now I'm completely hosed.
And after speaking with Verizon engineering, they readily admit they've included the payload on the Feb 5 Firmware to stop INBOUND VPN. So I asked for the release notes on the firmware upgrade and they said they don't produce or disclose that information.
So if I buy a commercial product, linksys, netgear, etc, they all release firmware updates with release notes. Verizon does not, and so you NEVER know what you're getting with VZ. Looks like I'm going to have to go third party router!
I'll take the trade offs and limitations because doing business with VZ like this is simply a gamble I can't afford to take. My ISP suddenly determines what's best for me? I wonder what backdooring they've also created to spy on my traffic?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can confirm that this issue is still alive and well. I just received a Quantum FIOS-G1100 router, Firmware v 01.03.02.03. Set up my L2TP port forwarding just as I had on my Actiontec router. The port forwaridng absolutley works for a period of time and then for unknown reason simply stops forwarding those ports or listening.
I've tried adding the L2TP rules as a NAT rule. It works. ANd then later in the day it just stops working. The only workaround I have found is to delete the forwaridng rules and then add them again. It will work for a period of time and then will again stop working for unknown reasons.
I called FIOS level 2 support and was on a group call with 2 technicians. Both never heard of this issue. They suggested all kinds of things (DMZ) that are not an option. The only good suggeston they made was recommending that I revert to the Actiontec router. Might not be a bad idea. Which means another clal to FIOS support (save me!). But I did want them to be aware that this issue is real.
The oddity is that all my other port forward rules work perfectly fine and keep on working. I have PPTP forwarding port 1723. It works consistently and hasn't suffered any issues, which I also explained to the Level2 techs.
Really sucks that macOS 10.12 (Siera) has phased out PPTP. Although much less secure its a lot more stable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Eureka!!! I think I may have solved the issue and it is so ridiculous. Hours of hair pulling and all due to Verizon's preset L2TP port forwaridng rules.
Based on other research I found...It seems the built-in port forwarding rules for L2TP on the FIOS Quantum Gateway router G1100 may be incorrect. The preset rules show the same source and destination UDP ports for 1701, 500, and 4500. This apparently will not work even though it should. What I found that does work is the source UDP port for each port should be set to ANY and the destination ports respectively set to UDP 1701, 500, and 4500. As well as services for GRE, ESP, and AH (these are not in the default built in port forwarding rules but I added them myself).
The correct port forwarding rules for L2TP
UDP Any -> 1701
UDP Any -> 500
UDP Any -> 4500
GRE
ESP
AH
Obviously in many of the reported cases for this L2TP issue on FIOS routers it will work at first and maybe for an hour and then for unknown reasons just stop working so I will be able to report on that tomorrow. But for right now it is working since I changes the source ports to ANY, whereas before it would not work at all using the same source and destination port numbers.