Home   Help Search Login Register  
You are not logged in. To get the full experience of these forums, we recommend you log in or register
Plusnet Usergroup » All Users - The Open Forum » Plusnet Network and Technical Issues » Residential Broadband: Excessive latency on VPN IPSec traffic since last Thurs?
Pages: 1 [2] 3
  Print  
Author Topic: Residential Broadband: Excessive latency on VPN IPSec traffic since last Thurs?  (Read 1803 times)
Shaggy

Posts: 39

« Reply #15 on: July 24, 2009, 08:41:11 am »

Ticket: 29438051 Actioned Raised: 2009-07-21 10:39:25 By: You Via: Portal 2009-07-24
09:11:58
Ticket: 29438051

[Agent's name removed]
IE - Generic Dear Mr Cording,
Unfortunately the packet capture you have provided doesn't contain much data, what I can advise is that TCP port 90 is not prioritized on our network as it is not a known VPN or any other application default port for that matter.

Is it possible for this port to be changed as currently traffic over this port will only be given silver QOS.

Kind regards,

[Agent's name removed]


Hi [Agent's name removed]
         Thank you for the update.

  I have been using IPSec over TCP Port 90 ever since I joined Plusnet as a user on 05/05/2004, in those 5 years there has only ever been one other issue with VPN Traffic over TCP Port 90 which was resolved.

 Since around the 16th of July I have been experiencing high latency again so something has changed on how you handle IPSec TCP traffic, is it something to do with this?

http://usertools.plus.net/status/archive/1247600472.htm

 If its the case that a new policy has been implemented which has migrated IPSec over TCP from Gold to Silver CoS then I need to know of this policy change as although I am very happy with Plusnet I cannot continue to use your service with VPN latency in excess of 2000ms.

 However if the problems I am experiencing are a result of an incorrect Policy as it has worked fine for 5 years then I would appreciate if we could get to the root cause of the issue to try and resolve.

 I assume your traffic shaping policy can differentiate between IPSec and other protocols/applications using Port 90.

 In terms of using another Port this is set by Sun Microsystems ITOPS as a Global Standard I'm afraid I hold little sway in asking Sun to change its Global VPN Policy for me.

As a work around I am using IPSec over UDP, my concern is how long is it until that is affected by any CoS Policy changes?

 Many thanks

Moderator's note by David (spraxyt): Agent's name removed.
« Last Edit: July 24, 2009, 09:57:52 am by spraxyt »
Shaggy

Posts: 39

« Reply #16 on: July 28, 2009, 01:31:13 pm »

I've been asked for another wireshark trace.. unfortunately I cant find my old hub therefore I'm going to have to use my laptop for the trace.

  northbritish mentions a way of setting up the lappy to do the trace and act as I guess a defualt gateway I'm not 100% on how to do that could someone give me an explination on how to do that?

 Thanks Shaggy
xpcomputers
Usergroup Member

Posts: 1068

« Reply #17 on: July 28, 2009, 01:52:30 pm »

Shaggy,

This guy is trying to do the reverse of you on his slideshow (see the data inside the encrypted tunnel, rather than the tunnel itself), but using his idea of pinging, you might find that in your connection list, you can see on your computer both the unencrypted state & encrypted states by picking a different connection adapter to monitor using wireshark. Might or might not help you.

I think the idea of using the laptop is to run Internet Connection Sharing (ICS) OR to bridge together the two adapters (in the network connections list). Then the laptop connects wirelessly to router as normal. The desktop plugs into the laptop ethernet port and because of the sharing or bridge established, you can see the tunnel as it passes through the laptop on it's way to the net. Do a net search for bridging or ICS and you should hit jackpot. If you are still stuck, come back.

Mike

xpcomputers
Usergroup Member

Posts: 1068

« Reply #18 on: July 28, 2009, 01:58:13 pm »

I think the bridging might be easier & better than ICS, but that is purely hypothetical understanding... I have never tried any of the techniques listed!
Shaggy

Posts: 39

« Reply #19 on: July 28, 2009, 04:15:54 pm »

Hi All
      Thanks to xpcomputers for the assistance but I finally found my old hub in the loft  angel

 So here is the results of the testing Im going to past the ticket below if you are interested in reading with the agents names removed this time sorry  cry but the bottom line is:

IPSec over TCP Port 90 results in DSCP 0x40 or Silver
IPSec over UDP results in DSCP 0x80 or Gold

Quote
Since around July 16th my IPSec Traffic over TCP Port 90 has been experiencing very high latency I assume that his is due to either:

The VPN traffic being remarked from Gold to Silver.

Or if the VPN traffic has not changed class the Silver Class is now experiencing greater traffic as a result of the change last July the 16th?






Hi
I managed to find my old Hub and placed this between my DSL router and the Desk Top PC running the VPN client, I then connected my Laptop running Wireshark to the Hub to capture the encrypted VPN traffic between the desk top and the DSL Router as my previous trace didn't show this traffic.

My test network as follows:

PC<-VPN->HUB<-VPN->DSL Router<-DSL->(Internet)->Cisco VPN GW
V
(Laptop running Wireshark)


Desk Top PC
192.168.2.101
WinXP
VPN Client Cisco Systems 4.0.3(A)
IPSec over TCP Port 90

Sun Microsystems
Cisco VPN 3000 Concentrator
192.18.1.12

The RTT is normally >1000ms although it does very, during this test the average was 407ms with the max being 1226ms.

Note using VPN over UDP RTT is never >200ms!

The DSCP value being tagged to packets from 192.18.1.12 is 0x40 or Silver / Unclassified traffic

I will provide a wireshark trace of using IPSec over UDP next.
Your comment    4:45pm, Tuesday 28th July 2009

Ping from IPSec over TCP Port 90 Trace above:

C:\Documents and Settings\Greg>ping google.com -t

Pinging google.com [74.125.127.100] with 32 bytes of data:

Reply from 74.125.127.100: bytes=32 time=205ms TTL=47
Reply from 74.125.127.100: bytes=32 time=211ms TTL=47
Reply from 74.125.127.100: bytes=32 time=221ms TTL=47
Reply from 74.125.127.100: bytes=32 time=240ms TTL=47
Reply from 74.125.127.100: bytes=32 time=393ms TTL=47
Reply from 74.125.127.100: bytes=32 time=207ms TTL=47
Reply from 74.125.127.100: bytes=32 time=261ms TTL=47
Reply from 74.125.127.100: bytes=32 time=202ms TTL=47
Reply from 74.125.127.100: bytes=32 time=239ms TTL=47
Reply from 74.125.127.100: bytes=32 time=199ms TTL=47
Reply from 74.125.127.100: bytes=32 time=199ms TTL=47
Reply from 74.125.127.100: bytes=32 time=205ms TTL=47
Reply from 74.125.127.100: bytes=32 time=210ms TTL=47
Reply from 74.125.127.100: bytes=32 time=236ms TTL=47
Reply from 74.125.127.100: bytes=32 time=203ms TTL=47
Reply from 74.125.127.100: bytes=32 time=201ms TTL=47
Reply from 74.125.127.100: bytes=32 time=204ms TTL=47
Reply from 74.125.127.100: bytes=32 time=201ms TTL=47
Reply from 74.125.127.100: bytes=32 time=205ms TTL=47
Reply from 74.125.127.100: bytes=32 time=204ms TTL=47
Reply from 74.125.127.100: bytes=32 time=206ms TTL=47
Reply from 74.125.127.100: bytes=32 time=202ms TTL=47
Reply from 74.125.127.100: bytes=32 time=214ms TTL=47
Reply from 74.125.127.100: bytes=32 time=215ms TTL=47
Reply from 74.125.127.100: bytes=32 time=396ms TTL=47
Reply from 74.125.127.100: bytes=32 time=375ms TTL=47
Reply from 74.125.127.100: bytes=32 time=209ms TTL=47
Reply from 74.125.127.100: bytes=32 time=205ms TTL=47
Reply from 74.125.127.100: bytes=32 time=203ms TTL=47
Reply from 74.125.127.100: bytes=32 time=199ms TTL=47
Reply from 74.125.127.100: bytes=32 time=200ms TTL=47
Reply from 74.125.127.100: bytes=32 time=202ms TTL=47
Reply from 74.125.127.100: bytes=32 time=205ms TTL=47
Reply from 74.125.127.100: bytes=32 time=202ms TTL=47
Reply from 74.125.127.100: bytes=32 time=202ms TTL=47
Reply from 74.125.127.100: bytes=32 time=206ms TTL=47
Reply from 74.125.127.100: bytes=32 time=202ms TTL=47
Reply from 74.125.127.100: bytes=32 time=206ms TTL=47
Reply from 74.125.127.100: bytes=32 time=200ms TTL=47
Reply from 74.125.127.100: bytes=32 time=200ms TTL=47
Reply from 74.125.127.100: bytes=32 time=265ms TTL=47
Reply from 74.125.127.100: bytes=32 time=293ms TTL=47
Reply from 74.125.127.100: bytes=32 time=221ms TTL=47
Reply from 74.125.127.100: bytes=32 time=217ms TTL=47
Reply from 74.125.127.100: bytes=32 time=218ms TTL=47
Reply from 74.125.127.100: bytes=32 time=210ms TTL=47
Reply from 74.125.127.100: bytes=32 time=206ms TTL=47
Reply from 74.125.127.100: bytes=32 time=303ms TTL=47
Reply from 74.125.127.100: bytes=32 time=349ms TTL=47
Reply from 74.125.127.100: bytes=32 time=202ms TTL=47
Reply from 74.125.127.100: bytes=32 time=338ms TTL=47
Reply from 74.125.127.100: bytes=32 time=207ms TTL=47
Reply from 74.125.127.100: bytes=32 time=366ms TTL=47
Reply from 74.125.127.100: bytes=32 time=208ms TTL=47
Reply from 74.125.127.100: bytes=32 time=241ms TTL=47
Reply from 74.125.127.100: bytes=32 time=245ms TTL=47
Reply from 74.125.127.100: bytes=32 time=366ms TTL=47
Reply from 74.125.127.100: bytes=32 time=403ms TTL=47
Reply from 74.125.127.100: bytes=32 time=535ms TTL=47
Reply from 74.125.127.100: bytes=32 time=903ms TTL=47
Reply from 74.125.127.100: bytes=32 time=1226ms TTL=47
Reply from 74.125.127.100: bytes=32 time=1216ms TTL=47
Reply from 74.125.127.100: bytes=32 time=897ms TTL=47
Reply from 74.125.127.100: bytes=32 time=504ms TTL=47
Reply from 74.125.127.100: bytes=32 time=460ms TTL=47
Reply from 74.125.127.100: bytes=32 time=363ms TTL=47
Reply from 74.125.127.100: bytes=32 time=760ms TTL=47
Reply from 74.125.127.100: bytes=32 time=767ms TTL=47
Reply from 74.125.127.100: bytes=32 time=265ms TTL=47
Reply from 74.125.127.100: bytes=32 time=243ms TTL=47
Reply from 74.125.127.100: bytes=32 time=215ms TTL=47
Reply from 74.125.127.100: bytes=32 time=292ms TTL=47
Reply from 74.125.127.100: bytes=32 time=452ms TTL=47
Reply from 74.125.127.100: bytes=32 time=643ms TTL=47
Reply from 74.125.127.100: bytes=32 time=1124ms TTL=47
Reply from 74.125.127.100: bytes=32 time=765ms TTL=47
Reply from 74.125.127.100: bytes=32 time=458ms TTL=47
Reply from 74.125.127.100: bytes=32 time=274ms TTL=47
Reply from 74.125.127.100: bytes=32 time=201ms TTL=47
Reply from 74.125.127.100: bytes=32 time=204ms TTL=47
Reply from 74.125.127.100: bytes=32 time=375ms TTL=47
Reply from 74.125.127.100: bytes=32 time=523ms TTL=47
Reply from 74.125.127.100: bytes=32 time=243ms TTL=47
Reply from 74.125.127.100: bytes=32 time=208ms TTL=47
Reply from 74.125.127.100: bytes=32 time=209ms TTL=47
Reply from 74.125.127.100: bytes=32 time=226ms TTL=47
Reply from 74.125.127.100: bytes=32 time=211ms TTL=47
Reply from 74.125.127.100: bytes=32 time=207ms TTL=47
Reply from 74.125.127.100: bytes=32 time=220ms TTL=47
Reply from 74.125.127.100: bytes=32 time=439ms TTL=47
Reply from 74.125.127.100: bytes=32 time=635ms TTL=47
Reply from 74.125.127.100: bytes=32 time=820ms TTL=47
Reply from 74.125.127.100: bytes=32 time=961ms TTL=47
Reply from 74.125.127.100: bytes=32 time=1040ms TTL=47
Reply from 74.125.127.100: bytes=32 time=1042ms TTL=47
Reply from 74.125.127.100: bytes=32 time=1055ms TTL=47
Reply from 74.125.127.100: bytes=32 time=764ms TTL=47
Reply from 74.125.127.100: bytes=32 time=689ms TTL=47
Reply from 74.125.127.100: bytes=32 time=751ms TTL=47
Reply from 74.125.127.100: bytes=32 time=564ms TTL=47
Reply from 74.125.127.100: bytes=32 time=354ms TTL=47
Reply from 74.125.127.100: bytes=32 time=215ms TTL=47
Reply from 74.125.127.100: bytes=32 time=257ms TTL=47
Reply from 74.125.127.100: bytes=32 time=247ms TTL=47
Reply from 74.125.127.100: bytes=32 time=378ms TTL=47
Reply from 74.125.127.100: bytes=32 time=331ms TTL=47
Reply from 74.125.127.100: bytes=32 time=509ms TTL=47
Reply from 74.125.127.100: bytes=32 time=1035ms TTL=47
Reply from 74.125.127.100: bytes=32 time=665ms TTL=47
Reply from 74.125.127.100: bytes=32 time=466ms TTL=47
Reply from 74.125.127.100: bytes=32 time=838ms TTL=47
Reply from 74.125.127.100: bytes=32 time=902ms TTL=47
Reply from 74.125.127.100: bytes=32 time=996ms TTL=47
Reply from 74.125.127.100: bytes=32 time=900ms TTL=47
Request timed out.
Reply from 74.125.127.100: bytes=32 time=709ms TTL=47
Reply from 74.125.127.100: bytes=32 time=792ms TTL=47
Reply from 74.125.127.100: bytes=32 time=575ms TTL=47
Reply from 74.125.127.100: bytes=32 time=240ms TTL=47
Reply from 74.125.127.100: bytes=32 time=227ms TTL=47
Reply from 74.125.127.100: bytes=32 time=477ms TTL=47
Reply from 74.125.127.100: bytes=32 time=478ms TTL=47
Reply from 74.125.127.100: bytes=32 time=366ms TTL=47
Reply from 74.125.127.100: bytes=32 time=576ms TTL=47
Reply from 74.125.127.100: bytes=32 time=987ms TTL=47
Reply from 74.125.127.100: bytes=32 time=873ms TTL=47
Reply from 74.125.127.100: bytes=32 time=909ms TTL=47
Reply from 74.125.127.100: bytes=32 time=447ms TTL=47
Reply from 74.125.127.100: bytes=32 time=554ms TTL=47
Reply from 74.125.127.100: bytes=32 time=659ms TTL=47
Reply from 74.125.127.100: bytes=32 time=680ms TTL=47
Reply from 74.125.127.100: bytes=32 time=748ms TTL=47
Reply from 74.125.127.100: bytes=32 time=851ms TTL=47
Reply from 74.125.127.100: bytes=32 time=997ms TTL=47
Reply from 74.125.127.100: bytes=32 time=852ms TTL=47
Reply from 74.125.127.100: bytes=32 time=524ms TTL=47
Reply from 74.125.127.100: bytes=32 time=655ms TTL=47
Reply from 74.125.127.100: bytes=32 time=372ms TTL=47
Reply from 74.125.127.100: bytes=32 time=367ms TTL=47
Reply from 74.125.127.100: bytes=32 time=296ms TTL=47
Reply from 74.125.127.100: bytes=32 time=243ms TTL=47
Reply from 74.125.127.100: bytes=32 time=209ms TTL=47
Reply from 74.125.127.100: bytes=32 time=730ms TTL=47
Reply from 74.125.127.100: bytes=32 time=301ms TTL=47
Reply from 74.125.127.100: bytes=32 time=214ms TTL=47
Reply from 74.125.127.100: bytes=32 time=201ms TTL=47
Reply from 74.125.127.100: bytes=32 time=206ms TTL=47
Reply from 74.125.127.100: bytes=32 time=214ms TTL=47
Reply from 74.125.127.100: bytes=32 time=206ms TTL=47
Reply from 74.125.127.100: bytes=32 time=229ms TTL=47
Reply from 74.125.127.100: bytes=32 time=202ms TTL=47
Reply from 74.125.127.100: bytes=32 time=226ms TTL=47
Reply from 74.125.127.100: bytes=32 time=202ms TTL=47
Reply from 74.125.127.100: bytes=32 time=201ms TTL=47
Reply from 74.125.127.100: bytes=32 time=212ms TTL=47
Reply from 74.125.127.100: bytes=32 time=200ms TTL=47
Reply from 74.125.127.100: bytes=32 time=207ms TTL=47
Reply from 74.125.127.100: bytes=32 time=213ms TTL=47
Reply from 74.125.127.100: bytes=32 time=212ms TTL=47
Reply from 74.125.127.100: bytes=32 time=402ms TTL=47
Reply from 74.125.127.100: bytes=32 time=227ms TTL=47
Reply from 74.125.127.100: bytes=32 time=206ms TTL=47
Reply from 74.125.127.100: bytes=32 time=225ms TTL=47
Reply from 74.125.127.100: bytes=32 time=324ms TTL=47
Reply from 74.125.127.100: bytes=32 time=391ms TTL=47
Reply from 74.125.127.100: bytes=32 time=210ms TTL=47
Reply from 74.125.127.100: bytes=32 time=202ms TTL=47
Reply from 74.125.127.100: bytes=32 time=239ms TTL=47

Ping statistics for 74.125.127.100:
Packets: Sent = 168, Received = 167, Lost = 1 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 199ms, Maximum = 1226ms, Average = 407ms

Your comment    5:00pm, Tuesday 28th July 2009

Uploaded file attachment.

Name: vpn_over_udp_source_192_168_2_101_dest_192_18_1_12_latency_max_209ms.pcap

Type: application/octet-stream

Download Attachment
Your comment    5:00pm, Tuesday 28th July 2009

Ok using the same network I have reconfigured the VPN Client on the Desk Top to use IPSec over UDP.

In the attached Wireshark trace you can now see that the DSCP value being tagged to the Packets is now 0x80 or Gold!

Therefore using IPSec over TCP port 90 DSCP is Silver and using IPSec over UDP DSCP is Gold!

Since around July 16th my IPSec Traffic over TCP Port 90 has been experiencing very high latency I assume that his is due to either:

The VPN traffic being remarked from Gold to Silver.
Or if the VPN traffic has not changed class the Silver Class is now experiencing greater traffic as a result of the change last July the 16th?

Below is the Ping I ran from the Desk Top PC running the VPN client, you can see a marked improvement.

Look forward to your thoughts..


C:\Documents and Settings\Greg>ping google.com -t

Pinging google.com [74.125.127.100] with 32 bytes of data:

Reply from 74.125.127.100: bytes=32 time=205ms TTL=46
Reply from 74.125.127.100: bytes=32 time=205ms TTL=46
Reply from 74.125.127.100: bytes=32 time=199ms TTL=46
Reply from 74.125.127.100: bytes=32 time=204ms TTL=46
Reply from 74.125.127.100: bytes=32 time=200ms TTL=46
Reply from 74.125.127.100: bytes=32 time=202ms TTL=46
Reply from 74.125.127.100: bytes=32 time=201ms TTL=46
Reply from 74.125.127.100: bytes=32 time=206ms TTL=46
Reply from 74.125.127.100: bytes=32 time=199ms TTL=46
Reply from 74.125.127.100: bytes=32 time=206ms TTL=46
Reply from 74.125.127.100: bytes=32 time=198ms TTL=46
Reply from 74.125.127.100: bytes=32 time=203ms TTL=46
Reply from 74.125.127.100: bytes=32 time=198ms TTL=46
Reply from 74.125.127.100: bytes=32 time=198ms TTL=46
Reply from 74.125.127.100: bytes=32 time=205ms TTL=46
Reply from 74.125.127.100: bytes=32 time=201ms TTL=46
Reply from 74.125.127.100: bytes=32 time=205ms TTL=46
Reply from 74.125.127.100: bytes=32 time=198ms TTL=46
Reply from 74.125.127.100: bytes=32 time=203ms TTL=46
Reply from 74.125.127.100: bytes=32 time=200ms TTL=46
Reply from 74.125.127.100: bytes=32 time=197ms TTL=46
Reply from 74.125.127.100: bytes=32 time=196ms TTL=46
Reply from 74.125.127.100: bytes=32 time=197ms TTL=46
Reply from 74.125.127.100: bytes=32 time=201ms TTL=46
Reply from 74.125.127.100: bytes=32 time=204ms TTL=46
Reply from 74.125.127.100: bytes=32 time=198ms TTL=46
Reply from 74.125.127.100: bytes=32 time=203ms TTL=46
Reply from 74.125.127.100: bytes=32 time=198ms TTL=46
Reply from 74.125.127.100: bytes=32 time=202ms TTL=46
Reply from 74.125.127.100: bytes=32 time=199ms TTL=46
Reply from 74.125.127.100: bytes=32 time=198ms TTL=46
Reply from 74.125.127.100: bytes=32 time=199ms TTL=46
Reply from 74.125.127.100: bytes=32 time=202ms TTL=46
Reply from 74.125.127.100: bytes=32 time=202ms TTL=46
Reply from 74.125.127.100: bytes=32 time=200ms TTL=46
Reply from 74.125.127.100: bytes=32 time=205ms TTL=46
Reply from 74.125.127.100: bytes=32 time=201ms TTL=46
Reply from 74.125.127.100: bytes=32 time=202ms TTL=46
Reply from 74.125.127.100: bytes=32 time=201ms TTL=46
Reply from 74.125.127.100: bytes=32 time=204ms TTL=46
Reply from 74.125.127.100: bytes=32 time=200ms TTL=46
Reply from 74.125.127.100: bytes=32 time=207ms TTL=46
Reply from 74.125.127.100: bytes=32 time=202ms TTL=46
Reply from 74.125.127.100: bytes=32 time=203ms TTL=46
Reply from 74.125.127.100: bytes=32 time=201ms TTL=46
Reply from 74.125.127.100: bytes=32 time=199ms TTL=46
Reply from 74.125.127.100: bytes=32 time=202ms TTL=46
Reply from 74.125.127.100: bytes=32 time=201ms TTL=46
Reply from 74.125.127.100: bytes=32 time=209ms TTL=46
Reply from 74.125.127.100: bytes=32 time=198ms TTL=46
Reply from 74.125.127.100: bytes=32 time=201ms TTL=46
Reply from 74.125.127.100: bytes=32 time=200ms TTL=46
Reply from 74.125.127.100: bytes=32 time=200ms TTL=46
Reply from 74.125.127.100: bytes=32 time=199ms TTL=46
Reply from 74.125.127.100: bytes=32 time=197ms TTL=46
Reply from 74.125.127.100: bytes=32 time=196ms TTL=46
Reply from 74.125.127.100: bytes=32 time=204ms TTL=46
Reply from 74.125.127.100: bytes=32 time=203ms TTL=46
Reply from 74.125.127.100: bytes=32 time=208ms TTL=46
Reply from 74.125.127.100: bytes=32 time=200ms TTL=46
Reply from 74.125.127.100: bytes=32 time=201ms TTL=46
Reply from 74.125.127.100: bytes=32 time=200ms TTL=46
Reply from 74.125.127.100: bytes=32 time=205ms TTL=46
Reply from 74.125.127.100: bytes=32 time=199ms TTL=46

Ping statistics for 74.125.127.100:
Packets: Sent = 64, Received = 64, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 196ms, Maximum = 209ms, Average = 201ms


Mark Kelly
Plusnet Staff

Posts: 563


« Reply #20 on: July 30, 2009, 09:03:05 pm »

Hi shaggy

Thanks for the updates and the info.

Quote
If its the case that a new policy has been implemented which has migrated IPSec over TCP from Gold to Silver CoS then I need to know of this policy change as although I am very happy with Plusnet I cannot continue to use your service with VPN latency in excess of 2000ms.

No policy to implement that for VPN exists however IPsec on port 90 is a new one on me.
Quote
IPSec over TCP Port 90 results in DSCP 0x40 or Silver
IPSec over UDP results in DSCP 0x80 or Gold

So thats perfectly clear and fully identifies the issue for me. I would assume that the Ellacoya's are seeing your UDP traffic on port 90 as "other" and therefore not recognising it as VPN. I dont know if thats as a result of a signature update on the E30's or what but 'll find out.That should be fixable for us and I'll chase this in the morning.
Quote
In terms of using another Port this is set by Sun Microsystems ITOPS as a Global Standard I'm afraid I hold little sway in asking Sun to change its Global VPN Policy for me.

Understood and we should be in a position to properly classify that traffic.

Mark

Shaggy

Posts: 39

« Reply #21 on: July 31, 2009, 07:35:36 am »

Mark
    Many thanks for your assistance, just one question I am by no means an expert on traffic shaping but I would have thought that Ellacoya (assumed to be the chief packet inspector) would be able to identify IPSec as the protocol in use regardless of Port as the port doesn’t define the application use e.g. P2P over port 80?

  I also had a look at the wireshark trace I took of the IPSec over UDP as the application didn’t give me a Port option and it looks like when using IPSec over UDP the Ports in use are 4500 at each end, so not sure if that helps.

Thanks again for your help..

 Shaggy
Mark Kelly
Plusnet Staff

Posts: 563


« Reply #22 on: July 31, 2009, 11:16:11 am »

Hi Shaggy

The identification works on a number of factors one of which is signature. We don't appear to have a signature for that Sun VPN client hence the issues you have seen.

To be fair I cant see any documentation for the Sun / Cisco Client stating Port 90 is the default port, but I'm checking that directly with them. the port 4500 sounds more like what it should be.

However, I did initially panic as I guessed, wrongly, that you were a business customer, as the rules for VPN differ on business products and had you been using that client on a business product you would have received the correct classification. On the consumer product which you are currently on, it is unidentified and as such sitting in Silver.

Now that I'm comfortable that this inst a business customer issue I can stop panicking Smiley but we'll still work with you to get it resolved and ensure that the traffic is correctly tagged and classified.




MauriceB
Administrator

Posts: 3955

« Reply #23 on: July 31, 2009, 11:55:50 am »

Thanks for picking this up Mark

M
Mark Kelly
Plusnet Staff

Posts: 563


« Reply #24 on: July 31, 2009, 02:17:13 pm »

No worries Maurice.

In the interests of clarity and bearing in mind that we've just launched our new business products, would it be too cheeky to ask that we somehow identify this as a consumer only issue in the title.

I'd hate to think that our business base or potential business customers would see this and automatically assume that IPsec traffic is poo on our network Smiley If casual browsers jump to the same conclusion as I did initially, then there is a little risk.

Mark

Shaggy

Posts: 39

« Reply #25 on: July 31, 2009, 02:33:16 pm »

To clearly define this Topic as a "NON Business/Telecommuter Product VPN Issue" would be fine by me..

  Could I caveat that by saying currently VPN traffic in Silver is Poo and subject to high latency and packet drops?  blush

  Although I have every confidence Silver CoS for VPN will be revaluated?

 Thanks Shaggy
xpcomputers
Usergroup Member

Posts: 1068

« Reply #26 on: July 31, 2009, 02:36:55 pm »

Even if no-one had a problem with changing it... (which I'm not sure about... I'll defer to combined wisdom!)... I'm not sure how you word the title differently to make the distinction clear? Any ideas or suggestions?

I understand the concern Mark... but then LOTS of thread titles could sound bad for the supplier, but the thread contents normally make it clear (whether it was a supplier issue, or a customer mess up, or trying to do business things on a residential account etc).

Clearly anyone who reads this thread will see that Business Accounts wouldn't have been affected by this in the first place... and secondly, even on a residential account, you are looking to put this right so that VPN traffic runs as intended on the residential accounts anyway. So it will only affect those who see the title and don't read any further.... that would be a poor way to choose an ISP... but I'm sure it happens!

If the OP is happy to change it, then it solves everything, as then no one gets accused of changing their posts! (Of course, if they are happy, but can't change it, then one of us could do the deed for them!). Shaggy, do you mind?

Mike
xpcomputers
Usergroup Member

Posts: 1068

« Reply #27 on: July 31, 2009, 02:38:12 pm »

Cross posted with Shaggy. Can Shaggy confirm, are you on a Telecommuter package then, or a straight home package?
xpcomputers
Usergroup Member

Posts: 1068

« Reply #28 on: July 31, 2009, 02:42:03 pm »

Change made to:

Residential Broadband: Excessive latency on VPN IPSec traffic since last Thurs?

I hope this is OK with everyone.

I corrected the "since" spelling mistake, and had to cut Thursday to Thurs to fit in the space allowed.
MauriceB
Administrator

Posts: 3955

« Reply #29 on: July 31, 2009, 02:50:12 pm »

Good compromise Mike graduate
Pages: 1 [2] 3
  Print  
 
Jump to: