<html xmlns:v="urn:schemas-microsoft-com:vml" 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=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:610207022;
mso-list-type:hybrid;
mso-list-template-ids:-1044344394 -176405260 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.75in;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.25in;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.75in;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.25in;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.75in;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.25in;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.75in;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>Updating my own thread again…we tried the Shrew client on a different cable site today (Cox being the carrier), and it didn’t have any of these problems. It’s using a similar cable modem to one of the Suddenlink sites, which we discovered today are using completely different modems (one Motorola and one Arris).<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>At this point we believe this issue is related to the carriers’ configuration somehow. We punted and put in Cisco 871 routers at both Suddenlink sites, and now they’re solid.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Jim Harle [mailto:vpn@technicolor.com] <br><b>Sent:</b> Monday, July 29, 2013 1:15 PM<br><b>To:</b> vpn-help@lists.shrew.net<br><b>Subject:</b> RE: Packet loss when using 2.2.2 Windows x64 client on cable Internet connections<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:#1F497D'>I have some updated information for this problem. I haven’t received any responses for it, which is expected, as it’s a hard one </span><span style='font-family:Wingdings;color:#1F497D'>K</span><span style='color:#1F497D'>. I’m re-pasting my “symptoms” section below, with the new information called out:<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal>The Shrew Soft client works on both of these PCs, with some caveats:<o:p></o:p></p><p class=MsoListParagraph style='margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>Packet loss of up to 30% is introduced on the public connection (and likewise the tunnel) while the VPN tunnel is active. This can be verified by using the “line quality” test at <a href="http://dslreports.com/pingtest">http://dslreports.com/pingtest</a>. When no tunnel is established, there is no packet loss.<o:p></o:p></p><p class=MsoListParagraph style='margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>The packet loss through the tunnel seems to degrade over time, as does the tunnel connectivity itself. After an average of five hours, the VPN tunnel will establish and pass traffic, but only for about 30 seconds before the tunnel is dropped. A reboot of the PC makes things “better” again (connection stays up, but with much packet loss). <b>[UPDATE] – when the Shrew client gets into this state, the connection drops after about 30 seconds with a “connection terminated by gateway” message. If I stop/start the two Shrew daemon services, the VPN connection starts working again, albeit with the packet loss.</b><o:p></o:p></p><p class=MsoListParagraph style='margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>The VPN tunnel will only work with no NAT traversal (IP-to-IP ESP). If we force the Shrew client to use NAT traversal, the tunnel will establish, but no traffic will pass through it (kinda like the Cisco client problem). <b> [UPDATE] – the Shrew client does pass traffic when the NAT traversal setting is ‘force-rfc.’ Interestingly, we have other sites where the Cisco client will not pass traffic regardless of NAT-T setting, and the Shrew client will only pass traffic using this ‘force-rfc’ NAT-T.</b><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>We are installing Cisco 871 VPN routers at these two sites today and tomorrow, so this problem may become academic for now. Still, I can reproduce the problem at my house if anyone has any ideas. Installing 871s throws off our cost-model for this project, so we only want to use them when absolutely necessary, and I’m sure more problematic Cable sites will turn up.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Jim Harle <br><b>Sent:</b> Friday, July 26, 2013 4:47 PM<br><b>To:</b> 'vpn-help@lists.shrew.net'<br><b>Subject:</b> Packet loss when using 2.2.2 Windows x64 client on cable Internet connections<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Greetings, this is my first post to this list. It is quite long, so if you have no interest in reading the context, you can skip to the last sentence at the end.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We are in the midst of a project involving Windows 7 x64 PCs which are “directly” connected to the Internet (public IP resides on a NIC in the PC), as opposed to behind a NAT device/hardware firewall as is typical. These Windows PCs are using the Cisco VPN client (IPsec with NAT traversal, split-tunneled) to connect to a Cisco ASA gateway in our datacenter. This ASA terminates many hundred VPN tunnels, mostly from Cisco 871 routers. The Internet connections for the PCs are mixture of “commercial grade” DSL or cable (mostly DSL)…using various carriers.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We’ve had intermittent issues with the Cisco client, where it will establish the VPN tunnel, but not pass private traffic through the tunnel. This is nearly always cleared up by power-cycling the DSL modem. We have two chronic sites in Texas, both using Suddenlink cable Internet, which are having the Cisco-connects-but-doesn’t-pass traffic problem. However, power-cycling the cable modem at these sites doesn’t always fix it. So, we decided to try the Shrew Soft 2.2.2 client on these two PCs.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The Shrew Soft client works on both of these PCs, with some caveats:<o:p></o:p></p><p class=MsoListParagraph style='margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>Packet loss of up to 30% is introduced on the public connection (and likewise the tunnel) while the VPN tunnel is active. This can be verified by using the “line quality” test at <a href="http://dslreports.com/pingtest">http://dslreports.com/pingtest</a>. When no tunnel is established, there is no packet loss.<o:p></o:p></p><p class=MsoListParagraph style='margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>The packet loss through the tunnel seems to degrade over time, as does the tunnel connectivity itself. After an average of five hours, the VPN tunnel will establish and pass traffic, but only for about 30 seconds before the tunnel is dropped. A reboot of the PC makes things “better” again (connection stays up, but with much packet loss).<o:p></o:p></p><p class=MsoListParagraph style='margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>The VPN tunnel will only work with no NAT traversal (IP-to-IP ESP). If we force the Shrew client to use NAT traversal, the tunnel will establish, but no traffic will pass through it (kinda like the Cisco client problem).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’ve attempted to analyze what is happening using Wireshark, although I’m not gleaning any useful information from the packet captures. I’ve also tried various MTU settings, with the same results as above.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>A colleague and I have also tried testing the Shrew client on one of these PCs, while directly connected to our cable modems (we both use Comcast). We experience the identical symptoms as I’ve listed above, although we have more success with the Cisco client working than our Suddenlink sites (but the Cisco client doesn’t always pass traffic). Even weirder, I’ve confirmed the same symptoms using completely different hardware/NICs, and also different Windows versions (7 and 8), connecting to two different Cisco ASA gateways, all with the same results. My colleague installed Ubuntu on one of our PCs and tried that with the Shrew client, and that one worked just fine – no packet loss or problems. Additionally, we have tried the Shrew client on DSL and fiber-connected Internet sites, using the same PCs (identical hardware and OS image), and those have been solid. It is truly a mystery why the Windows PCs have a problem with the Shrew client on four different cable connections.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>So finally, I simply ask the question, has anyone else seen a packet loss issue when using the Shrew x64 client on a Windows PC, using a “direct” cable Internet connection (no NAT device between the PC and bridged cable modem)?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Many thanks,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Jim<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>