Connectivity
Back to Top

150M/20M bw is good. But site-to-site vpn seems capped at 20M in both directions

SOLVED
Highlighted
kevin_0xdata
New Member

150M/20M bw is good. But site-to-site vpn seems capped at 20M in both directions

 

comcast router is in bridge only mode..firewall and nat disabled.

vpn/firewall device before that, is cisco asa5512x

it can support 200+Mbps vpn perf. I tested two back to back and got 250Mbps.

 

I've had no problem with normal download/upload testing: 150Mbits/sec  download and 20Mbits/download

 

I've recently enabled a site-to-site vpn and can only get around 20Mbits/sec up and down. It oscillates 16M to 24M. I think maybe Comcast is throttling? It's udp traffic.

 

I tried testing the remote client VPN bw. it also seems limited to 20Mbits/sec in both directions.

 

I know this is a deep/complicated subject, but I'm pretty confident I'ved tested things enough to say that I don't think it's my gear or configuration.

 

Has anyone done either site to site vpn, or remote client vpn, with >20Mbits/sec bw in one direction?

 

Does anyone know any details that might led to a capping effect by comcast?

 

I've heard rumors of comcast routers not being able to support UDP bw above a certain limit, or maybe only if NAT'ed. But I've disabled both firewall and NAT in the comcast router, so don't think that would affect me if true.

 

I've only done tcp/ip testing for the 150M download test. I can't test UDP at those levels. If anyone knows a site where i can do a UDP test of 100M to 150M download, that would be useful also

 

Thanks a bunch, 

I know there's an infinite # of things I could have done wrong, but I think there's a comcast issue here.

 

-kevin

Accepted Solution

Re: 150M/20M bw is good. But site-to-site and remote client vpn seems capped at 20M in both directio

I think you are actually seeing normal behavior. If i understand you correctly, you have a site-to-site VPN between 2 ASAs, with each side having a 150/20 bandwidth limit. So think about the flow of traffic; side A sends a stream to side B, side A has a max upload rate of 20mbit, meaning side B will only be able to download from side A at 20mbit. And since both sites have the same upload rate, the same 20mbit limiation will exist in the "vice versa" situation (transfers from side B to A will be capped at 20mbit)

Bandwidth will always be limited by the "slowest link in the chain" so to speak. If you want confirmation of this, research the commandline tool called "iperf", and set up an iperf connection between the 2 sites without any VPN connection. I believe you will see the same speeds.
View solution in context
9 REPLIES
Trusted Forum Contributor

Re: 150M/20M bw is good. But site-to-site and remote client vpn seems capped at 20M in both directio

I think you are actually seeing normal behavior. If i understand you correctly, you have a site-to-site VPN between 2 ASAs, with each side having a 150/20 bandwidth limit. So think about the flow of traffic; side A sends a stream to side B, side A has a max upload rate of 20mbit, meaning side B will only be able to download from side A at 20mbit. And since both sites have the same upload rate, the same 20mbit limiation will exist in the "vice versa" situation (transfers from side B to A will be capped at 20mbit)

Bandwidth will always be limited by the "slowest link in the chain" so to speak. If you want confirmation of this, research the commandline tool called "iperf", and set up an iperf connection between the 2 sites without any VPN connection. I believe you will see the same speeds.
kevin_0xdata
New Member

Re: 150M/20M bw is good. But site-to-site and remote client vpn seems capped at 20M in both directio

I've just done some more testing.

 

I switched to remote client vpn testing with tcp (I think) and I can sustain 90Mbits/sec vpn remote client bandwidth, from the remote site (which has a cisco asa5512x for the firewall vpn)

 

I have comcast here, so it's 150Mbits/sec download

 

When I use speedtest-cli (emulates the browser speedtest.net)..I can see about 80-90Mbits/sec right now

 

So I think there's some busyness on the comcast cable, but it shows that if I plug directly into the comcast router, I can move data to here (download) with vpn ..vpn with tcp at least.

 

