TCP/IP to Https
I was asked to write a program to receive something in the protocol of TCP/IP and output it in the protocol of https.
How should I start my program? need some suggestion, p.s. I am a noob
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
-
Why does TCP tunneling remove http 503 response from async WS call?
Hi all,
I am facing a bit of a weird problem.
I have developed and tested an asynchronous BPEL process which among other things invokes a 3rd party web service.
It works fine in development environment.
When I migrate to the customers test environment I get a http 503 error back to the BPEL process (only difference in the BPEL code is the endpoint to the WS).
Trying to figure out what went wrong I used a TCP monitor to tunnel through. This solved the problem!
So why does going through a TCP monitor running on the BPEL server help?
Continuing with the TCP monitor in production is obviously not an option, so not only do I need to figure out why using a TCP mon helps, but also figure out how to fix the underlying issue.
I should mention that I am using BPEL version 10.1.3.3, and that I have testet the connection between the BPEL server and the 3rd party web service and found no problem.
Any help is much appreciated.
Regards,
Aagaard
Edited by: Aagaard on Mar 23, 2009 9:48 AM
In Metalink in "TCP Tunneling the Oracle BPEL Process Manager" (document id 283484.1) it is suggested to change the "opt-soap-shortcut" property in the "Manage BPEL domian" from false to true if you want to use TCP tunneling.
I don't see this property in the BPEL console or in the domain.xml file found at $ORACLE_HOME/bpel/domains/<domain used>/config.
Could this be part of the problem?
The BPEL server in the customers test environment is a clone of the BPEL server in our development environment, so I don't see how this could be the problem.Hi,
Status update: Accessing the remote web service from the BPEL server works fine if not done through BPEL.
My current thinking is that the problem may be linked to port numbers and firewalls. Obviously, there is an opening in the firewall from my BPEL servers (installed on port 8888) and to the remote web service running on port 19313.
However, sniffing at the connection between BPEL and the TCPMon it can be seen that BPEL is trying to make a connection in a range of ports in the 1400s (so far I have seen between 1454 and 1481).
In the Oracle documentation at [http://download.oracle.com/docs/cd/B31017_01/core.1013/b28940/portnums.htm] there is a list of default ports.
The 1400 range does not appear anywhere.
So my thinking is that maybe the TCPMon goes through a static port, which is opened in the firewall, and BPEL is trying to go through a dynamic range which can get to the TCPMon but not to the remote service.
Any comments, ideas or suggestions is most welcome.
Regards,
Aagaard
PS: James - Thank you for the assistance. As always it was very helpful.
Edited by: Aagaard on Mar 26, 2009 8:45 AM
The 1400 range may have to do with wireshark sniffer tool ...
So that might explain it. -
Tcp redirect and https response verification
Can CSS redirect ip based tcp traffic (in addition to http/https ) to a remote server when the local server is down (active/standby) - there is no DNS involed in the process?
Can CSS (with SCA) check the https return string to determin the server status?
Thanks.A service created with 'type redirect' and the 'redirect-string' might help you. If you apply this service to a Layer 5 rule the CSS will only send traffic to that service if all other local-services are down, assuming you have added more than 1 service to the content rule..
The CSS should be able to dns resolve inorder to have the redirected traffic hits the destination sorry server. -
Which tcp port the http service on my application server runs on
Hi,
Please could you help? If the url for my web application doesn't give the port number that the http service is running on, how can I find out. I know it is not running on the default 80 or 8080 because I have it from another source but don't know how to find it out myself from the application.
thank youMight be 1156
So something like this might work :
http://yourserver.name.com:1156
You can replace 1156 with 7777 or 7778 and the default iAS might pop up. -
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 -
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 -
Reading the binary data from a http request received via socket connection.
1. I require to extract the binary data out of a http multipart request,
2. I have a server socket opened up, which can receive connections over tcp( and therefore http.)
3. I will require to read the stream, find out the "request boundary identifier", and then extract the different "request body parts".
4. From there i need to read all of the binary content and put it in a file.
5. I did some implementation to his effect. but i see that the file that i had uploaded initially if its not a text file, gets corrupted.
can you please let me know why is that happening, and a probable solution approach.
please find below the class (with a main method) I have been using to expose a server socket.
package self.services;
import java.io.BufferedReader;
import java.io.ByteArrayOutputStream;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.PrintWriter;
import java.net.ServerSocket;
import java.net.Socket;
public class FileServer {
public static void main(String[] args) throws Exception {
ServerSocket serverSocket = new ServerSocket(9999);
String FOLDER_NAME = "uploaded_files";
while(true) {
try{
Socket socket = serverSocket.accept();
InputStream is = socket.getInputStream();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
BufferedReader reader = new BufferedReader(new InputStreamReader(is));
String currentLine;
int cnt = 0;
boolean postRequest = false;
String dataBoundary = null;
String fileName = null;
String yourName = null;
while((currentLine = reader.readLine()) != null) {
if(currentLine.contains("POST")) {
postRequest = true;
System.out.println("POST REQ AS EXPECTED VERY NICE");
continue;
if(!postRequest) {
System.out.println("NO POST REQ THIS BREAKING FLOW");
break;
} else {
if(currentLine.contains("Content-Type: multipart/form-data; boundary=")) {
System.out.println("found a boundary value header");
dataBoundary = currentLine.substring((currentLine.indexOf("boundary=") + "boundary=".length()), (currentLine.length() -1));
System.out.println("boundary value = ".concat(dataBoundary));
continue;
if(dataBoundary != null && currentLine.contains(dataBoundary)) {
cnt++;
if(cnt == 1) {
//move 3 lines
if(currentLine.contains("Content-Disposition: form-data; name=\"yourName\"")){
reader.readLine();//skip a line
System.out.println("Your name = ".concat(yourName = reader.readLine()));
continue;
} else if(cnt == 2) {
if(currentLine.contains("Content-Disposition: form-data; name=\"sentFile\"; filename=\"")){
fileName = currentLine.substring(currentLine.indexOf("filename=") + "filename=".length() + 1, currentLine.length() - 1);
System.out.println("File Name = ".concat(fileName));
reader.readLine();//skip a line , this would depict a content type header
reader.readLine();//skip a line, this would indicate a blank line to mark the start of data.
continue;
} else {
// write the content to os
if(currentLine != null && !currentLine.contains(dataBoundary)) {
baos.write(currentLine.concat("\r").getBytes());
} else if( cnt == 3) {
System.out.println(("cnt [" + cnt).concat( "], current line [").concat(currentLine).concat("]"));
break;
if(fileName == null ||yourName == null) {
System.out.println("FileServer.main() dont bother about this" );
} else {
//send a response back
PrintWriter pw = new PrintWriter(new OutputStreamWriter(socket.getOutputStream()));
pw.write(responseMessage(yourName, fileName));
pw.flush();
//close output stream
pw.close();
//handle the request bytearray.
FileOutputStream fos = new FileOutputStream(FOLDER_NAME + "/" + fileName);
fos.write(baos.toByteArray(), 0, baos.toByteArray().length - 1);
fos.close();
//close input stream
reader.close();
socket.close();
baos.close();
} catch(Exception ex) {
ex.printStackTrace();
public static String responseMessage(String yourName, String fileName) {
String response =
"<HTML>" .concat(
"<BODY>") .concat(
"<P>" ).concat(
"Mr. <FONT color=\"red\">") .concat( yourName).concat("</FONT>. Your file named <B>").concat( fileName).concat( "</B> successfully reached us." ).concat(
"</P>") .concat(
"</BODY>").concat(
"</HTML>");
return response;
}{code}
Here is a sample html file which can be used to send multipart requests to the java service.
<html>
<body>
<form action="http://localhost:9999" enctype="multipart/form-data" method="POST">
Enter name :<br/>
<input type="text" name="yourName"/>
Enter file :<br/>
<input type="file" name="sentFile"/>
<br/>
<input type="submit" value="Submit"/>
</form>
</body>
</html>
*Both the form elements are mandatory*
*I hope my requirement is clear. Any help regarding this will be highly appreciated.*
Regards.MishraC wrote:
1. I require to extract the binary data out of a http multipart request,
2. I have a server socket opened up, which can receive connections over tcp( and therefore http.)
3. I will require to read the stream, find out the "request boundary identifier", and then extract the different "request body parts".
4. From there i need to read all of the binary content and put it in a file.
5. I did some implementation to his effect. but
i see that the file that i had uploaded initially if its not a text file, gets corrupted.
can you please let me know why is that happening,Because you are using a Reader (which translates bytes to chars according to the charset encoding specified).
and a probable solution approach. Use a BufferedInputStream. -
Unable to use HTTPS proxy when redirecting HTTP/HTTPS via NAT
I'm trying to get the WSA to work when redirecting HTTP and HTTPS traffic along the lines of the following:
object network WSA-HOST
host 10.0.210.2
object network obj-10.0.1.0 subnet 10.0.1.0 255.255.255.0
object service ORIG-HTTP-PORT
service tcp destination eq www
object service WSA-HTTP-DEST-PORT
service tcp destination eq 8080
object service ORIG-HTTPS-PORT
service tcp destination eq https
object service WSA-HTTPS-DEST-PORT
service tcp destination eq https << also tried 8080 etc.
nat (inside,outside) source dynamic obj-10.0.1.0 interface destination static obj_any WSA-HOST service ORIG-HTTP-PORT WSA-HTTP-DEST-PORT
nat (inside,outside) source dynamic obj-10.0.1.0 interface destination static obj_any WSA-PROXY-HOST service ORIG-HTTPS-PORT WSA-HTTPS-DEST-PORT
This works just fine for HTTP, but with HTTPS I get the following response from the Ironport WSA:
Based on your corporate access policies, access to this web site ( https://www.rbsdigital.com/ ) has been blocked.
Notification codes: (1, POLICY, UNKNOWN, 0x00000082, 1329750248.609, QAAAAAAAAAAAAAAAyf8AAP8AAAD/AAAAAAAAAAAAAAE=,
https://www.rbsdigital.com/)
The access log gives me the following:
1329750248.602 404 10.0.4.140 NONE_SSL/200 0 TCP_CONNECT 10.0.210.2:443 - NONE/- - OTHER-NONE-NONE-NONE-NONE-NONE-NONE <-,-,"-","-",-,-,-,"-","-",-,-,-,"-","-",-,"-","-",-,-,-,-,"-","-","-","-","-","-",0.00,0,[Local],"-","-"> -
1329750248.609 0 10.0.4.140 TCP_DENIED_SSL/403 1840 GET https://www.rbsdigital.com:443/ - NONE/- - BLOCK_ADMIN-HTTPS-NonLocalDestination-NONE-NONE-NONE-NONE-NONE-NONE <-,-,"-","-",-,-,-,"-","-",-,-,-,"-","-",-,"-","-",-,-,-,-,"-","-","-","-","-","-",0.00,0,[Local],"-","-"> -
If anyone has any idea why the WSA simply denies the connection instead of proxying it then I'd be grateful.
The WSA and the decryption policies work fine in explisit mode.
Thanks in advance!The policy doesn't require authentication. Now here are two tests I did, seconds apart, from the same client on 10.0.4.140:
First one is where I use NAT as shown above:
1329757052.027 118 10.0.4.140 NONE_SSL/200 0 TCP_CONNECT 10.0.210.2:443 - NONE/- - OTHER-NONE-NONE-NONE-NONE-NONE-NONE <-,-,"-","-",-,-,-,"-","-",-,-,-,"-","-",-,"-","-",-,-,-,-,"-","-","-","-","-","-",0.00,0,[Local],"-","-"> -
1329757052.311 0 10.0.4.140 TCP_DENIED_SSL/403 1840 GET https://www.rbsdigital.com:443/ - NONE/- - BLOCK_ADMIN-HTTPS-NonLocalDestination-NONE-NONE-NONE-NONE-NONE-NONE <-,-,"-","-",-,-,-,"-","-",-,-,-,"-","-",-,"-","-",-,-,-,-,"-","-","-","-","-","-",0.00,0,[Local],"-","-"> -
Second test case is when I reconfigured the browser to explisitely use the WSA as a proxy on port 8080:
1329757138.274 344 10.0.4.140 TCP_CLIENT_REFRESH_MISS_SSL/200 39 CONNECT tunnel://www.rbsdigital.com:443/ - DIRECT/www.rbsdigital.com - DECRYPT_WBRS_7-DefaultGroup-UK_Office-NONE-NONE-NONE-DefaultGroup -
1329757138.566 200 10.0.4.140 TCP_CLIENT_REFRESH_MISS_SSL/200 39 CONNECT tunnel://www.rbsdigital.com:443/ - DIRECT/www.rbsdigital.com - DECRYPT_WBRS_7-DefaultGroup-UK_Office-NONE-NONE-NONE-DefaultGroup -
Non-categorised stuff should be passed through:
Global Policy
Identity: All
Pass Through: 1
Monitor: 65
Disabled
Pass Through
Any thoughts ? -
Best HTTP load balancing method
This is probably basic, but how satisfactory is this http load balancing method:
service http-1
ip address 192.168.1.10
protocol tcp
port 80
keepalive type tcp
active
service http-2
ip address 192.168.1.9
protocol tcp
port 80
keepalive type tcp
active
owner http
content web-domains
vip address 10.0.0.1
add service http-1
add service http-2
protocol tcp
port 80
balance leastconn
active
Should I rather use sticky-mask 255.255.255.255 or advanced-balance sticky-srcip?It really depends what you are doing.
Some people will find this acceptable and for others it will just not work.
Do you need persistency ?
To answer this question check with your webserver admin.
does this website have a shopping basket ?
Finally, changing the sticky-mask is useless if you do not have sticky-srcip. So your question should be ..or .. but .. and ..
Anyway, it all depends what is required for your website to work.
You can try this config and if you run into problem capture a sniffer trace and identify the problem to see if a configuration change is needed.
Regards,
Gilles. -
Hello all,
I have an ACE 4700 and It is balancing a web aplication using tcp ports 80 (http) and 443 (https). The configuration of ACE is in One-Arm, it means that the ACE does a NAT to client IP source address.
For requeriment legal the web aplication must to show the client IP source address in the web site, but with configurationin One-Arm only shows the IP address ACE.
Whit the next configuration I can insert into the http packet the client IP source address
policy-map type loadbalance first-match L7_LB_POLICY_SURA.COM.CO
class class-default
serverfarm sura.com.co
insert-http X-Forwarded-For header-value "%is"
but that don´t work with HTTPS (443)
How do I do in HTTPS?
If I buy this licenses, Can I do this?
ACE-AP-SSL-05K-K9
ACE-AP-SSL-07K-K9
ACE-AP-SSL-100-K9
ACE-AP-SSL-UP1-K9
ACE-AP-SSLUP-5K-K9
Thanks.
Haiver BermonHi,
you don't need to buy any license.
By default the ACE can do SSL Offload (1000 Transactions per Second). This means that the HTTS session is terminated at the ACE (and no longer at the server).
Take a look at following example on how to configure ssl offload:
http://www.cisco.com/en/US/products/hw/modules/ps2706/products_configuration_example09186a00809c3045.shtml
HTH,
Dario -
Shared public IP with same tcp port (round robin/load balance)
Hi all,
I want to know if I can do that with my ASA5515-X, I have two servers that can do the same thing, there are SSO servers, What I want to do is to publish the 2 servers on Internet with the same public IP address and on TCP 443.
Is it supported ? will it works like load balancing per sessions ?
or do I need to add an HLB between ASA and my SSO servers ?
ThanksHi Yann,
You can configure the ASA to allow traffic to your SSO server from outside on two public IP's. Users can hit either of the IP to reach the inside server. Now, load balancing would be achieved based on source devices sending request to public IP's. If source machine son internet use one public IP more to access the server, ASA can't do anything to load balance in such scenario. Here is how you can accomplish this:
Assuming SSO server on inside is 192.168.16.110 and two public IP's are 192.168.17.110 and 192.168.17.111
object network SSO_1
host 192.168.17.110
object network SSO_2
host 192.168.17.111
object network SSO
host 192.168.16.110
object service https
service tcp source eq https
nat (inside,outside) source static SSO SSO_1 service https https
nat (inside,outside) source static SSO SSO_2 service https https
Hostname(config)# sh xl
2 in use, 6 most used
Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice
TCP PAT from inside:192.168.16.110 443-443 to outside:192.168.17.110 443-443
flags sr idle 0:00:06 timeout 0:00:00
TCP PAT from inside:192.168.16.110 443-443 to outside:192.168.17.111 443-443
flags sr idle 0:00:08 timeout 0:00:00
Verification:
Hostname(config)# packet-tracer input outside tcp 4.4.4.4 discard 192.168.17.110 443
Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static SSO SSO_1 service https https
Additional Information:
NAT divert to egress interface inside
Untranslate 192.168.17.110/443 to 192.168.16.110/443
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside in interface outside
access-list outside extended permit ip any any
Additional Information:
Phase: 3
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source static SSO SSO_1 service https https
Additional Information:
Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 3670, packet dispatched to next module
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hostname(config)# packet-tracer input outside tcp 4.4.4.4 discard 192.168.17.111 443
Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static SSO SSO_2 service https https
Additional Information:
NAT divert to egress interface inside
Untranslate 192.168.17.111/443 to 192.168.16.110/443
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside in interface outside
access-list outside extended permit ip any any
Additional Information:
Phase: 3
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source static SSO SSO_1 service https https
Additional Information:
Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 3671, packet dispatched to next module
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
Sourav -
We are currently using TCP probe for HTTPS webServer health checking. Is there a HTTPS or SSL probe available on CSM to send a url to detect if the HTTPS Apache WebServer is up or not?
Many Thx, Q.XieYou can download the TCL script file from the same locstion as the CSM software.
In this TCL file you should find the following scripts
[root@linux-1 cisco]# cat /tftpboot/c6slb-apc.4-2-1.tcl | grep -i "name ="
#!name = CHECKPORT_STD_SCRIPT
#!name = ECHO_PROBE_SCRIPT
#!name = FINGER_PROBE_SCRIPT
#!name = FTP_PROBE_SCRIPT
#!name = HTTPCONTENT_PROBE
#!name = HTTPHEADER_PROBE
#!name = HTTPPROXY_PROBE
#!name = HTTP_PROBE_SCRIPT
#!name = IMAP_PROBE
#!name = LDAP_PROBE
#!name = MAIL_PROBE
#!name = POP3_PROBE
#!name = PROBENOTICE_PROBE
#!name = RTSP_PROBE
#!name = SSL_PROBE_SCRIPT
#!name = TFTP_PROBE
There is a SSL_PROBE_SCRIPT that will verify that the SSL server respond to a client SSL HELLO message.
It does not verify if you can send an HTTP request.
It only sends a HELLO as a client and wait for the server HELLO.
With the SSLM for the CSM, there might be a way to achieve HTTPS probe.
I never tried it, but the solution I see would be to create an HTTP probe on the CSM and direct to the SSLM which will do the encryption and forward it to the server.
Regards,
Gilles -
Problems with https web pages and my iptables scripts
[root@Arch root]# iptables -A INPUT -p tcp -i eth0 --sport https -j ACCEPT
iptables v1.2.10: invalid TCP port/service `https' specified
Try `iptables -h' or 'iptables --help' for more information.
Why?
In others distro it works perfectly ...the iptables comparison is performed on the packet itself, and its contents. If you sniffed the packet, you would see that the source for the packet is the machine of the person requesting the website, and the destination of the packet would be your server.
Since the packet is allowed in the the rule, it gets to the box. The outgoing return data is either allowed by default (some people let anything out, but only filter incoming) or allowed via connection tracking (since it is part of a message that was allowed in, it gets allowed out).
You can do a man iptables to find all kinds of other info, and searching google helps too. Best thing of all to do is just fire up a packet sniffer and watch...
8) -
Tcp Reset question - IPS Sensor 4255
I have this sensor doing tcp resets, the question I have is if I add a network to the "never block addresses" will the sensor still send tcp resets even though the network is in the never block? if so how do I tell the sensor to not block certain ip addresses..
Thanks in advance
PhilYou can configure sensors to send TCP reset packets to try to reset a network connection between an attacker host and its intended target host. In some installations when the interface is operating in promiscuous mode, the sensor may not be able to send the TCP reset packets over the same sensing interface on which the attack was detected. In such cases, you can associate the sensing interface with an alternate TCP reset interface and any TCP resets that would otherwise be sent on the sensing interface when it is operating in promiscuous mode, are instead sent out on the associated alternate TCP reset interface.
http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_installation_guide_chapter09186a008055fc77.html -
I have been trying to set up my wireless network for a couple of days now. My router is a WRT54GS and the problem I am having is on my desktop with the wireless adapter. I can connect to the network and can ping the router with no problem. It is when I try to connect to the internet I keep getting the cannot find page error. Tech support says I need to check my tcp/ip stacks and my DNS address. Does anyone know how to refresh the tcp/ip stacks on Windows ME and how to resolve the DNS issue.
Thanks Jabepls visit this one... this will tell you how to refresh your TCP/IP stacking
http://support.microsoft.com/kb/299357
"a helping hand in a community makes the world a universe"
Maybe you are looking for
-
I can't login to the App Store - connection failed...
yesterday I had totally forgot my password and security question & went through 'Apple Express Lane' in getting assistance to reset my password for my ID "[email protected]" account so I can update to Lion OSX & merge my MobileMe account to iCloud through
-
[SOLVED] Problem configuring DisplayLink monitor (udlfb...)
SOLVED: It seems that my monitor shows no green screen when it is ready. Instead it shows the last image rendered. In my case it was this color stripes. Also, I upgraded to kernel 3.2.1-2, and using the include module udlfb and xf86-video-fbdev from
-
D110a loss of communication on 1 computer in a network
I have a home network with 2 destops and a laptop. There is one desktop that doesn't work all the time with the printer. I've unistalled and reinstalled the software several times but nothing seems to work. Yesterday I did that process again. I got
-
Ibought adobe photoshop cs5 exended will this work on my new iMac operating system mac osx.10.9.13a1
Hello i,m new with mac. I bought adobe photoshop cs5 exended will this work on my new iMac operating system mac osx.10.9.13a1900
-
Ichat quits when trying to use video - only since updating to 10.4.5
G4 dual 1Ghz mirrored door Mac OS X (10.4.5) I've been using the video chat feature of ichat for a while now with no problems (other than sometimes I need to have my buddy request the chat for it to work) but now since updating my software to 10.