A customer of mine has had the same issue with a TW-connected site in
Ohio and another in PA. One VPN tunnel works fine, the other has
one-way ISAKMP traffic to the other head-end, which connects to Level3.
A traceroute shows the failing path includes 66.109.7.162. The failing
direction is from the PA/OH sites toward the L3 head end. Full-size
pings work fine. It's the UDP/500 that vanishes. I.E., it has nothing
to do with MTU.
Both started having the issue around Aug 26. Mysteriously, every week
to 10 days, the broken path will start working for a while. This is
usually shortly after midnight EDT; they go back down 1-3 hours later
and stay down. The log entries for the two sites match within seconds.
The customer's contract is with Comcast Business so it's been difficult
to get to someone clueful about this symptom in TW.
-Marty
On 10/15/2019 8:04 AM, Biddle, Josh via Outages wrote:
Found a thread in the Spectrum forums talking about the issue finally
– it was marked as resolved so I started a new one.
https://forums.timewarnercable.com/t5/Connectivity/Traffic-issues-at-66-109-7-162/m-p/164091#M53497
*From:* Outages <outages-boun...@outages.org> *On Behalf Of *Biddle,
Josh via Outages
*Sent:* Sunday, October 13, 2019 12:00 PM
*To:* outages@outages.org
*Subject:* [outages] VPN issues over Spectrum L3 boundaries
We have several offices over the Ohio and Pennsylvania area that are
experiencing issues passing traffic over VPN tunnels (specifically,
there is always a Spectrum >< Level 3 interconnect). It is a very
strange issue. The VPN tunnel will actually establish, and if you
source your ping from inside the internal network across the VPN
tunnel to the destination, the traffic gets there and replies, but the
replies never make it back to the original sending point.
Anyone else experiencing any similar issues like this?
Best Regards,
*Josh*
_______________________________________________
Outages mailing list
Outages@outages.org
https://puck.nether.net/mailman/listinfo/outages