I have to try vpn with udp and see if there's a different.

 

-kevin

kevin_0xdata
New Member

Re: 150M/20M bw is good. But site-to-site and remote client vpn seems capped at 20M in both directio

Hi train_wreck

"f i understand you correctly, you have a site-to-site VPN between 2 ASAs, with each side having a 150/20 bandwidth limit"

 

no, I'm complaining about more of a 1% problem Smiley Happy

 

The "other site" is a datacenter. It has 900Mbits/sec speedtest results to the internet. Yes it's a 1Gbps link. Google's 8.8.8.8 pings at just 2ms. So it's great.

 

The site here is comcast link. it has 150/20 cable.

 

I have asa 5512x's at both sites. Set up to either remote vpn client, or site to site vpn client.

 

I've just tested that I can remote vpn to the datacenter, and get 80 to 90 Mbits/sec VPN download to here (download on comcast) ..that's what I expect.

 

The local asa5512 wasn't being used for that test. I plugged directly into the comcast router.

 

I'm thinking it's a site-to-site udp vpn problem with comcast. I don't think using the second vpn here is an issue.

 

Guess I'm looking for someone who's got site to site vpn working with >20Mbit/sec download with comcast.

 

thanks

-kevin

 

Trusted Forum Contributor

Re: 150M/20M bw is good. But site-to-site and remote client vpn seems capped at 20M in both directio

Ah ok, a bit different of a situation then.

 

Have you ever tried setting up a site-to-site between the data center & another Comcast (or any other ISP ) connection, and verified that you can definitely get >20mbps sustained transfer at all?

kevin_0xdata
New Member

Re: 150M/20M bw is good. But site-to-site and remote client vpn seems capped at 20M in both directio

Hi train_wreck,

thanks for helping me brain storm on this

 

"Have you ever tried setting up a site-to-site between the data center & another Comcast (or any other ISP ) connection, and verified that you can definitely get >20mbps sustained transfer at all?"

 

I can get 80 Mbps from the datacenter with vpn, if I use client vpn from here to there ..with "here" having comcast cable

 

I've used iperf for tcp and udp testing, and looks like I'm good for 80Mbps both udp and tcp

 

that's new info for me today.

 

I can only get 20Mbps in both directions when site to site vpn is used.

 

So maybe something more complicated is going on then I first suspected, since I can get client vpn bw thru comcast that's good, and I can get UDP bw that's good.

 

just can't get good bw with site to site vpn.

 

I think I just have to try some more things. I can't (right now) verify client vpn with both asa5512's in the path, because of setup issues. I have to brainstorm some more on what to try.

 

Would think someone out there would have a site-to-site vpn on comcast, where they've got >20Mbits/sec in one direction. ?? anyone out there ?? Smiley Happy

 

-kevin

Trusted Forum Contributor

Re: 150M/20M bw is good. But site-to-site and remote client vpn seems capped at 20M in both directio

I'm not sure; i know that I have several site-to-site IPsec-only VPNs between my personal Comcast business connection (100/20, real-world provisioning around ~115/23) and numerous other equal-banwidth Comcast connections, and I get ~21.5-22mbit both ways on all of them... I use a combination of Linux-based PC routers, Ubiquiti EdgeRouters, Cisco RV042 & RV024Gs, and some other TP-Link VPN routers.

 

Could there possibly be any QoS speed-limiting rules that may be overlooked here?

Trusted Forum Contributor

Re: 150M/20M bw is good. But site-to-site and remote client vpn seems capped at 20M in both directio

 

 

Great input train_wreck but I believe the following 5512 X spec says more than just the 150/20 to 150/20 Comcast Gateways (CGs) limiting the overall VPN implementation here:

 

 

Use this link instead....

 

 

