Ask Your Question
0

Why there is port mismatch in tcp and http header for port 51006. Also why the netstat in server do not shows connections under port 51006 even traffic is coming to this port.

asked 2017-10-31 07:06:11 +0000

this post is marked as community wiki

This post is a wiki. Anyone with karma >750 is welcome to improve it.

10.5.220.26 is a LOAD Balancer. And as per usual practice we get our server 10.5.207.199 added under LB ip 10.5.220.26 under port 51006 and 44006. It is observed that traffic is coming from source ip 10.5.220.26 and destination port is 44006 in tcp header. But there is a entry in http header showing Host:10.5.220.26:51006 which means 10.5.220.26 is talking to 10.5.207.199 at port 51006. So why the source port in tcp packet is displayed as 44006. Also in my server when i do netstat and try to see connections with port 51006 i cannot see any connections. For source ip 10.5.220.26 and destination port 44006 in tcp header there is entry Host:10.5.220.26:44006 in http header which is fine as it means destination port is 44006 and same is displayed in http header. When my server 10.5.207.199 is added under port 44006 the connections are say X in netstat and when i get it added under 51006 also the number of connnection in netstat under 44006 gets increased to X Y. But no connection is shown under port 51006. Why? Tcpdump rar file link https://drive.google.com/file/d/0B3Vn...

edit retag flag offensive close merge delete

Comments

Post your capture file on a public sharing site, e.g. [Cloudshark](https://cloudshark.org), Google Drive, DropBox etc.

grahamb gravatar imagegrahamb ( 2017-10-31 08:39:33 +0000 )edit

I tried uploading it on cloudshark. size was more so i zipped it but then after uploading it does not reccognize rar file. So now i have uploaded on google drive. Here is the link --> https://drive.google.com/file/d/0B3VnP3xmwL5pUEJiTG9XUWtVNk9IM1Z4SWtnblZRd3Fadktn/view?usp=sharing Please check.

harpreet gravatar imageharpreet ( 2017-10-31 13:04:30 +0000 )edit

Wireshark just decodes and presents in human-readable form what it has found in the data. So when looking e.g. at packet 65, you can see also in its hex dump that the TCP source port (two bytes at offset 0x24 of the frame) is 56817 (=0xddf1) and that the http Host header contains ":51006".

sindy gravatar imagesindy ( 2017-10-31 13:19:45 +0000 )edit

So none of the two values is made up by Wireshark. Therefore, you cannot see any connections from port 51006 of the LB as it really establishes them from 56817. Unfortunately, Wireshark can not tell you **why** this happens, only **that** this happens.

sindy gravatar imagesindy ( 2017-10-31 13:22:46 +0000 )edit

My query is why there is destination port mismatch in tcp and http header. It is observed that traffic is coming from source ip 10.5.220.26 and destination port is 44006 in tcp header. But there is a entry in http header showing Host:10.5.220.26:51006 which means 10.5.220.26 is talking to 10.5.207.199 at port 51006.

harpreet gravatar imageharpreet ( 2017-10-31 13:27:22 +0000 )edit

my system is making connecition to LB with system port 51006 and Lb port 56817. then on doing netstat why no connection is shown with 51006? is there something like port hidden policy becuse as i mentioned the connections in port 44006 increases after adding server under LB port 51006. but no connection are shown under 51006.

harpreet gravatar imageharpreet ( 2017-10-31 13:31:05 +0000 )edit

Your capture seems to come from between the load balancer and the actual server (no other traffic than between those two, except ARP and NBNS). So it is not possible to say anything else than that the LB has established the connection from 56817 towards 44006 at the actual server and probably forwarded the HTTP payload unmodified, resulting in mismatch between L2 and L7 information.

To find out more about what's actually going on, you have to capture simultaneously at the same place you did before and between the actual client and the LB's interface facing the client.

sindy gravatar imagesindy ( 2017-10-31 13:48:39 +0000 )edit

The trace is captured at actual server i.e. 10.5.207.199 which makes connection with LB. It seems LB is receiving http payload from its source at port 51006 and it sends this to actual server 10.5.207.199 at port 44006 with http payload unmodified (hence 51006 in http header).

harpreet gravatar imageharpreet ( 2017-10-31 13:57:57 +0000 )edit

That sounds quite logical, except that I'm now lost in what is your actual question :-) At which of the three machines do you run the netstat which "does not show connections at 51006"?

sindy gravatar imagesindy ( 2017-10-31 14:12:12 +0000 )edit

I run netstat in 10.5.207.199 actual server which receives traffic from LB. LB has two ports 44006 and 51006. sometimes we get our actual server added in 44006 and sometimes under 51006 and sometimes under both. so when my actual server is added under 51006 i do not see connections under 51006 in actual server 10.5.207.199. I think this happens because 51006 is LB port on which LB is receiving traffic from its source which it then sends to actual server 10.5.207.199 with http payload unmodified. i see connections only under 44006 in actual server 10.5.207.199 which get increases once 10.5.207.199 is also added under LB port 51006. my acttual server port is 44006 only.

harpreet gravatar imageharpreet ( 2017-10-31 14:33:10 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2018-07-30 00:05:34 +0000

wesmorgan1 gravatar image

updated 2018-07-30 00:10:41 +0000

Remember that the Host header is inserted by the CLIENT, so it reflects the server/port the client is attempting to reach.

Most load balancers CAN modify the Host header, but they must usually be configured to do so.

At first glance, your description suggests that the load balancer is accepting conversations on tcp/44006 and tcp/51006, and is NOT modifying the Host header...but only forwarding them to tcp/44006 on the destination system.

So, the conflict you see occurs because the (unmodified Host) header from the original request doesn't reflect the action(s) of the load balancer.

I think you need to talk with your load balancer team and review its configuration for your service. You probably need a load balancer rule that basically says, "forward this conversation to the destination on the port specified in the Host header." That rule can be probably be implemented without modifying the Host header...and you don't want to add work to that device unless absolutely necessary.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2017-10-31 07:06:11 +0000

Seen: 10,204 times

Last updated: Jul 30 '18