TCP/IP - HTTPS
how should I convert a message in TCP/IP protocol to HTTPS protocol?
Which class should I look into?
I think I have to pack some message in HTTP protocol in application layer and then send it through SSL, I know how to do the SSL part, but i am confused how to pack the message in HTTP protocol. Should I just add a HTTP header to the message?
Similar Messages
-
Hi,
I would like to know the difference between RCP/TCP and RPC/HTTP. Also, I would like to know where these two things are used in Exchange 2003,2007, 2010 & 2013 with respect to Outlook Connectivity. I meant internal connections and external connections.
I know that in Exchange 2003 & 2007 all internal connections were directly pointed to Mailbox Servers and all external connections were coming in through the CAS/FE. In Exchange 2010 even MAPI connection was also shift from Mailbox to CAS Server.
But I am facing difficulty in understanding between RPC/TCP, RPC/HTTP, RPC/HTTPS & MAPI/HTTP. Can some one please brief these things for me. I am unable to find any documents/articles in any of the forums.
Regards,
Noble
Regards, Noble K VargheseAll Outlook connectivity uses MAPI. RPC is simply how MAPI is wrapped for communication.
RPC/TCP is for local connectivity only. It is not for connectivity externally. Supported version of Exchange are 2003, 2007 and 2010.
RPC/HTTP is using HTTP for MAPI communication. External connectivity is supported. Supported version of Exchange are 2003, 2007, 2010 and 2013, however it should be noted that Exchange 2013 out of the box relies on RPC/HTTP. RPC/TCP is
not available in Exchange 2013.
MAPI/HTTP was introduced in Exchange 2013 CU4 (SP1). This allows MAPI communication that is only wrapped in HTTP for communication, rather than using RPC (see below link). Exchange 2013 CU4 (SP1) and above are supported and this must be enabled
before it can be used.
For further information, I suggest subscribing to and reading through the Exchange team blog:
http://blogs.technet.com/b/exchange/
Here is also a more recent blog post describing MAPI/HTTP, which also describes some of what I mentioned above:
http://blogs.technet.com/b/exchange/archive/2014/05/09/outlook-connectivity-with-mapi-over-http.aspx -
SAP ECC Interface w/ IDOC-XML using TCP/IP, HTTP, or FTP to 3rd-Party Syst.
I am trying to understand if the following interface options can occur (without the use of SAP PI or any other middleware):
Option 1A: Can I process an SAP ECC outbound IDoc in XML using TCP/IP to a non-SAP 3rd party system? Can you please explain the reason for why I can or can NOT do this. If possible, please provide supporting documentation on how-to do this?
Option 1B: Can I process an SAP ECC inbound XML-IDOC from a non-SAP calling system that used TCP/IP? Can you please explain the reason for why I can or can NOT do this. If possible, please provide supporting documentation on how-to do this?
Option 2A: Can I process an SAP ECC outbound IDOC in XML using HTTP to a non-SAP 3rd-party system? Can you please explain the reason for why I can or can NOT do this. If possible, please provide supporting documentation on how-to do this?
Option 2B: Can I process an SAP ECC inbound XML-IDOC from a non-SAP calling system that used HTTP? Can you please explain the reason for why I can or can NOT do this. If possible, please provide supporting documentation on how-to do this?
Option 3A: Can I process an SAP ECC outbound IDOC in XML using FTP to a non-SAP 3rd-party system? Can you please explain the reason for why I can or can NOT do this. If possible, please provide supporting documentation on how-to do this?
Option 3B: Can I process an SAP ECC inbound XML-IDOC from a non-SAP calling system that used FTP? Can you please explain the reason for why I can or can NOT do this. If possible, please provide supporting documentation on how-to do this?Hello Kirk ,
The answers for your question are:
Option 1A: Yes you can .you can use TCP/IP but you must have a middleware component for that such as BC/JCO .
Please see the link : [http://help.sap.com/saphelp_nw04/helpdata/EN/09/c88442a07b0e53e10000000a155106/frameset.htm]
Option 1B: See the link above.
Option 2A: You can use ABAP code :
[http://help.sap.com/saphelp_nw04/helpdata/EN/e5/4d3514c11411d4ad310000e83539c3/frameset.htm]
Option 2B: [http://help.sap.com/saphelp_nw04/helpdata/EN/90/4f3c2ec3c511d6b2b400508b6b8a93/frameset.htm]
Option 3A: Only with ABAP code :[Reg: FTP Connection;
Option 3B: See the link of Option 3A.
Good Luck,
Boaz
Edited by: Boaz Ornan on Feb 21, 2010 4:33 PM -
What is POP3 / SMTP / IMAP / SSL / TCP-IP / HTTP / HTTPs ?
Hi Experts.
Can anybody tell me about the following questions.
What is POP3 ?
What is IMAP ?
What is SMTP ?
What is SSL encryption ?
What is TCP-IP connection ?
what is HTTP ?
What is difference in HTTP:// and HTTPs:// ?
Thanks in advance.
Regards,
-=Soniya.=-Hi,
POP3: This is stands for Post Office Protocol this is part of mail inbox configuration, based on POP3 configuration mail will be reach to inbox from out side.
IMAP: This is stands for Internet Message Access Protocol, it is one of protocol for internet data transfer
SMTP: This is stands for Simple Mail Transport Protocol, it is outbox mail configuration, based on SMTP configuration mail will be send to target system
SSL: This is stands for Secure Socket Layer, this is mainly used to transfer data between two system in secure way. In this configuration we can provide security in transport (https) & message level (encryption & decryption)
TCP-IP: This is stands for Transmission Control Protocol-Internet Protocol, it is for using internet & intranet. This protocol will support most of all network.
HTTP: This is stands for Hyper Text Transport Protocol, this protocol convert data to XML format and send across internet & intranet.
What is difference in HTTP:// and HTTPs:// ?
HTTP & HTTPs main difference is security, http we don't have any security in message transport but HTTPs by default provide security in transport level & message level using digital certificates
I hope now clear -
Apologies if this sort of question has been asked before! Is it possible to write an application that can pick up messages (e.g. SOAP messages) on a local machine without using a ServerSocket? For example, can I get hold of SOAP messages sent to port 80 on my local machine even though there is an HTTP server on my machine bound to that port? If I use a ServerSocket in my Java app I inevitably get a JVM_Bind error.
I hope someone can help!
Thanks,
AndrewThere is no "clean" way of doing that, but if you have suitable permissions (root in Unix, I don't know if Windows requires admin) you may be able to snoop packets. Google for the jpcap library, I think you can write a packet snooper with it.
-
I appologize if this is not the correct place to post this question.. I am trying to understand the overhead with tcp and HTTP response that I see in the packet capture (wireshark) which I am attaching to this thread.
My understanding is:
I can calculate the TCP data portion by subtracting the ip/tcp headers from the total length field in IP header. My confusion is when looking at the tcp data payload and then seeing the overhead that is specified in the HTTP response header/message body. I see there is 1448 bytes that is the tcp data portion of the packet.
However, the HTTP response header is 347 bytes and the Content-Length of the entity message body is 3867 bytes. I am trying to wrap my head around how to determine the correct overhead for this specific packet. Normally this is very simple but its the HTTP rsponse header thats throwing me off.
Can anyone break this down and help me to understand how I can have 1448 for TCP data but greater values for the HTTP portion?So as I am thinking on this, after the first post..... The remaining would be the initial segment ( not really fragment ) of the response message..I think I was overcomplicating this when it is very simple...
Thanks for clarification. -
Load Balance https based on url
I am trying to configure ACE 4710 to load balance base on the URL, If it matches the specific URL ( /456/ ), the traffic will be sent to server farm 456 else the traffic will be sent to server farm 123.
I attached an image of the topology.
Ace Config:
rserver host SRV01_123
ip address 192.168.1.101
inservice
rserver host SRV02_123
ip address 192.168.1.102
inservice
rserver host SRV01_456
ip address 192.168.1.111
inservice
serverfarm host farm_123
rserver SRV01_123
inservice
rserver SRV02_123
inservice
serverfarm host farm_456
rserver SRV01_456
inservice
class-map match-all VIP_Application
2 match virtual-address 192.168.1.10 tcp eq https
class-map type http loadbalance match-all L7_server_456
2 match http url /456/
policy-map type loadbalance http first-match LB_Application
class L7_server_456
serverfarm farm_456
class class-default
serverfarm farm_123
policy-map multi-match ServerGroup1_PM
class VIP_Application
loadbalance vip inservice
loadbalance policy LB_Application
loadbalance vip icmp-reply
interface vlan 70
bridge-group 1
no shutdown
interface vlan 700
bridge-group 1
service-policy input ServerGroup1_PM
no shutdown
ThanksHi John,
If you want to do the offload in the ACE also called SSL termination, it is a two step process:
1- You need to upload your certificate and key to the ACE using FTP or one of the available methods.
2- Create the the SSL proxy service where you add these two files and finally add this service under the policy-multimatch for the VIP in question.
You also need to decide whether you want to keep your server listening in the encrypted port (that would be a two way encryption process called End-to-End SSL) or you can change the port to 80 and leave all the decyption process to the ACE (this would be transparent to the client, the site will show up as HTTPS all the time).
Here you can take a look at the SSL termination process (using clear text port in the backend servers).
Oficial Configuration Example
http://www.cisco.com/en/US/partner/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA4_1_0/configuration/ssl/guide/terminat.html
Cisco Wiki Example
http://docwiki.cisco.com/wiki/SSL_Termination_on_the_Cisco_Application_Control_Engine_Without_an_Existing_Chained_Certificate_and_Key_in_Routed_Mode_Configuration_Example
HTH
Pablo -
Safety of MS Sharing on LAN over TCP/IP via NetBIOS and/or Direct SMB
Shalini Sampath Kumar at http://answers.microsoft.com/en-us/windows/forum/windows_7-security/ suggested I post this question over
here:
What is the safest recommended way to set up MS File and Printer Sharing on a LAN with both Windows 7 Pro and XP Pro machines? Does "Direct hosting of SMB over TCP/IP," help? What about setting a "Scope ID" (or did that go out
with Windows NT)?
Background: I've been trained to be paranoid about NetBIOS over TCP/IP. Right now I have only XP Pro machines on my peer-to-peer workgroup LAN (behind a NAT router and with Simple File Sharing turned off), on which File and Printer Sharing has been
unbound from TCP/IP and bound to NetBEUI instead, so I feel fairly safe. Port scanning by ShieldsUp doesn't see any ports through the router, open or closed -- in other words, it appears to be "stealthed," for what that's worth. With
NetBIOS disabled on all computers inside the LAN, however, can I perform a valid test of what will happen when File and Printer Sharing is re-bound to TCP/IP?
My New Problem: I'm planning to add Window 7 Pro machines, for which NetBEUI isn't an option, and then to transition entirely to Win7 before XP goes off extended support in April. I will still use a peer-to-peer architecture with password-protected
sharing turned on (no HomeGroup). It appears that I can still get rid of NetBIOS (and WINS) in favor of "Direct hosting of SMB over TCP/IP," which sounds safer. Apparently then only port 445 will be vulnerable instead of ports 137-139.
In any case I want to do everything I can to protect my file-sharing port(s) from the Internet (e.g., from anyone who might break into my LAN either by making a wireless connection or by hacking the router itself). Can anybody give a clear set of steps
to change sharing from NetBIOS (which I would like to disable entirely) to direct hosting of SMB and to verify that I'm protected as well as possible?
I will have to completely revamp the network-file-sharing configuration of my XP machines as soon as the first Win7 machine goes on line (and possibly tweak the configuration of Win7 as well), perhaps as early as this week. I want to do this in the way that
maximizes security to the extent possible. Thanks in advance more details and guidance on this topic! -- JCW2
P.S. -- These computers are all laptops and will be used away from my home LAN -- another reason for paranoia about File and Printer Sharing. I realize that Windows 7 provides an easy way to disable F&PS by selecting any new network location as
"public," but XP does not (as far as I know). Fixing that will take more effort and be harder to remember... -- JCW2Removing the NetBIOS transport has several advantages compared to NetBIOS over TCP, you can find detailed infromation in the following KB
Direct hosting of SMB over TCP/IP
http://support.microsoft.com/kb/204279/en-us
Yolanda
TechNet Community Support
Hi again -- I think I'm slowly catching up with you. Following from my previous message...
Somebody on another forum mentioned creating "Hosts" files on each computer to substitute for the DNS server that I don't have on my workgroup. This is intriguing if I can figure out how to set it up. (I've heard it said that taking control of
your "Hosts" file is a good safety precaution anyhow, since it is a frequent target of hackers trying to divert legitimate Web requests to their own malicious sites.) Does anybody have tips and/or references that would help me accomplish the name resolution
there?
Finally, what functionality do I really lose by going the Direct-Hosting-of-SMB-with-Hosts-file (or drive mapping) route as opposed to using NetBIOS over TCP/IP? Granted, any new machine added to the network would also have to be added to all the "Hosts"
files (or mapped to a new drive letter) on each machine; but given that I already have to add it to the MAC filter and assign it a DHCP reservation in my router, this isn't a heavy burden for something that doesn't happen often. Would everything then
work the same as if NetBIOS were providing the name resolution?
One missing piece that I see so far -- it's not obvious how this same trick would apply to printer sharing (although I'm not using that feature right now anyhow). Could this be handled seamlessly through the "Hosts" file as well?
Thanks and Best Regards to All -- JCW2 -
Non-global zone sending TCP SYN-ACK packet over wrong interface.
After spending many hours looking at ipmon/ethereal logs, I believe I've found
a explanation (a bug?) for the following strange behaviour (Solaris 10u1):
I've got a non-global zone with Apache2 with dedicated IP and bound to interface e1000g2 of a Sun X4200 box. The global zone has a different dedicated IP bound to a different interface e1000g0.
When I point a browser at the web site, the HTML page often comes up immediately, but sometimes it will hang and only load when I press the reload browser button one or multiple times. This is reproducible with different browsers from different networks with or without DNS resolution. It's reproducible with other non-local zones configured alike and running different TCP based services (namely SSH or non-Apache HTTP).
This is what happens in a failing case (Ethereal client dump "dump_failed.txt" and IPF log "att1.txt" lines 1-3 pp): the incoming TCP SYN comes over interface e1000g2 (correct) and is passed by IPF. However, the non-global zone sends the TCP SYN-ACK package back over interface e1000g0, which is wrong and causes IPF to fail to build a correct state entry. Then, afterwards, the response packets from the webserver will be filtered by IPF, since it has no state entry.
In the success case (Ethereal client dump "dump_success.txt" and IPF log "att1.txt" lines 19-21 pp), the incoming TCP SYN is answered correctly by a TCP SYN-ACK both over interface e1000g2. IPF can build a state entry and all subsequent packets from the webserver reach the client.
=====
The non-global zone has this setup:
zonecfg:ws1> info
...snip...
net:
address: 62.146.25.34
physical: e1000g2
zonecfg:ws1>
=====
The relevant (as of the IPF log) IPF rules are:
rule 1: block out log all
rule 16: pass in log quick proto tcp from any to 62.146.25.34 port = 80 keep state
=====
If I didn't miss an important point, I suspect this to be a bug in Zones and/or IPF.
Any hints?
Thx,
Tobias
"att1.txt":
LINE PACKET_DT PACKET_FS PACKET_IFC RULE_NUMBER RULE_ACTION SOURCE_IP SOURCE_PORT DEST_IP DEST_PORT PROTOCOL TCP_FLAGS
1 08.05.2006 21:24:09 786741 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp S
2 08.05.2006 21:24:09 786863 e1000g0 16 p 62.146.25.34 80 84.56.16.159 60693 tcp AS
3 08.05.2006 21:24:09 808218 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp A
4 08.05.2006 21:24:09 837170 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
5 08.05.2006 21:24:09 837189 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
6 08.05.2006 21:24:09 837479 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AP
7 08.05.2006 21:24:12 823801 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
8 08.05.2006 21:24:12 823832 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
9 08.05.2006 21:24:13 210039 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AP
10 08.05.2006 21:24:18 839318 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
11 08.05.2006 21:24:18 839351 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
12 08.05.2006 21:24:19 970040 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AP
13 08.05.2006 21:24:24 840073 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AF
14 08.05.2006 21:24:30 870503 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
15 08.05.2006 21:24:30 870538 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
16 08.05.2006 21:24:33 480059 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
17 08.05.2006 21:24:45 347464 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AF
18 08.05.2006 21:24:45 347498 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
19 08.05.2006 21:24:47 857068 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp S
20 08.05.2006 21:24:47 857118 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AS
21 08.05.2006 21:24:47 878257 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp A
22 08.05.2006 21:24:47 907630 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp AP
23 08.05.2006 21:24:47 907644 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp A
24 08.05.2006 21:24:47 907892 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AP
25 08.05.2006 21:24:47 976361 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp AP
26 08.05.2006 21:24:47 976375 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp A
27 08.05.2006 21:24:47 976487 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AP
28 08.05.2006 21:24:48 127599 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp A
29 08.05.2006 21:24:54 932569 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AFP
30 08.05.2006 21:24:54 932595 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
31 08.05.2006 21:25:00 490052 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
32 08.05.2006 21:25:02 980057 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AF
33 08.05.2006 21:25:03 1890 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp A
34 08.05.2006 21:25:09 907916 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp AF
35 08.05.2006 21:25:09 907949 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp A
36 08.05.2006 21:25:42 948502 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AFP
37 08.05.2006 21:25:42 948535 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
38 08.05.2006 21:25:54 500051 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
39 08.05.2006 21:26:54 510046 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
40 08.05.2006 21:27:54 520041 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
41 08.05.2006 21:28:54 530040 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
42 08.05.2006 21:29:54 540039 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
43 08.05.2006 21:30:54 550039 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
44 08.05.2006 21:31:54 560041 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
"dump_failed.txt":
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.101 62.146.25.34 TCP 1079 > http [SYN] Seq=0 Len=0 MSS=1460
Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x0269 (617)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde9d [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 0, Len: 0
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 65535
Checksum: 0x5c3c [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
2 0.022698 62.146.25.34 192.168.1.101 TCP http > 1079 [SYN, ACK] Seq=0 Ack=1 Win=49368 Len=0 MSS=1452
Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x002f (47)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2ed8 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1079 (1079), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 1079 (1079)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 28 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 49368
Checksum: 0xd017 [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
3 0.022749 192.168.1.101 62.146.25.34 TCP 1079 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x026a (618)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdea4 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 65535
Checksum: 0x19dc [incorrect, should be 0xbdac]
No. Time Source Destination Protocol Info
4 0.022919 192.168.1.101 62.146.25.34 HTTP GET / HTTP/1.1
Frame 4 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x026b (619)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdcfd [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
5 3.013084 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
Frame 5 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x0276 (630)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdcf2 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
6 9.029003 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
Frame 6 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x027f (639)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdce9 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
7 21.060827 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
Frame 7 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x0284 (644)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdce4 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
8 35.561984 192.168.1.101 62.146.25.34 TCP 1079 > http [FIN, ACK] Seq=423 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
Frame 8 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x029a (666)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde74 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 423, Ack: 1, Len: 0
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0011 (FIN, ACK)
Window size: 65535
Checksum: 0x19dc [incorrect, should be 0xbc05]
"dump_success.txt":
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.101 62.146.25.34 TCP 1083 > http [SYN] Seq=0 Len=0 MSS=1460
Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x02a3 (675)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde63 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 0, Len: 0
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 65535
Checksum: 0x70ca [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
2 0.020553 62.146.25.34 192.168.1.101 TCP http > 1083 [SYN, ACK] Seq=0 Ack=1 Win=49368 Len=0 MSS=1452
Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x006b (107)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2e9c [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 28 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 49368
Checksum: 0xb530 [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
3 0.020599 192.168.1.101 62.146.25.34 TCP 1083 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x02a4 (676)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde6a [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 65535
Checksum: 0x19dc [incorrect, should be 0xa2c5]
No. Time Source Destination Protocol Info
4 0.020746 192.168.1.101 62.146.25.34 HTTP GET / HTTP/1.1
Frame 4 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x02a5 (677)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdcc3 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xb2be]
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
5 0.071290 62.146.25.34 192.168.1.101 TCP http > 1083 [ACK] Seq=1 Ack=423 Win=49368 Len=0
Frame 5 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x006c (108)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2ea3 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 1, Ack: 423, Len: 0
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 423 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 49368
Checksum: 0xe046 [correct]
No. Time Source Destination Protocol Info
6 0.075838 62.146.25.34 192.168.1.101 HTTP HTTP/1.1 200 OK (text/html)
Frame 6 (413 bytes on wire, 413 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 399
Identification: 0x006d (109)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2d3b [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 1, Ack: 423, Len: 359
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 1 (relative sequence number)
Next sequence number: 360 (relative sequence number)
Acknowledgement number: 423 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 49368
Checksum: 0x29b8 [correct]
Hypertext Transfer Protocol
Line-based text data: text/html
No. Time Source Destination Protocol Info
7 0.095473 192.168.1.101 62.146.25.34 HTTP GET /favicon.ico HTTP/1.1
Frame 7 (407 bytes on wire, 407 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 393
Identification: 0x02aa (682)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdd03 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 423, Ack: 360, Len: 353
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 423 (relative sequence number)
Next sequence number: 776 (relative sequence number)
Acknowledgement number: 360 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65176
Checksum: 0x1b3d [incorrect, should be 0x1e0c]
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
8 0.139786 62.146.25.34 192.168.1.101 TCP http > 1083 [ACK] Seq=360 Ack=776 Win=49368 Len=0
Frame 8 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x006e (110)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2ea1 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 360, Ack: 776, Len: 0
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 360 (relative sequence number)
Acknowledgement number: 776 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 49368
Checksum: 0xdd7e [correct]
No. Time Source Destination Protocol Info
9 0.144850 62.146.25.34 192.168.1.101 HTTP HTTP/1.1 404 Not Found (text/html)
Frame 9 (464 bytes on wire, 464 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 450
Identification: 0x006f (111)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2d06 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 360, Ack: 776, Len: 410
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 360 (relative sequence number)
Next sequence number: 770 (relative sequence number)
Acknowledgement number: 776 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 49368
Checksum: 0x7a71 [correct]
Hypertext Transfer Protocol
Line-based text data: text/html
No. Time Source Destination Protocol Info
10 0.269307 192.168.1.101 62.146.25.34 TCP 1083 > http [ACK] Seq=776 Ack=770 Win=64766 [TCP CHECKSUM INCORRECT] Len=0
Frame 10 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x02af (687)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde5f [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 776, Ack: 770, Len: 0
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 776 (relative sequence number)
Acknowledgement number: 770 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 64766
Checksum: 0x19dc [incorrect, should be 0x9fbe]lev wrote:This performance regression renders openvpn with a tun adapter unusable if client and server use kernel 3.14 .
Thus I created a bug report: https://bugs.archlinux.org/task/40089
i actually noticed it to be an "either-or" type of thing; my Windows clients were seeing the same thing coming off a 3.14 openvpn server.
yeah, weird issue. like i noticed spurts of even-powers-of-2 sized packets
Client connecting to 10.10.10.6, TCP port 5001
TCP window size: 416 KByte
[ 3] local 10.10.10.1 port 40643 connected with 10.10.10.6 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 2.0- 4.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 4.0- 6.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 6.0- 8.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 8.0-10.0 sec 128 KBytes 524 Kbits/sec
[ 3] 10.0-12.0 sec 128 KBytes 524 Kbits/sec
[ 3] 12.0-14.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 14.0-16.0 sec 128 KBytes 524 Kbits/sec
[ 3] 16.0-18.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 18.0-20.0 sec 128 KBytes 524 Kbits/sec
[ 3] 20.0-22.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 22.0-24.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 24.0-26.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 26.0-28.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 28.0-30.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 30.0-32.0 sec 128 KBytes 524 Kbits/sec
[ 3] 32.0-34.0 sec 640 KBytes 2.62 Mbits/sec
[ 3] 34.0-36.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 36.0-38.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 38.0-40.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 40.0-42.0 sec 128 KBytes 524 Kbits/sec -
Outlook 2010 - Prevent fallback to Http via Group Policy
We use OL2010 with Exchange 2010 in a Windows 2008 R2 AD environment
We use VDI desktops for remote users, and therefore
never want to fallback from tcp to http (outlook anywhere)
Is there a way to configure Group Policy to ensure that:
(1) All accounts connect without the HTTP option (and with tcp)
(2) Outlook is prevented from falling back to Http even when the tcp connection is slow or unavailable
My understanding is that tcp/rcp will be faster than Http since we are only ever talking about LAN connections
The situation we want to avoid is the one where Outlook falls back to Http when the Exchange Server is taken down for maintenance, for example, due to Windows updates. This is an issue for us because of the use of VDI desktops which are not guaranteed to
be shut down during off-peak hours or during maintenance windows.
I cannot see any appropriate settings in the Office 2010 GP Administrative Templates
thanksMake sure you have the correct adm:
http://support.microsoft.com/kb/2426686
The feature you probably want to disable is the
RPC/HTTP Connection Flags and set to None or 0. You'll have to test that out.
Twitter!: Please Note: My Posts are provided “AS IS” without warranty of any kind, either expressed or implied. -
ACE - HTTPS CLASS MAP CONFIGURATION
Hi,
We have a secured web site (HTTPS) currently fronted by Cisco ACE 4170, running version A5(1.2). We are trying to use the http class map to manipulate the traffic flow in the following manner:
https://abc.com/ABC/* -> serverfarm#1
https://abc.com/* -> serverfarm#2 (Default)
Tecnically this should not be difficult and below is a sample of our configuration. We have similar configuration working on our non-secured web site (HTTP) However for the secure web site, the https request https://abc.com/ABC/xxx is continued being routed to serverfarm#2 instead of serverfarm#1 which is very frustrating.
We can easily get this working on my F5 LTM within 5 minutes but this Cisco ACE continue to frustrate me...Appreciate if any expert on Cisco ACE can help to advise on our configuration.. Thanks.
=========================================================
serverfarm host serverfarm#1
predictor leastconns
probe https_probe
rserver rs_server#1
inservice
rserver rs_server#2
inservice
serverfarm host serverfarm#2
predictor leastconns
probe https_probe
rserver rs_server#3
inservice
rserver rs_server#4
inservice
sticky http-cookie STICKY_HTTPS_serverfarm#1
cookie insert browser-expire
timeout 15
replicate sticky
serverfarm serverfarm#1
sticky http-cookie STICKY_HTTPS_serverfarm#2
cookie insert browser-expire
timeout 15
replicate sticky
serverfarm serverfarm#2
class-map type http loadbalance match-any class-map-serverfarm#1
2 match http url /ABC/.*
policy-map type loadbalance first-match vs_serverfarm_https
class class-map-serverfarm#1
sticky-serverfarm STICKY_HTTPS_serverfarm#1
insert-http x-forward header-value "%is"
ssl-proxy client ssl_serverfarm
class class-default
sticky-serverfarm STICKY_HTTPS_serverfarm#2
insert-http x-forward header-value "%is"
ssl-proxy client ssl_serverfarm
=========================================================Kanwaljeet,
Yes, we are using ACE for SSL termination i.e. front end is https and back-end is also https.
We are doing end-to-end encryption as our IT security and audit wanted end-to-end encryption between the client and servers. ACE should be able to look at the HTTP header at the front end since the client SSL session is terminate on the ACE.
Below is an extract of the configuration, I've leave out the remaining configuration which is not required.
=========================================================
serverfarm host serverfarm#1
predictor leastconns
probe https_probe
rserver rs_server#1
inservice
rserver rs_server#2
inservice
serverfarm host serverfarm#2
predictor leastconns
probe https_probe
rserver rs_server#3
inservice
rserver rs_server#4
inservice
sticky http-cookie STICKY_HTTPS_serverfarm#1
cookie insert browser-expire
timeout 15
replicate sticky
serverfarm serverfarm#1
sticky http-cookie STICKY_HTTPS_serverfarm#2
cookie insert browser-expire
timeout 15
replicate sticky
serverfarm serverfarm#2
class-map match-all vs_serverfarm
2 match virtual-address 10.178.50.140 tcp eq https
class-map type http loadbalance match-any class-map-serverfarm#1
2 match http url /ABC/.*
policy-map type loadbalance first-match vs_serverfarm_https
class class-map-serverfarm#1
sticky-serverfarm STICKY_HTTPS_serverfarm#1
insert-http x-forward header-value "%is"
ssl-proxy client ssl_serverfarm
class class-default
sticky-serverfarm STICKY_HTTPS_serverfarm#2
insert-http x-forward header-value "%is"
ssl-proxy client ssl_serverfarm
policy-map multi-match PRODWEB_POLICY
class vs_serverfarm
loadbalance vip inservice
loadbalance policy vs_serverfarm_https
loadbalance vip icmp-reply active
nat dynamic 100 vlan 100
ssl-proxy server ssl_serverfarm
========================================================= -
TCP COMMUNICATION ON INTERNET
Hello..
There is one example "TCP communication client-server model" in example finder. I have tested it. It is running on local LAN connection.
What should I do to run it on internet...
Please let me know
Thanks
PrashhThe only thing you need to change to run that example across the world, rather than across the room, is the IP addresses.
Your machines have to have internet access to the outside world, of course.
I have a couple of blog entries describing the basics of TCP communications:
http://culverson.com/category/tcp/
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks -
Hello,
our customer has a problem with correct closing TCP connections on the ACE. TCP session (HTTP protocol) is closed _correctly_ (we can see it in the sniffer output), but 'sh conn' on the ACE shows it as 'established' (session is already closed). TCP timeout is set to default (60min).
Any new connection from the same src port (because many connection to the service) is closed after TCP session is established.
When I try generate 200 concurrent sessions TCP sessions in my lab, this are on the ACE closed correctly. Customer's traffic is around 20-30.000 concurrent session, but I can't generate so much traffic.
SW version on the ACE: 3.0(0)A1(3b)
thx
martinThanks Gilles!
The problem occurs only with traffic from WAP nodes (too many short HTTP requests).
We try it upgrade to A1(5b), but I'm not sure, if this is our problem...
Bug description:
Symptom:
With L7 LB configuration, Some times connections do not close.
Conditions:
SYN sent to Real server may result in ACK coming from server. ACE TCP module was not handling this ACK correctly.
...but our traffic is only L4 LB and we have a problem with connection state on the ACE from both sides (client and server). on the client and server side is connection closed properly, but on the ACE module ('sh conn') we can see it in 'established' state. It's closed after TCP timeout and that is not correct.
martin -
Load Balance HTTPS servers with redirection
Hello,
I have been tasked with ACE configuration at work as the prior go-to guy for load balancing is no longer available. Trouble is, I have little idea what I’m doing when it comes to the ACE. So, forgive me if the question I have is super basic. After doing some research I put together a LB config, but its not working.
I was trying to load balance 10 servers, split into groups of 2 using 5 VIPS (1 VIP for each group of 2 servers). The servers serve an ssl web app.
Below is my configuration. What am I doing wrong? Does the config have any glaring errors? I've been staring at this thing on and off for a week and searching these forums trying to figure it out.
Any help provided will greatly appreciated.
probe tcp probe_443
port 443
interval 30
passdetect interval 5
probe https probe_https_test
interval 30
passdetect interval 5
ssl version all
request method get url /test.html
expect status 200 200
rserver host QA-1.1
ip address 10.200.162.126
inservice
rserver host QA-1.2
ip address 10.200.162.127
inservice
rserver redirect QA-group_1_redirect_rserver
webhost-redirection https://10.37.5.73/ 302
inservice
rserver host QA-2.1
ip address 10.200.162.22
inservice
rserver host QA-2.2
ip address 10.200.162.240
inservice
rserver redirect QA-group_2_redirect_rserver
webhost-redirection https://10.37.5.74/ 302
inservice
rserver host QA-3.1
ip address 10.200.162.181
inservice
rserver host QA-3.2
ip address 10.200.162.50
inservice
rserver redirect QA-group_3_redirect_rserver
webhost-redirection https://10.37.5.75/ 302
inservice
rserver host QA-4.1
ip address 10.200.162.23
inservice
rserver host QA-4.2
ip address 10.200.162.241
inservice
rserver redirect QA-group_4_redirect_rserver
webhost-redirection https://10.37.5.76/ 302
inservice
rserver host QA-5.1
ip address 10.200.162.182
inservice
rserver host QA-5.2
ip address 10.200.162.51
inservice
rserver redirect QA-group_5_redirect_rserver
webhost-redirection https://10.37.5.77/ 302
inservice
serverfarm host SF_QA-group_1_HTTPS
failaction reassign
predictor leastconns
probe probe_443
probe probe_https_test
rserver QA-1.1 443
inservice
rserver QA-1. 2 443
inservice
serverfarm host SF_QA-group_2_HTTPS
failaction reassign
predictor leastconns
probe probe_443
probe probe_https_test
rserver QA-2.1 443
inservice
rserver QA-2. 2 443
inservice
serverfarm host SF_QA-group_3_HTTPS
failaction reassign
predictor leastconns
probe probe_443
probe probe_https_test
rserver QA-3.1 443
inservice
rserver QA-3. 2 443
inservice
serverfarm host SF_QA-group_4_HTTPS
failaction reassign
predictor leastconns
probe probe_443
probe probe_https_test
rserver QA-4.1 443
inservice
rserver QA-4. 2 443
inservice
serverfarm host SF_QA-group_5_HTTPS
failaction reassign
predictor leastconns
probe probe_443
probe probe_https_test
rserver QA-5.1 443
inservice
rserver QA-5. 2 443
inservice
serverfarm redirect SF_ QA-group_1_REDIRECT
rserver QA-group_1_redirect_rserver
inservice
serverfarm redirect SF_ QA-group_2_REDIRECT
rserver QA-group_2_redirect_rserver
inservice
serverfarm redirect SF_ QA-group_3_REDIRECT
rserver QA-group_3_redirect_rserver
inservice
serverfarm redirect SF_ QA-group_4_REDIRECT
rserver QA-group_4_redirect_rserver
inservice
serverfarm redirect SF_ QA-group_5_REDIRECT
rserver QA-group_5_redirect_rserver
inservice
sticky ip-netmask 255.255.255.255 address source SRC_ QA-group_1_STICKY
serverfarm SF_ QA-group_1_HTTPS
timeout 30
replicate sticky
sticky ip-netmask 255.255.255.255 address source SRC_ QA-group_2_STICKY
serverfarm SF_ QA-group_2_HTTPS
timeout 30
replicate sticky
sticky ip-netmask 255.255.255.255 address source SRC_ QA-group_3_STICKY
serverfarm SF_ QA-group_3_HTTPS
timeout 30
replicate sticky
sticky ip-netmask 255.255.255.255 address source SRC_ QA-group_4_STICKY
serverfarm SF_ QA-group_4_HTTPS
timeout 30
replicate sticky
sticky ip-netmask 255.255.255.255 address source SRC_ QA-group_5_STICKY
serverfarm SF_ QA-group_5_HTTPS
timeout 30
replicate sticky
class-map match-all QA-group_1_HTTP
3 match virtual-address 10.37.5.73 tcp eq www
class-map match-all QA-group_1_HTTPS
3 match virtual-address 10.37.5.73 tcp eq https
class-map match-all QA-group_2_HTTP
3 match virtual-address 10.37.5.74 tcp eq www
class-map match-all QA-group_2_HTTPS
3 match virtual-address 10.37.5.74 tcp eq https
class-map match-all QA-group_3_HTTP
3 match virtual-address 10.37.5.75 tcp eq www
class-map match-all QA-group_3_HTTPS
3 match virtual-address 10.37.5.75 tcp eq https
class-map match-all QA-group_4_HTTP
3 match virtual-address 10.37.5.76 tcp eq www
class-map match-all QA-group_4_HTTPS
3 match virtual-address 10.37.5.76 tcp eq https
class-map match-all QA-group_5_HTTPS
3 match virtual-address 10.37.5.77 tcp eq www
class-map match-all QA-group_5_HTTPS
3 match virtual-address 10.37.5.77 tcp eq https
class-map type management match-any remote-management
2 match protocol http any
3 match protocol https any
4 match protocol icmp any
5 match protocol snmp any
6 match protocol ssh any
policy-map type management first-match remote-access
class remote-management
permit
policy-map type loadbalance first-match QA-group_1_REDIRECT
class class-default
serverfarm SF_ QA-group_1_REDIRECT
policy-map type loadbalance first-match QA-group_2_REDIRECT
class class-default
serverfarm SF_ QA-group_2_REDIRECT
policy-map type loadbalance first-match QA-group_3_REDIRECT
class class-default
serverfarm SF_ QA-group_3_REDIRECT
policy-map type loadbalance first-match QA-group_4_REDIRECT
class class-default
serverfarm SF_ QA-group_4_REDIRECT
policy-map type loadbalance first-match QA-group_5_REDIRECT
class class-default
serverfarm SF_ QA-group_5_REDIRECT
policy-map multi-match SERVICE_VIPS
class QA-group_1_HTTPS
loadbalance vip inservice
loadbalance policy HTTPS_ QA-group_1_HTTPS _L7_BALANCED
loadbalance vip icmp-reply
nat dynamic 1 vlan 25
class QA-group_1_HTTP
loadbalance vip inservice
loadbalance policy QA-group_1_REDIRECT
class QA-group_2_HTTPS
loadbalance vip inservice
loadbalance policy HTTPS_ QA-group_2_HTTPS _L7_BALANCED
loadbalance vip icmp-reply
nat dynamic 1 vlan 25
class QA-group_2_HTTP
loadbalance vip inservice
loadbalance policy QA-group_2_REDIRECT
class QA-group_3_HTTPS
loadbalance vip inservice
loadbalance policy HTTPS_ QA-group_3_HTTPS _L7_BALANCED
loadbalance vip icmp-reply
nat dynamic 1 vlan 25
class QA-group_3_HTTP
loadbalance vip inservice
loadbalance policy QA-group_3_REDIRECT
class QA-group_4_HTTPS
loadbalance vip inservice
loadbalance policy HTTPS_ QA-group_4_HTTPS _L7_BALANCED
loadbalance vip icmp-reply
nat dynamic 1 vlan 25
class QA-group_4_HTTP
loadbalance vip inservice
loadbalance policy QA-group_4_REDIRECT
class QA-group_5_HTTPS
loadbalance vip inservice
loadbalance policy HTTPS_ QA-group_4_HTTPS _L7_BALANCED
loadbalance vip icmp-reply
nat dynamic 1 vlan 25
class QA-group_5_HTTP
loadbalance vip inservice
loadbalance policy QA-group_4_REDIRECT
interface vlan 25
ip address 10.37.5.72 255.255.255.0
access-group input everyone
service-policy input remote-access
service-policy input SERVICE_VIPS
no shutdown
ip route 0.0.0.0 0.0.0.0 10.37.5.1Fnu,
Thank you so much for your reply.
At this point I can get to the real server IP's via ping and https in a browser from my PC. I can also ping the gateway and all the real server IP's from the ACE context i'm working on. However, the VIPS are not working. When I attempt to use one of the VIPS in the browser, the request times out. When I issue the command ":show service-policy" I see a hit count (which increments every time I try and reach the VIP via the browser) but the dropped counter is equal to the hit counter. I will paste the running config from the context I’m working in along with the output from the show service-policy command.
Any suggestions on how I can get this working would be greatly appreciated.
csc# show run
Generating configuration....
access-list Servers line 3 extended permit tcp any any eq https
access-list Servers line 5 extended permit tcp any any eq www
access-list everyone line 1 extended permit ip any any
access-list everyone line 2 extended permit icmp any any
probe tcp probe_443
port 443
interval 30
passdetect interval 5
rserver host QA-1.1
ip address 10.37.5.111
inservice
rserver host QA-1.2
ip address 10.37.5.88
inservice
rserver host QA-2.1
ip address 10.37.5.84
inservice
rserver host QA-2.2
ip address 10.37.5.89
inservice
rserver host QA-3.1
ip address 10.37.5.85
inservice
rserver host QA-3.2
ip address 10.37.5.90
inservice
rserver host QA-4.1
ip address 10.37.5.86
inservice
rserver host QA-4.2
ip address 10.37.5.81
inservice
rserver host QA-5.1
ip address 10.37.5.87
inservice
rserver host QA-5.2
ip address 10.37.5.92
inservice
rserver redirect QA-group_1_redirect_rserver
webhost-redirection https://10.37.5.93/ 302
inservice
rserver redirect QA-group_2_redirect_rserver
webhost-redirection https://10.37.5.94/ 302
inservice
rserver redirect QA-group_3_redirect_rserver
webhost-redirection https://10.37.5.95/ 302
inservice
rserver redirect QA-group_4_redirect_rserver
webhost-redirection https://10.37.5.96/ 302
inservice
rserver redirect QA-group_5_redirect_rserver
webhost-redirection https://10.37.5.97/ 302
inservice
serverfarm host SF_QA-group_1_HTTPS
failaction reassign
predictor leastconns
probe probe_443
rserver QA-1.1 443
inservice
rserver QA-1.2 443
inservice
serverfarm redirect SF_QA-group_1_REDIRECT
rserver QA-group_1_redirect_rserver
inservice
serverfarm host SF_QA-group_2_HTTPS
failaction reassign
predictor leastconns
probe probe_443
rserver QA-2.1 443
inservice
rserver QA-2.2 443
inservice
serverfarm redirect SF_QA-group_2_REDIRECT
rserver QA-group_2_redirect_rserver
inservice
serverfarm host SF_QA-group_3_HTTPS
failaction reassign
predictor leastconns
probe probe_443
rserver QA-3.1 443
inservice
rserver QA-3.2 443
inservice
serverfarm redirect SF_QA-group_3_REDIRECT
rserver QA-group_3_redirect_rserver
inservice
serverfarm host SF_QA-group_4_HTTPS
failaction reassign
predictor leastconns
probe probe_443
rserver QA-4.1 443
inservice
rserver QA-4.2 443
inservice
serverfarm redirect SF_QA-group_4_REDIRECT
rserver QA-group_4_redirect_rserver
inservice
serverfarm host SF_QA-group_5_HTTPS
failaction reassign
predictor leastconns
probe probe_443
rserver QA-5.1 443
inservice
rserver QA-5.2 443
inservice
serverfarm redirect SF_QA-group_5_REDIRECT
rserver QA-group_5_redirect_rserver
inservice
serverfarm host SF_QA-group_HTTPS
serverfarm host SF_QA-group__HTTPS
sticky ip-netmask 255.255.255.255 address source SRC_QA-group_1_STICKY
serverfarm SF_QA-group_1_HTTPS
timeout 30
replicate sticky
sticky ip-netmask 255.255.255.255 address source SRC_QA-group_2_STICKY
serverfarm SF_QA-group_2_HTTPS
timeout 30
replicate sticky
sticky ip-netmask 255.255.255.255 address source SRC_QA-group_3_STICKY
serverfarm SF_QA-group_3_HTTPS
timeout 30
replicate sticky
sticky ip-netmask 255.255.255.255 address source SRC_QA-group_4_STICKY
serverfarm SF_QA-group_4_HTTPS
timeout 30
replicate sticky
sticky ip-netmask 255.255.255.255 address source SRC_QA-group_5_STICKY
serverfarm SF_QA-group_5_HTTPS
timeout 30
replicate sticky
class-map match-all QA-group_1_HTTP
3 match virtual-address 10.37.5.93 tcp eq www
class-map match-all QA-group_1_HTTPS
3 match virtual-address 10.37.5.93 tcp eq https
class-map match-all QA-group_2_HTTP
3 match virtual-address 10.37.5.94 tcp eq www
class-map match-all QA-group_2_HTTPS
3 match virtual-address 10.37.5.94 tcp eq https
class-map match-all QA-group_3_HTTP
3 match virtual-address 10.37.5.95 tcp eq www
class-map match-all QA-group_3_HTTPS
3 match virtual-address 10.37.5.95 tcp eq https
class-map match-all QA-group_4_HTTP
3 match virtual-address 10.37.5.96 tcp eq www
class-map match-all QA-group_4_HTTPS
3 match virtual-address 10.37.5.76 tcp eq https
class-map match-all QA-group_5_HTTP
3 match virtual-address 10.37.5.97 tcp eq www
class-map match-all QA-group_5_HTTPS
3 match virtual-address 10.37.5.97 tcp eq https
class-map type management match-any remote-management
2 match protocol http any
3 match protocol https any
4 match protocol icmp any
5 match protocol snmp any
6 match protocol ssh any
policy-map type management first-match remote-access
class remote-management
permit
policy-map type loadbalance first-match QA-group_1_REDIRECT
class class-default
policy-map type loadbalance first-match QA-group_2_REDIRECT
class class-default
serverfarm SF_QA-group_2_REDIRECT
policy-map type loadbalance first-match QA-group_3_REDIRECT
class class-default
serverfarm SF_QA-group_3_REDIRECT
policy-map type loadbalance first-match QA-group_4_REDIRECT
class class-default
serverfarm SF_QA-group_4_REDIRECT
policy-map type loadbalance first-match QA-group_5_REDIRECT
class class-default
serverfarm SF_QA-group_5_REDIRECT
policy-map multi-match SERVICE_VIPS
class QA-group_1_HTTPS
loadbalance vip inservice
loadbalance policy QA-group_1_REDIRECT
loadbalance vip icmp-reply
class QA-group_1_HTTP
loadbalance vip inservice
loadbalance policy QA-group_1_REDIRECT
class QA-group_2_HTTPS
loadbalance vip inservice
loadbalance policy QA-group_2_REDIRECT
loadbalance vip icmp-reply
class QA-group_2_HTTP
loadbalance vip inservice
loadbalance policy QA-group_2_REDIRECT
class QA-group_3_HTTPS
loadbalance vip inservice
loadbalance policy QA-group_3_REDIRECT
loadbalance vip icmp-reply
class QA-group_3_HTTP
loadbalance vip inservice
loadbalance policy QA-group_3_REDIRECT
class QA-group_4_HTTPS
loadbalance vip inservice
loadbalance policy QA-group_4_REDIRECT
loadbalance vip icmp-reply
class QA-group_4_HTTP
loadbalance vip inservice
loadbalance policy QA-group_4_REDIRECT
class QA-group_5_HTTPS
loadbalance vip inservice
loadbalance policy QA-group_5_REDIRECT
loadbalance vip icmp-reply
class QA-group_5_HTTP
loadbalance vip inservice
loadbalance policy QA-group_5_REDIRECT
interface vlan 25
ip address 10.37.5.98 255.255.255.0
access-group input everyone
service-policy input remote-access
service-policy input SERVICE_VIPS
no shutdown
ip route 0.0.0.0 0.0.0.0 10.37.5.1
csc# show service-policy SERVICE_VIPS
Status : ACTIVE
Interface: vlan 25
service-policy: SERVICE_VIPS
class: QA-group_1_HTTPS
loadbalance:
L7 loadbalance policy: QA-group_1_REDIRECT
VIP Route Metric : 77
VIP Route Advertise : DISABLED
VIP ICMP Reply : ENABLED
VIP state: OUTOFSERVICE
VIP DWS state: DWS_DISABLED
Persistence Rebalance: DISABLED
curr conns : 0 , hit count : 122
dropped conns : 122
conns per second : 0
client pkt count : 122 , client byte count: 6164
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
compression:
bytes_in : 0 bytes_out : 0
Compression ratio : 0.00%
Gzip: 0 Deflate: 0
compression errors:
User-Agent : 0 Accept-Encoding : 0
Content size: 0 Content type : 0
Not HTTP 1.1: 0 HTTP response error: 0
Others : 0
class: QA-group_1_HTTP
loadbalance:
L7 loadbalance policy: QA-group_1_REDIRECT
VIP Route Metric : 77
VIP Route Advertise : DISABLED
VIP ICMP Reply : DISABLED
VIP state: OUTOFSERVICE
VIP DWS state: DWS_DISABLED
Persistence Rebalance: DISABLED
curr conns : 0 , hit count : 58
dropped conns : 58
conns per second : 0
client pkt count : 58 , client byte count: 3628
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
compression:
bytes_in : 0 bytes_out : 0
Compression ratio : 0.00%
Gzip: 0 Deflate: 0
compression errors:
User-Agent : 0 Accept-Encoding : 0
Content size: 0 Content type : 0
Not HTTP 1.1: 0 HTTP response error: 0
Others : 0
class: QA-group_2_HTTPS
loadbalance:
L7 loadbalance policy: QA-group_2_REDIRECT
VIP Route Metric : 77
VIP Route Advertise : DISABLED
VIP ICMP Reply : ENABLED
VIP State: INSERVICE
VIP DWS state: DWS_DISABLED
Persistence Rebalance: ENABLED
curr conns : 0 , hit count : 13
dropped conns : 0
conns per second : 0
client pkt count : 74 , client byte count: 7648
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
compression:
bytes_in : 0 bytes_out : 0
Compression ratio : 0.00%
Gzip: 0 Deflate: 0
compression errors:
User-Agent : 0 Accept-Encoding : 0
Content size: 0 Content type : 0
Not HTTP 1.1: 0 HTTP response error: 0
Others : 0
class: QA-group_2_HTTP
loadbalance:
L7 loadbalance policy: QA-group_2_REDIRECT
VIP Route Metric : 77
VIP Route Advertise : DISABLED
VIP ICMP Reply : DISABLED
VIP State: INSERVICE
VIP DWS state: DWS_DISABLED
Persistence Rebalance: ENABLED
curr conns : 0 , hit count : 3
dropped conns : 0
conns per second : 0
client pkt count : 12 , client byte count: 1398
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
compression:
bytes_in : 0 bytes_out : 0
Compression ratio : 0.00%
Gzip: 0 Deflate: 0
compression errors:
User-Agent : 0 Accept-Encoding : 0
Content size: 0 Content type : 0
Not HTTP 1.1: 0 HTTP response error: 0
Others : 0
class: QA-group_3_HTTPS
loadbalance:
L7 loadbalance policy: QA-group_3_REDIRECT
VIP Route Metric : 77
VIP Route Advertise : DISABLED
VIP ICMP Reply : ENABLED
VIP State: INSERVICE
VIP DWS state: DWS_DISABLED
Persistence Rebalance: ENABLED
curr conns : 0 , hit count : 34
dropped conns : 0
conns per second : 0
client pkt count : 201 , client byte count: 23495
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
compression:
bytes_in : 0 bytes_out : 0
Compression ratio : 0.00%
Gzip: 0 Deflate: 0
compression errors:
User-Agent : 0 Accept-Encoding : 0
Content size: 0 Content type : 0
Not HTTP 1.1: 0 HTTP response error: 0
Others : 0
class: QA-group_3_HTTP
loadbalance:
L7 loadbalance policy: QA-group_3_REDIRECT
VIP Route Metric : 77
VIP Route Advertise : DISABLED
VIP ICMP Reply : DISABLED
VIP State: INSERVICE
VIP DWS state: DWS_DISABLED
Persistence Rebalance: ENABLED
curr conns : 0 , hit count : 5
dropped conns : 0
conns per second : 0
client pkt count : 20 , client byte count: 1907
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
compression:
bytes_in : 0 bytes_out : 0
Compression ratio : 0.00%
Gzip: 0 Deflate: 0
compression errors:
User-Agent : 0 Accept-Encoding : 0
Content size: 0 Content type : 0
Not HTTP 1.1: 0 HTTP response error: 0
Others : 0
class: QA-group_4_HTTPS
loadbalance:
L7 loadbalance policy: QA-group_4_REDIRECT
VIP Route Metric : 77
VIP Route Advertise : DISABLED
VIP ICMP Reply : ENABLED
VIP State: INSERVICE
VIP DWS state: DWS_DISABLED
Persistence Rebalance: ENABLED
curr conns : 0 , hit count : 0
dropped conns : 0
conns per second : 0
client pkt count : 0 , client byte count: 0
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
compression:
bytes_in : 0 bytes_out : 0
Compression ratio : 0.00%
Gzip: 0 Deflate: 0
compression errors:
User-Agent : 0 Accept-Encoding : 0
Content size: 0 Content type : 0
Not HTTP 1.1: 0 HTTP response error: 0
Others : 0
class: QA-group_4_HTTP
loadbalance:
L7 loadbalance policy: QA-group_4_REDIRECT
VIP Route Metric : 77
VIP Route Advertise : DISABLED
VIP ICMP Reply : DISABLED
VIP State: INSERVICE
VIP DWS state: DWS_DISABLED
Persistence Rebalance: ENABLED
curr conns : 0 , hit count : 2
dropped conns : 0
conns per second : 0
client pkt count : 8 , client byte count: 697
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
compression:
bytes_in : 0 bytes_out : 0
Compression ratio : 0.00%
Gzip: 0 Deflate: 0
compression errors:
User-Agent : 0 Accept-Encoding : 0
Content size: 0 Content type : 0
Not HTTP 1.1: 0 HTTP response error: 0
Others : 0
class: QA-group_5_HTTPS
loadbalance:
L7 loadbalance policy: QA-group_5_REDIRECT
VIP Route Metric : 77
VIP Route Advertise : DISABLED
VIP ICMP Reply : ENABLED
VIP State: INSERVICE
VIP DWS state: DWS_DISABLED
Persistence Rebalance: ENABLED
curr conns : 0 , hit count : 0
dropped conns : 0
conns per second : 0
client pkt count : 0 , client byte count: 0
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
compression:
bytes_in : 0 bytes_out : 0
Compression ratio : 0.00%
Gzip: 0 Deflate: 0
compression errors:
User-Agent : 0 Accept-Encoding : 0
Content size: 0 Content type : 0
Not HTTP 1.1: 0 HTTP response error: 0
Others : 0
class: QA-group_5_HTTP
loadbalance:
L7 loadbalance policy: QA-group_5_REDIRECT
VIP Route Metric : 77
VIP Route Advertise : DISABLED
VIP ICMP Reply : DISABLED
VIP State: INSERVICE
VIP DWS state: DWS_DISABLED
Persistence Rebalance: ENABLED
curr conns : 0 , hit count : 0
dropped conns : 0
conns per second : 0
client pkt count : 0 , client byte count: 0
server pkt count : 0 , server byte count: 0
conn-rate-limit : 0 , drop-count : 0
bandwidth-rate-limit : 0 , drop-count : 0
compression:
bytes_in : 0 bytes_out : 0
Compression ratio : 0.00%
Gzip: 0 Deflate: 0
compression errors:
User-Agent : 0 Accept-Encoding : 0
Content size: 0 Content type : 0
Not HTTP 1.1: 0 HTTP response error: 0
Others : 0 -
HTTP/HTTPS on the same ACE VIP - best practice
I currently have a VIP representing one server farm that contains two http servers:-
class-map match-all VIP-HTTP-xxxxx.co.uk
2 match virtual-address 10.79.18.10 tcp eq www
class-map match-all VIP-SSL-xxxxx.co.uk
2 match virtual-address 10.79.18.10 tcp eq https
I have port 80 and 443 open on the VIP and SSL termination performed on the ACE (both http servers are the same and configured for default load balancing behaviour - I've also specified port 80 for ACE to server traffic). Having 80 and 443 on the same VIP (meaning the site can be accessed via one NAT'd external IP) came from a request from the business so the site can have one domain.
The majority of the http server(s) web content is standard http but there is a specific sub-directory of interactive forms that requires https termination.
I have a couple of queries with regards to URL re-writes:-
1) Is the SSL URL re-write functionality limited to just the host part of the URL or can the ACE enforce https for specific sub-directories, i.e. can the ACE intercept and re-write a URL if a user tries to go to a particular https page/directory using http (by just deleting the s from the URL within their browser)? A possible example being:-
ssl url rewrite location "www\.cisco\.com\secure-forms"
2) Can the ACE re-direct users back to a standard http page if they try to 'secure' their session by changing http to https within their browser (basically the opposite of the above).
Basically as I have 80 and 443 on the same VIP I'm interested in the best practice methods of enforcing http and https content segregation using just the ACE (as opposed to having Apache doing the re-writes, etc).
Web services functionality (in terms of SSL and URL re-writes) has traditionally fallen within the domain of a dedicated web development team (who use Apache, Tomcat, etc.) but the introduction of the ACE as a load balancing appliance that is primarily managed by the networks team but with functionality that crosses traditional team boundaries has resulted in lots of questions from web development around what functionality can be moved from Apache, etc. and onto the ACE?
Any advice or personal experiences would be gratefully received.
Thanks
MatthewBack again!
Could someone possibly cast their eye over the following config?
The only bit I'm not sure on (syntactically and whether it can even be done on the ACE) is how to specify a DO NOT match regular expression, i.e. how to capture https URLs that do not match my secure pages so I can re-direct the request back to the normal http URL (class-map type http loadbalance Non-Secure_Pages). What I'd like to avoid is re-directing requests that don't need to be, i.e. re-directing all requests that don't match /secure back to http when the majority will be correctly going to a normal http URL :-
rserver host server1
description *** HTTP server 1 ***
ip address 10.100.194.2
inservice
rserver host server2
description *** HTTP server 2 ***
ip address 10.100.194.3
inservice
rserver redirect REDIRECT_TO_HTTPS
webhost-redirection https://www.website.co.uk/%p 302
inservice
rserver redirect REDIRECT_TO_HTTP
webhost-redirection http://www.website.co.uk/%p 302
inservice
class-map type http loadbalance Secure_Pages
match http url /secure.*
class-map type http loadbalance Non-Secure_Pages
*** DO NOT *** match http url /secure.*
class-map match-all VIP-HTTP-website.co.uk
2 match virtual-address 10.79.18.10 tcp eq www
class-map match-all VIP-SSL-website.co.uk
2 match virtual-address 10.79.18.10 tcp eq https
policy-map type loadbalance first-match VIP-LB-HTTP-website.co.uk
class Secure_Pages
serverfarm REDIRECT_TO_HTTPS
class class-default
serverfarm serverfarm-website.co.uk
policy-map type loadbalance first-match VIP-LB-SSL-website.co.uk
class Non-Secure_Pages
serverfarm REDIRECT_TO_HTTP
class class-default
serverfarm serverfarm-website.co.uk
serverfarm host serverfarm-website.co.uk
failaction purge
rserver server1 80
probe PING_SERVER
probe http-website.co.uk
inservice
rserver server2 80
probe PING_SERVER
probe http-website.co.uk
inservice
serverfarm redirect REDIRECT_TO_HTTPS
rserver REDIRECT_TO_HTTPS
inservice
serverfarm redirect REDIRECT_TO_HTTP
rserver REDIRECT_TO_HTTP
inservice
many thanks
Maybe you are looking for
-
I have my mail set to retrieve data manually. When I retrieve mail, I get a popup box for each and every e-mail message asking if I want to view or cancel and must either view or cancel each one before I can use other apps on the ipad. How can I turn
-
How to add digital signature to Form16 in version 4.7?
I need to add a digital signature to the Form 16. i read somewhere that this can be done thru smartforms. can someone please tell me how it can be done?
-
How i can test my files in fp 9.0.0.115?
hi ... how i change the version of my Flash player in adobe flash pro to test my files in FP 9.0.0.115?
-
Canon MG3550 driver for Yosemite
Printer can not be found since updating to Yosemite. Please help.
-
Dear All, I am in process of implementing CHARM and i am facing issue in the process flow for maintenance cycle. In normal changes - we create change request and a maintenance cycle (MC) is attached to it. Once we change the status to Dev with releas