As you can see from the above, the VLANs are rates @ 50 / 100 Mbps along with the AVC NGIPS (Internet Specific processing is speced at 100 Mbps.

 

Now I am not exactly sure as to his exact VPN configuration , however, I have dealt with many Comcast VPN customers that have been able to successfully use the following VPN configurator with using CG containing a staticIP to make absolutely sure that all ALL the correct ports are opened on the CG connected to either a direct VPN server or built-in one.

 

1) If RRAS based VPN server is behind a firewall (i.e. a firewall is placed between Internet and RRAS server), then following ports need to be opened (bidirectional) on this firewall to allow VPN traffic to pass through: -

  • For PPTP:
    • IP Protocol=TCP, TCP Port number=1723   <- Used by PPTP control path
    • IP Protocol=GRE (value 47)   <- Used by PPTP data path
  • For L2TP:
    • IP Protocol Type=UDP, UDP Port Number=500    <- Used by IKEv1 (IPSec control path)
    • IP Protocol Type=UDP, UDP Port Number=4500   <- Used by IKEv1 (IPSec control path)
    • IP Protocol Type=ESP (value 50)   <- Used by IPSec data path
  • For SSTP:
    • IP Protocol=TCP, TCP Port number=443   <- Used by SSTP control and data path
  • For IKEv2:
    • IP Protocol Type=UDP, UDP Port Number=500    <- Used by IKEv2 (IPSec control path)
    • IP Protocol Type=UDP, UDP Port Number=4500   <- Used by IKEv2 (IPSec control path)
    • IP Protocol Type=ESP (value 50)   <- Used by IPSec data path

2) If RRAS server is directly connected to Internet, then you need to protect RRAS server from the Internet side (i.e. only allow access to the services on the public interface that isaccessible from the Internet side). This can be done using RRAS static filters or running Windows Firewall on the public interface (or the interface towards the Internet side). In this scenario following ports need to be opened (bidirectional) on RRAS box to allow VPN traffic to pass through

    • For PPTP:
      • IP Protocol=TCP, TCP Port number=1723  <- Used by PPTP control path
      • IP Protocol=GRE (value 47)  <- Used by PPTP data path
    • For L2TP:
      • IP Protocol Type=UDP, UDP Port Number=500   <- Used by IKEv1 (IPSec control path)
      • IP Protocol Type=UDP, UDP Port Number=4500 <- Used by IKEv1 (IPSec control path)
      • IP Protocol Type=UDP, UDP Port Number=1701  <- Used by L2TP control/data path
      • IP Protocol Type=50  <- Used by data path (ESP)
  • For SSTP:
  • IP Protocol=TCP, TCP Port number=443   <- Used by SSTP control and data path
  • For IKEv2:
  • IP Protocol Type=UDP, UDP Port Number=500   <- Used by IKEv2 (IPSec control path)
  • IP Protocol Type=UDP, UDP Port Number=4500 <- Used by IKEv2 (IPSec control path)
  • IP Protocol Type=UDP, UDP Port Number=1701  <- Used by L2TP control/data path
  • IP Protocol Type=50 <- Used by data path (ESP)

Note: Please DO NOT configure RRAS static filters if you are running on the same server RRAS based NAT router functionality. This is because RRAS static filters are stateless and NAT translation requires a stateful edge firewall like ISA firewall.

Do not forget: If you enable Windows firewall or RRAS static filters on the public interface and only enable VPN traffic to pass-through, then all the other traffic may be dropped. For example, if the same server is running as a mail server facing internet or a DNS server or a reverse web proxy server, then you need to enable the ports used by those services explicitly.

"

 

Hope this helps everyone out.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

kevin_0xdata
New Member

Re: 150M/20M bw is good. But site-to-site and remote client vpn seems capped at 20M in both directio

Hi train wreck

 

sorry for the delay in responding

 

You said

"I'm not sure; i know that I have several site-to-site IPsec-only VPNs between my personal Comcast business connection (100/20, real-world provisioning around ~115/23) and numerous other equal-banwidth Comcast connections, and I get ~21.5-22mbit both ways on all of them"

 

