Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 4 subscribers
  • Views 44771 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cisco AnyConnect VERY slow (Laptop to work)

randfee
Hi,

I'm unable to figure this one out myself:
I run my UTM at home, behind a cable modem (bridged). So far I've never had any performance issues. Not until my employer set up a VPN server at work to connect to company network using my work-laptop (only via Laptop, not via UTM!!!). It uses Cisco AnyConnect. So the laptop (win7) is situated in my LAN (behind the UTM) and I want to connect to the company net.

Accessing my employers servers via ssh/scp utilizes the maximum bandwidth of my connection (50Mbit/s down, 5 up) (Laptop behind UTM --> outside server). Accessing the same server using the AnyConnect VPN (Laptop behind UTM --> outside server) gives me around 200kbit/s each way. 
When I hook up the laptop the the cable modem I get the full bandwidth maximum bandwidth!
I fiddled with the MTU on the Laptop and UTM since I saw some fragmentation messages on the UTM but seeing that the tunnel works flawlessly when circumventing the UTM I figured, I am kinda lost (IMCP was always activated in the UTM).

I ran out of ideas. I tried turning off any security measure. The routing seems fine. I'd really appreciate any help.

kind regards


This thread was automatically locked due to age.
  • 0
    Hi, have you checked the logs (firewall, IPS, app control)?

    Barry
  • 0
    IPS & App Control can be ruled out, because I already turned them off.
    The firewall log shows nothing of significance.

    here's a tcpdump of everything on the WAN interface going to the VPN Server during/after login, maybe this gives a clue. I obviously replaced all privacy relevant information by upper-case dummy strings.
    UTM_Name:/root # tcpdump -i eth1 | grep COMPANY_HOST
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
    23:40:17.907993 IP UTM_Name.40272 > PROVIDER: 6551+ [1au] A? COMPANY_HOST3. (42)
    23:40:18.034626 IP UTM_Name.58656 > COMPANY_HOST.isakmp: isakmp: parent_sa ikev2_init
    23:40:18.047781 IP PROVIDER > UTM_Name.46615: 1458 4/0/1 PTR marauders-gate.COMPANY4.de., PTR COMPANY_HOST., PTR COMPANY_HOST2., PTR COMPANY_HOST3. (150)
    23:40:18.052408 IP COMPANY_HOST.isakmp > UTM_Name.58656: isakmp: parent_sa ikev2_init[R]
    23:40:18.062561 IP UTM_Name.58656 > COMPANY_HOST.isakmp: isakmp: parent_sa ikev2_init
    23:40:18.081234 IP COMPANY_HOST.isakmp > UTM_Name.58656: isakmp: parent_sa ikev2_init[R]
    23:40:18.098543 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: NONESP-encap: isakmp: child_sa  ikev2_auth
    23:40:18.098605 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: NONESP-encap: isakmp: child_sa  ikev2_auth
    23:40:18.126793 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:18.127703 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:18.127708 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:18.127713 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:18.127718 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:18.127722 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:18.127726 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:18.127730 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:18.127734 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:18.127738 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:18.127742 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:18.127746 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:18.139724 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: NONESP-encap: isakmp: child_sa  ikev2_auth
    23:40:18.156759 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:18.156763 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:28.574585 IP UTM_Name.45666 > sg.COMPANY4.de.ssh: Flags [P.], seq 3575313351:3575313383, ack 1543887205, win 661, options [nop,nop,TS val 2341711216 ecr 1661695714], length 32
    23:40:35.359372 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: NONESP-encap: isakmp: child_sa  ikev2_auth
    23:40:37.358685 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: NONESP-encap: isakmp: child_sa  ikev2_auth
    23:40:37.418981 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.420077 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.420084 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.420088 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.420092 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.420096 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.420100 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.420105 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.420109 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.420112 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.422964 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: NONESP-encap: isakmp: child_sa  ikev2_auth
    23:40:37.453719 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.454346 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: NONESP-encap: isakmp: child_sa  ikev2_auth
    23:40:37.473066 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.473072 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.473076 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.473364 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.473368 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.473371 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.473658 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.473663 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.474159 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:37.474163 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
    23:40:39.254838 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x1), length 84
    23:40:39.454295 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x2), length 84
    23:40:41.251170 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x3), length 84
    23:40:41.450818 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x4), length 84
    23:40:43.112802 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x1), length 84
    23:40:43.117982 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x2), length 84
    23:40:43.118364 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x3), length 100
    23:40:43.221352 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x4), length 100
    23:40:43.221414 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x5), length 228
    23:40:43.244046 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x5), length 260
    23:40:43.264188 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x6), length 84
    23:40:43.266276 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x6), length 228
    23:40:43.266329 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x7), length 228
    23:40:43.266372 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x8), length 228
    23:40:43.266412 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x9), length 228
    23:40:43.283913 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x7), length 260
    23:40:43.284246 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x8), length 260
    23:40:43.284250 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x9), length 260
    23:40:43.284254 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0xa), length 260
    23:40:43.331855 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0xa), length 100
    23:40:43.348432 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0xb), length 116
    23:40:43.350273 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0xb), length 100
    23:40:43.367229 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0xc), length 100
    23:40:43.367932 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0xc), length 84
    23:40:43.367984 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0xd), length 244
    23:40:43.384550 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0xd), length 340
    23:40:43.385379 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0xe), length 196
    23:40:43.402681 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0xe), length 340
    23:40:43.404087 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0xf), length 1444
    23:40:43.404160 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x10), length 1444
    23:40:43.404239 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x11), length 292
    23:40:43.408411 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x12), length 84
    23:40:43.421767 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0xf), length 84
    23:40:43.422778 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x10), length 340
    23:40:43.423615 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x13), length 212
    23:40:43.440733 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x11), length 164
    23:40:43.441511 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x14), length 212
    23:40:43.458648 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x12), length 356
    23:40:43.464033 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x13), length 84
    23:40:43.471368 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x15), length 100
    23:40:43.472703 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x16), length 148
    23:40:43.472770 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x17), length 148
    23:40:43.486529 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x14), length 100
    23:40:43.487248 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x18), length 84
    23:40:43.487314 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x19), length 436
    23:40:43.494097 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x15), length 292
    23:40:43.494102 IP COMPANY_HOST.ipsec-msft > UTM_Name.58657: UDP-encap: ESP(spi=0x5869e3cb,seq=0x16), length 292
    23:40:43.495249 IP UTM_Name.58657 > COMPANY_HOST.ipsec-msft: UDP-encap: ESP(spi=0xaaa8e59b,seq=0x1a), length 100
    [/CODE]
  • +1
    When you disabled IPS, did you also turn off Anti-Portscan and Anti-Flooding?  Although in that same section, they are controlled separately.  Just another possibility.
  • 0
    here some interesting statistics while I try to copy a large file when the VPN connection is up. It looks like heavy fragmentation to me... but I have no idea where it would be coming from. 



    length 	# of occurences

    84	2323

    100	868

    116	974

    132	16

    148	19

    164	35

    180	57

    196	130

    212	61

    228	6

    244	14

    260	25

    276	12

    292	17

    308	96

    324	95

    340	53

    356	53

    372	34

    388	42

    404	44

    420	53

    436	23

    452	22

    468	15

    484	20

    500	8

    516	24

    532	37

    548	48

    564	46

    580	44

    596	39

    612	22

    628	18

    644	24

    660	23

    676	31

    692	27

    708	42

    724	22

    740	22

    756	20

    772	27

    788	37

    804	20

    820	32

    836	16

    852	16

    868	16

    884	10

    900	24

    916	19

    932	28

    948	17

    964	27

    980	22

    996	31

    1012	27

    1028	24

    1044	32

    1060	17

    1076	14

    1092	22

    1108	10

    1124	17

    1140	15

    1156	19

    1172	18

    1188	14

    1204	17

    1220	20

    1236	21

    1252	21

    1268	27

    1284	21

    1300	23

    1316	18

    1332	13

    1348	12

    1364	14

    1380	10

    1396	24

    1412	10

    1428	16

    1444	5244
  • 0
    As Scott and Barry have suggested, until you check the IPS log to confirm that there's no evidence of Anti-Flooding activity, we're all hesitant to suggest a next step.  It's not unusual for an IPsec VPN to appear to be malicious UDP flooding.

    Cheers - Bob
  • 0
    Now why didn't I think of it. I guess I got sloppy with "switching" (literally the switches on the UI) all things off. Seing fragmentation then threw me off completely.
    thanks guys.... you were spot on. UDP flood protection killed the throughput. I set exclusion rules for laptop and external VPN Host and voila... worked of course. 

    Thanks for the help!

    However... I'm still clueless about the fragmentation which obviously is suboptimal. The company VPN Gate seems to ignore the fragmentation messages but manually setting MTUs on the client and/or the UTM's interfaces didn't seem to do a thing. When client's MTU is set for 1500, fragmentation occurs to a length of 1444 as seen above. When client's MTU is set to 1200, fragmentation still occurs. Maybe someone has an insight on this too?

    Again, cheers for the prompt help!
    Arnold
  • 0
    Glad you got it solved!

    An informal rule here is "one issue per thread," so please start another thread with the new question.

    Cheers - Bob
  • 0 in reply to Scott_Klassen

    I had this exact problem and disabling these three services fixed my problem:

    1. TCP SYN Flood Protection
    2. UDP Flood Protection
    3. Portscan detection

    Thanks so much!

  • 0 in reply to crum66

    Thanks for providing the solution!  This is not the approach I would recommend though - see #1 in Rulz.  Look at the Intrusion Prevention log when those were enabled.  That should show you what exceptions you need to be able to re-enable those protections.

    Cheers - Bob