Juniper recommends setting a reduce MTU on VPNs to allow for overhead. Does your configuration include that?
Bob Webber > On Jan 24, 2014, at 17:34, Nick Cammorato <[email protected]> wrote: > > 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. > > 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. > > 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. > > All of the firewall rules are off, everything is in default permit at present > until we settle in from the current change. > > >> On Fri, Jan 24, 2014 at 4:36 PM, John Stoffel <[email protected]> wrote: >> >>>>> "Nick" == Nick Cammorato <[email protected]> writes: >> >> Nick> On Fri, Jan 24, 2014 at 12:39 PM, John Stoffel <[email protected]> >> wrote: >> >> >> >> Nick, >> >> >> >> From looking at your description, it really sounds like you've got >> >> some sort of caching in the middle which is slowing things down. But >> >> you don't explain the other side of the VPN well enough to know. >> >> >> >> >> Nick> No caching, no application acceleration anywhere I'm aware of. >> >> >> >> Can the client using the VPN got a simple FTP from either of your >> >> Confluence servers at full speed? Or can they pull http data from >> >> other internal hosts over the VPN at full speed. >> >> >> >> Nick> Installed vsftpd real quick, SCPed a test file over to the pub >> Nick> directory - it started at 2.5 and went up to 3.5 MB/s on the >> Nick> transfer up. >> >> That's a good sign... >> >> Nick> Pulled back down over FTP and SCP at 10kbps. >> >> But that's bad. So there's something between your Confluence server >> and the device on the other side of the VPN that's choking things. >> Hmm... can you do fast downloads from other systems via the VPN >> connection, or are the Confluence the only ones slow sending data out >> the VPN? >> >> Oh! Have you checked the speeds of all your connections? It's almost >> like you have the dreaded 100mbit - 1GigE mis-configuration that the >> old Sun hme (Happy Meal Ethernet) interfaces used to have at one time >> with Cisco devices. Autonegotiation would break down, etc. >> >> Can you use 'iperf' on the Confluence side to see if you can push a >> bunch of data to various other systems, to try and narrow down where >> in the chain of network hops the slowdown happens? Or even just doing >> scp to/from the box from various spots sould help narrow it down. >> >> Something is seriously wrong in the network. Heck, it could be the >> ASA is just hammered, or has a poorly written firewall rule or something. >> >> Nick> The fact that serial access is slow, while parallel access is fast >> >> is... surprising. Does each access when done in parallel stay at >> >> 10kbps, or do they all speed up to whatever the max the pipe to their >> >> end supports. >> >> >> >> Nick> The all speed up(to 200kbps or so) until one remains, then it drops >> back >> Nick> down. It's utterly bizzare. >> Nick> _______________________________________________ >> Nick> bblisa mailing list >> Nick> [email protected] >> Nick> http://www.bblisa.org/mailman/listinfo/bblisa > > _______________________________________________ > bblisa mailing list > [email protected] > http://www.bblisa.org/mailman/listinfo/bblisa
_______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
