<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Yes, exactly same issue for us, and it has happened in the past a few years ago fortunately. Any chance the route takes a Level 3 (3356) path? I’m just theorizing here, but my belief is they have some kind of link aggregation in the path
from TB to 3356 (or maybe just internal near some edge) and some traffic is getting hashed onto a problematic link/interface/linecard, etc. where IPSec gets dropped. One of our locations lost IPSec ability to some normal VPN endpoints but not others. And
here’s why I think this is the issue…. if you change the source and/or destination IP address by one, you may find some or all of your sessions magically work again.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In our case, one of our office locations has a static assignment of (fortunately) five IP’s. We only have one external exposed, four site to site VPN’s. Two began failing Saturday morning. I moved the office firewall’s external IP minus
1 and that fixed both, but broke one that had been fine. On the remote end fortunately I have equipment that’s able to override the local IP for VPN traffic, so without impacting other things it talks to, I was able to add a new IP one off from the previous,
and use that for traffic just to this office location; that fixed the remaining issue.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If I’d not seen this previously several years ago, and wasted who knows how many hours trying to figure it out, it would have once again taken forever to resolve. Trying to get through their support layer to someone who can really help
is impossible. The support is really complete garbage at this point after the Verizon dump; I was going to say service, but that’s been stable outside of these random weird issues that are impossible to resolve with support.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I tried to be a nice guy and raise this through the support channels, but could not make it past the layer where they want me to take our office down to have someone plug a laptop in with our normal WAN IP and “prove” ipsec isn’t working
with different equipment. I was like dude I just told you what I did to get it working again, offered packet captures, just escalate it, but ultimately gave up and hung up.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">David<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">NANOG <nanog-bounces+dhubbard=dino.hostasaurus.com@nanog.org> on behalf of Nick Olsen <nick@141networks.com><br>
<b>Date: </b>Sunday, January 24, 2021 at 8:42 PM<br>
<b>To: </b>"nanog@nanog.org" <nanog@nanog.org><br>
<b>Subject: </b>Frontier Tampa issues<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Anyone else seeing weird things on Tampa/Bradenton FIOS connections?<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I've got three unrelated customers that cant establishes IPsec back to me.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">And a third that can't process credit cards out to their third party merchant.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Customers are in <a href="http://47.196.0.0/14">47.196.0.0/14</a>.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In All instances, I see the traffic leave the CPE behind the FIOS circuit. The IPSEC traffic never makes it to my DC. And no clue on the credit card traffic. But it goes un-ack'd<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">And just now a fifth has appeared that can't query DNS against 8.8.8.8. Responses go out and never come back.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The first four all started around noon today.<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>