<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Juniper recommends setting a reduce MTU on VPNs to allow for overhead. Does your configuration include that?<br><br>Bob Webber</div><div><br>On Jan 24, 2014, at 17:34, Nick Cammorato <<a href="mailto:nick.cammorato@gmail.com">nick.cammorato@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>The problem is universal from the VPN to any device on any network that has it's gateway on the SRX. It doesn't show up if the VPN isn't in the picture or if the destination server is off a different piece of gear, so it has got to be some kind of interaction between the two(and it showed up when the VPN gateway was moved to the SRX), I just can't think of what it could be. </div>
<div><br></div><div>I can transfer from confluence A or Confluence B to anything but a VPN client at normal speeds (1-10gbps or tunnel maxes depending), via iperf, scp, wget, curl, ftp, what have you - it only slows down if the VPN is in the picture.</div>
<div><br></div>Everything has claimed to negotiate down to 100/full - and the problem showed up identically when the ASA was off a switch(as opposed to directly connected) where that definitely was not an issue. I've run into that one before(it's fun!) though with a Verizon Fiber NID. <div>
<br></div><div>All of the firewall rules are off, everything is in default permit at present until we settle in from the current change.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 24, 2014 at 4:36 PM, John Stoffel <span dir="ltr"><<a href="mailto:john@stoffel.org" target="_blank">john@stoffel.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>>>>> "Nick" == Nick Cammorato <<a href="mailto:nick.cammorato@gmail.com">nick.cammorato@gmail.com</a>> writes:<br>
<div class="im"><br>
Nick> On Fri, Jan 24, 2014 at 12:39 PM, John Stoffel <<a href="mailto:john@stoffel.org">john@stoffel.org</a>> wrote:<br>
>><br>
>> Nick,<br>
>><br>
>> From looking at your description, it really sounds like you've got<br>
>> some sort of caching in the middle which is slowing things down. But<br>
>> you don't explain the other side of the VPN well enough to know.<br>
>><br>
>><br>
</div>Nick> No caching, no application acceleration anywhere I'm aware of.<br>
<div class="im"><br>
<br>
>> Can the client using the VPN got a simple FTP from either of your<br>
>> Confluence servers at full speed? Or can they pull http data from<br>
>> other internal hosts over the VPN at full speed.<br>
>><br>
<br>
</div>Nick> Installed vsftpd real quick, SCPed a test file over to the pub<br>
Nick> directory - it started at 2.5 and went up to 3.5 MB/s on the<br>
Nick> transfer up.<br>
<br>
That's a good sign...<br>
<br>
Nick> Pulled back down over FTP and SCP at 10kbps.<br>
<br>
But that's bad. So there's something between your Confluence server<br>
and the device on the other side of the VPN that's choking things.<br>
Hmm... can you do fast downloads from other systems via the VPN<br>
connection, or are the Confluence the only ones slow sending data out<br>
the VPN?<br>
<br>
Oh! Have you checked the speeds of all your connections? It's almost<br>
like you have the dreaded 100mbit - 1GigE mis-configuration that the<br>
old Sun hme (Happy Meal Ethernet) interfaces used to have at one time<br>
with Cisco devices. Autonegotiation would break down, etc.<br>
<br>
Can you use 'iperf' on the Confluence side to see if you can push a<br>
bunch of data to various other systems, to try and narrow down where<br>
in the chain of network hops the slowdown happens? Or even just doing<br>
scp to/from the box from various spots sould help narrow it down.<br>
<br>
Something is seriously wrong in the network. Heck, it could be the<br>
ASA is just hammered, or has a poorly written firewall rule or something.<br>
<br>
Nick> The fact that serial access is slow, while parallel access is fast<br>
<div class="im">>> is... surprising. Does each access when done in parallel stay at<br>
>> 10kbps, or do they all speed up to whatever the max the pipe to their<br>
>> end supports.<br>
>><br>
<br>
</div>Nick> The all speed up(to 200kbps or so) until one remains, then it drops back<br>
Nick> down. It's utterly bizzare.<br>
<div class="HOEnZb"><div class="h5">Nick> _______________________________________________<br>
Nick> bblisa mailing list<br>
Nick> <a href="mailto:bblisa@bblisa.org">bblisa@bblisa.org</a><br>
Nick> <a href="http://www.bblisa.org/mailman/listinfo/bblisa" target="_blank">http://www.bblisa.org/mailman/listinfo/bblisa</a><br>
</div></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>bblisa mailing list</span><br><span><a href="mailto:bblisa@bblisa.org">bblisa@bblisa.org</a></span><br><span><a href="http://www.bblisa.org/mailman/listinfo/bblisa">http://www.bblisa.org/mailman/listinfo/bblisa</a></span></div></blockquote></body></html>