I created a virtual ubuntu machine in oracle cloud. Then I install nginx webserver. I adjust the incoming and outcoming firewalls rules so that port 80 is accesible.
When I run curl server IP I can see the website from one location but not from the other. To further analyze the situation I installed Tshark (wireshark) and checked the packets. Here is the results from two locations. The first is the problematic IP and the second is where it works.
Can any one guess what could potentially be the issue? Or if this is not enough what else can I do to understand what is the issue?
<<>>
curl 140.238.17x.xxx
curl: (56) Recv failure: Connection was reset
ubuntu#instance-20220807-1212:~$ sudo tshark -f "(src net 109.122.24x.xxx or dst net 109.122.24x.xxx) and (udp port 53 or tcp port 80 or tcp port 443)"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'enp0s3'
> ** (tshark:12233) 13:06:37.612630 [Main MESSAGE] -- Capture started. ** (tshark:12233) 13:06:37.614325 [Main MESSAGE] -- File: "/tmp/wireshark_enp0s3A0AVQ1.pcapng"
> 1 0.000000000 109.122.24x.xxx → 10.0.0.163 TCP 66 61809 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
> 2 0.000061961 10.0.0.163 → 109.122.24x.xxx TCP 66 80 → 61809 [SYN, ACK] Seq=0 Ack=1 Win=62720 Len=0 MSS=8960 SACK_PERM=1 WS=128
> 3 0.120269794 109.122.24x.xxx → 10.0.0.163 TCP 56 61809 → 80 [ACK] Seq=1 Ack=1 Win=1203712 Len=0
> 4 0.132157417 109.122.24x.xxx → 10.0.0.163 HTTP 132 GET / HTTP/1.1
> 5 0.132186937 10.0.0.163 → 109.122.24x.xxx TCP 54 80 → 61809 [ACK] Seq=1 Ack=79 Win=62720 Len=0
> 6 0.132401218 10.0.0.163 → 109.122.24x.xxx HTTP 913 HTTP/1.1 200 OK (text/html)
> 7 0.220395642 109.122.24x.xxx → 10.0.0.163 TCP 56 61809 → 80 [PSH, ACK] Seq=79 Ack=860 Win=125440 Len=0
> 8 0.220395802 109.122.24x.xxx → 10.0.0.163 TCP 56 [TCP Dup ACK 7#1] 61809 → 80 [PSH, ACK] Seq=79 Ack=860 Win=125440 Len=0
MY PC
curl 140.238.17x.xxx
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
nginx.org.<br/>
Commercial support is available at
nginx.com.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
ubuntu#instance-20220807-1212:~$ sudo tshark -f "(src net 109.255.15X.XXX or dst net 109.255.15X.XXX) and (udp port 53 or tcp port 80 or tcp port 443)"
> Running as user "root" and group "root". This could be dangerous.
> Capturing on 'enp0s3' ** (tshark:12258) 13:09:11.732226 [Main
> MESSAGE] -- Capture started. ** (tshark:12258) 13:09:11.733476 [Main
> MESSAGE] -- File: "/tmp/wireshark_enp0s3EBUXQ1.pcapng"
> 1 0.000000000 109.255.15X.XXX → 10.0.0.163 TCP 66 57442 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
> 2 0.000064841 10.0.0.163 → 109.255.15X.XXX TCP 66 80 → 57442 [SYN, ACK] Seq=0 Ack=1 Win=62720 Len=0 MSS=8960 SACK_PERM=1 WS=128
> 3 0.043089107 109.255.15X.XXX → 10.0.0.163 TCP 56 57442 → 80 [ACK] Seq=1 Ack=1 Win=131328 Len=0
> 4 0.049215260 109.255.15X.XXX → 10.0.0.163 HTTP 132 GET / HTTP/1.1
> 5 0.049236820 10.0.0.163 → 109.255.15X.XXX TCP 54 80 → 57442 [ACK] Seq=1 Ack=79 Win=62720 Len=0
> 6 0.049434021 10.0.0.163 → 109.255.15X.XXX HTTP 913 HTTP/1.1 200 OK (text/html)
> 7 0.097005351 109.255.15X.XXX → 10.0.0.163 TCP 56 57442 → 80 [FIN, ACK] Seq=79 Ack=860 Win=130304 Len=0
> 8 0.097056872 10.0.0.163 → 109.255.15X.XXX TCP 54 80 → 57442 [FIN, ACK] Seq=860 Ack=80 Win=62720 Len=0
> 9 0.145239245 109.255.15X.XXX → 10.0.0.163 TCP 56 57442 → 80 [ACK] Seq=80 Ack=861 Win=130304 Len=0 ^C9 packets captured
enter image description here
Related
I have two servers with different ips, one is the ip that clients know and the other is private.
all packets directed to the first server gets redirected to the second locally by the network switch.
as you can see in the logs by wireshark there is no http packet arriving from client, all is continuation or non-http:
15 29.352916 172.17.251.32 -> 10.0.0.100 TCP 78 49975 > http [SYN] Seq=0 Win=4380 Len=0 MSS=1398 WS=1 TSval=2098464254 TSecr=0 SACK_PERM=1
16 29.352970 10.0.0.100 -> 172.17.251.32 TCP 74 http > 49975 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=1571906898 TSecr=2098464254 WS=256
17 29.354856 172.17.251.32 -> 10.0.0.100 TCP 66 49975 > http [ACK] Seq=1 Ack=1 Win=4380 Len=0 TSval=2098464257 TSecr=1571906898
18 29.355093 172.17.251.32 -> 10.0.0.100 HTTP 220 Continuation or non-HTTP traffic
19 29.355126 10.0.0.100 -> 172.17.251.32 TCP 66 http > 49975 [ACK] Seq=1 Ack=155 Win=30208 Len=0 TSval=1571906898 TSecr=2098464257
20 29.355231 10.0.0.100 -> 172.17.251.32 HTTP 247 Continuation or non-HTTP traffic
21 29.355291 10.0.0.100 -> 172.17.251.32 TCP 66 http > 49975 [FIN, ACK] Seq=182 Ack=155 Win=30208 Len=0 TSval=1571906898 TSecr=2098464257
22 29.356955 172.17.251.32 -> 10.0.0.100 TCP 66 49975 > http [ACK] Seq=155 Ack=183 Win=4561 Len=0 TSval=2098464259 TSecr=1571906898
23 29.357405 172.17.251.32 -> 10.0.0.100 HTTP 73 Continuation or non-HTTP traffic
24 29.357424 172.17.251.32 -> 10.0.0.100 TCP 66 49975 > http [FIN, ACK] Seq=162 Ack=183 Win=4561 Len=0 TSval=2098464259 TSecr=1571906898
25 29.357434 10.0.0.100 -> 172.17.251.32 TCP 66 http > 49975 [ACK] Seq=183 Ack=163 Win=30208 Len=0 TSval=1571906899 TSecr=2098464259
my guess is that there is a problem with redirection or some firewall problem.
what is the problem?
I wrote a proxy server which support http and https connection, When I use with http all work fine, but when I work with https , wireshark report this error
'Reassembly error, protocol TCP: New fragment overlaps old data (retransmission?)'
Although the browsing work fine but performance is impacted as after this I see TCP RST and because of that SSL negotiation happen again.
Any clue on what could be wrong ?
169.254.119.252 169.254.1.66 TCP 66 54589 > ff-fms [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
169.254.1.66 169.254.119.252 TCP 60 ff-fms > 54589 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1456
169.254.119.252 169.254.1.66 TCP 54 54589 > ff-fms [ACK] Seq=1 Ack=1 Win=65520 Len=0
169.254.119.252 169.254.1.66 TCP 245 [TCP segment of a reassembled PDU]
169.254.1.66 169.254.119.252 TCP 912 [TCP segment of a reassembled PDU]
169.254.119.252 169.254.1.66 TCP 252 54588 > ff-fms [PSH, ACK] Seq=192 Ack=859 Win=64662 Len=198[Reassembly error, protocol TCP: New fragment overlaps old data (retransmission?)]
169.254.1.66 169.254.119.252 TCP 91 [TCP segment of a reassembled PDU]
169.254.119.252 169.254.1.66 TCP 54 54587 > ff-fms [RST, ACK] Seq=391 Ack=955 Win=0 Len=0
When my browser(win7) accesses the xenapp server hosted remotely on windows 2008 R2(which is on a virtualbox virtual machine), tcp handshake could be completed, then my browser sent rst to the server, there is no other msg anymore...
- 153 4.991612000 123.235.17.94 217.63.13.71 TCP 74 sstsys-lm > http [SYN] Seq=4246057259 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1 TSval=2040538 TSecr=0
- 154 4.991986000 217.63.13.71 123.235.17.94 TCP 74 http > sstsys-lm [SYN, ACK] Seq=298571595 Ack=4246057260 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 TSval=590459 TSecr=2040538
- 158 5.024598000 123.235.17.94 217.63.13.71 TCP 66 sstsys-lm > http [ACK] Seq=4246057260 Ack=298571596 Win=66608 Len=0 TSval=2040541 TSecr=590459
- 159 5.025212000 123.235.17.94 217.63.13.71 TCP 60 sstsys-lm > http [RST] Seq=4246057260 Win=65536 Len=0
Please give me an advice about:
How does the [RST] come from and how to avoid it ? Thanks in advance.
I am writing a program that fakes TCP requests and collects the data to store in a local buffer. For this, in the system connected to the client i have configured the iptables to keep all the incoming packets to a queue before routing. Then i use the netfilter library to read the packets from the queue. After this using RAW sockets I send the fake TCP packets to the client. With this I am able to fake the SYN/ACK packet in response to the SYN request from the client.
But issue happens when I try to fake an ACK to the client in response to the incoming data. In this case the real ip of the source comes in the packet and not the faked one. Please see 7th trace below marked with ">>>". In this the source ip is shown as 192.168.10.10 where as it has to be 212.58.246.81. In the 4th trace(i.e. SYN/ACK packet) its showing as fine.
3 0.073852000 192.168.10.100 212.58.246.81 TCP 38307 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=502233100 TSER=0 WS=6
4 0.103102000 212.58.246.81 192.168.10.100 TCP http > 38307 [SYN, ACK] Seq=0 Ack=1 Win=31744 Len=0
5 0.103147000 192.168.10.100 212.58.246.81 TCP 38307 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0
6 0.103349000 192.168.10.100 212.58.246.81 HTTP GET /go/rss/int/news/-/sport2/hi/tennis/9519762.stm HTTP/1.1
>>> 7 1.118729000 192.168.10.10 192.168.10.100 TCP http > 38307 [ACK] Seq=1 Ack=1 Win=31744 Len=0
8 1.118788000 192.168.10.100 192.168.10.10 TCP 38307 > http [RST] Seq=1 Win=0 Len=0
9 3.102627000 192.168.10.100 212.58.246.81 HTTP [TCP Retransmission] GET /go/rss/int/news/-/sport2/hi/tennis/9519762.stm HTTP/1.1
10 3.148590000 192.168.10.10 192.168.10.100 TCP [TCP Dup ACK 7#1] http > 38307 [ACK] Seq=1 Ack=1 Win=31744 Len=0
11 3.148606000 192.168.10.100 192.168.10.10 TCP 38307 > http [RST] Seq=1 Win=0 Len=0
Also I have tried out "sendip" command like below to send a fake TCP ACK
sendip -p ipv4 -p tcp -is 212.58.246.81 -id 192.168.10.100 -ts 80 -td 4567 -tfa 1 -tfs 0 -d "Data" 192.168.10.100
here tfa and tfs stands for ack and syn flags respectively.
This also didnt work as expected and its shown as orginating from 192.168.10.10 instead of 212.58.246.81. But if I set both flags(syn and ack) as 1 then its working fine.
The OS is Ubuntu. Can anyone please let me know where I am going wrong. Thanks a lot for your help.
Is it okay if a machine sets the TCP windowsize to zero after receiving a FIN?
I've got the following packet dump from wireshark of the end of the connection and I'm just wondering if this is a valid way to end a connection or if something is wrong.
192.168.1.1 192.168.1.6 TCP 3450 > 102 [FIN, ACK] Seq=48 Ack=50 Win=65486 Len=0
192.168.1.6 192.168.1.1 TCP [TCP ZeroWindow] 102 > 3450 [ACK] Seq=50 Ack=49 Win=0 Len=0
192.168.1.6 192.168.1.1 TCP 102 > 3450 [FIN, PSH, ACK] Seq=50 Ack=49 Win=0 Len=0
192.168.1.1 192.168.1.6 TCP 3450 > 102 [ACK] Seq=49 Ack=51 Win=65486 Len=0
BTW: .1 is a regular windows PC while .6 is a Siemens PLC. (S7-400)
After some investigation it looks like a weird but valid way to end a TCP conversation.
I see nothing wrong with sending a zero window after a FIN ACK... presumably 192.168.1.6 sent a FIN to 192.168.1.1, so they are now closing the connection.
192.168.1.6 192.168.1.1 TCP [TCP ZeroWindow] 102 > 3450 [ACK] Seq=50 Ack=49 Win=0 Len=0
But immediately setting a PSH flag and sending no data (Len=0) right after that ACK, looks rather odd (but not technically wrong) to me...
192.168.1.6 192.168.1.1 TCP 102 > 3450 [FIN, PSH, ACK] Seq=50 Ack=49 Win=0 Len=0