That's exactly what I see..16-20Mbits/sec in both directions. You don't expect to see 100Mbits in one direction?

 

I just setup a sftp server to make sure that I can get the asymmetric 150Mbits/sec bw in one direction. I can.

 

So I can do 150 down/20 up, between the two sites with ftp ..but not thru the site-to-site vpn.

The annoying thing is that I can do 100/20 between the two sites with a client mode vpn also 

 

There must be something I don't understand about site to site vpn behaviors.

 

-kevin

 

 

kevin_0xdata
New Member

Re: 150M/20M bw is good. But site-to-site and remote client vpn seems capped at 20M in both directio

 

VBSSP-RICH


Hi, thanks.

 

I'm using IKEV1

 

I have the nat and firewall disabled (using the web gui)  in the comcast router (which is the cisco dpc3939, provided by comcast)

 

The asa5512x uses UDP port 500 to negotiate the tunnel

 

here's some details from the asa5512x on the tunnel after it's created

 

 IKEv1 AES-256Tunnel ID: 311.1 Authentication Mode: preSharedKeys UDP Source Port 500 UDP Destination Port 500 Authentication Mode: preSharedKeys UDP Source Port 500 UDP Destination Port 500 IKE Negotiation Mode: Main Hashing: SHA1 Authentication Mode: preSharedKeys UDP Source Port 500 UDP Destination Port 500 IKE Negotiation Mode: Main Hashing: SHA1 Diffie-Hellman Group: 2 Rekey Time Interval: 86400 Seconds Rekey Left(T): 86288 Seconds 

 

 

 IPsec172.16.0.0/255.255.0.0/0/0 172.17.0.0/255.255.0.0/0/0AES-128Tunnel ID: 311.2 Hashing: SHA1 Encapsulation: Tunnel Rekey Time Interval: 28800 Seconds Rekey Left(T): 28688 Seconds Rekey Data Interval: 4608000 K-Bytes Rekey Left(D): 4606622 K-Bytes Idle Time Out: 30 Minutes Idle TO Left: 30 Minutes Packets Tx: 6566 Packets Rx: 23101411410 159663

 

 

IPsec SA Details


Crypto map tag: outside_map, seq num: 1, local addr: 50.255.33.33

access-list outside_cryptomap extended permit ip 172.16.0.0 255.255.0.0 172.17.0.0 255.255.0.0
local ident (addr/mask/prot/port): (172.16.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (172.17.0.0/255.255.0.0/0/0)
current_peer: 162.249.37.234


#pkts encaps: 7490, #pkts encrypt: 7490, #pkts digest: 7490
#pkts decaps: 2978, #pkts decrypt: 2978, #pkts verify: 2978
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 7490, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#pkts no sa (send): 0, #pkts invalid sa (rcv): 0
#pkts encaps failed (send): 0, #pkts decaps failed (rcv): 0
#pkts invalid prot (rcv): 0, #pkts verify failed: 0
#pkts invalid identity (rcv): 0, #pkts invalid len (rcv): 0
#pkts invalid pad (rcv): 0,
#pkts invalid ip version (rcv): 0,
#pkts replay rollover (send): 0, #pkts replay rollover (rcv): 0
#pkts replay failed (rcv): 0
#pkts min mtu frag failed (send): 0, #pkts bad frag offset (rcv): 0
#pkts internal err (send): 0, #pkts internal err (rcv): 0

local crypto endpt.: 50.255.33.33/0, remote crypto endpt.: 162.249.37.234/0
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: clear-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: 369FD8BE
current inbound spi : DFE3B7FE

inbound esp sas:
spi: 0xDFE3B7FE (3756242942)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 1273856, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (3914805/28648)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0x369FD8BE (916445374)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 1273856, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (3913406/28648)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001

 

 

-kevin

 

Discussion stats
  • 9 replies
  • 2475 views
  • 0 kudos
  • 3 in conversation