Ask Your Question
0

{RST, ACK} ports 61820 >28130

asked 2020-05-15 14:27:19 +0000

Scotty gravatar image

updated 2020-05-15 15:17:25 +0000

grahamb gravatar image

Hello,

I have a server (pmdvportal) that is attempting to connect every 5 seconds or so to port 28130 on the destination server. The destination server is behind a firewall. We have opened all traffic between the 2.... or so we think we have. According to the tap, I see the below:

Does this look like a possible Firewall issue? Firewall team states all traffic opened, but this tap looks like a Firewall block to an inexperienced Wireshark pup. Any direction would be very helpful!

29  0.087309    10.203.205.210  pmdvportal  UDP 54  58970 → ms-wbt-server(3389) Len=12
34  0.404535    pmdvportal  10.203.205.210  TLSv1.2 105 Application Data
35  0.414060    10.203.205.210  pmdvportal  TCP 54  49744 → ms-wbt-server(3389) [ACK] Seq=1 Ack=52 Win=62965 Len=0
107 1.420160    pmdvportal  10.203.205.210  TLSv1.2 105 Application Data
108 1.429832    10.203.205.210  pmdvportal  TCP 54  49744 → ms-wbt-server(3389) [ACK] Seq=1 Ack=103 Win=62914 Len=0
152 2.435784    pmdvportal  10.203.205.210  TLSv1.2 105 Application Data
153 2.446383    10.203.205.210  pmdvportal  TCP 54  49744 → ms-wbt-server(3389) [ACK] Seq=1 Ack=154 Win=62863 Len=0
188 3.451392    pmdvportal  10.203.205.210  TLSv1.2 105 Application Data
189 3.462132    10.203.205.210  pmdvportal  TCP 54  49744 → ms-wbt-server(3389) [ACK] Seq=1 Ack=205 Win=62812 Len=0
216 4.467042    pmdvportal  10.203.205.210  TLSv1.2 105 Application Data
217 4.477283    10.203.205.210  pmdvportal  TCP 54  49744 → ms-wbt-server(3389) [ACK] Seq=1 Ack=256 Win=64240 Len=0
241 5.094947    pmdvportal  10.203.205.210  TCP 62  61773 → 28130 [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1
242 5.094985    10.203.205.210  pmdvportal  TCP 62  28130 → 61773 [SYN, ACK, ECN] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 SACK_PERM=1
243 5.095196    pmdvportal  10.203.205.210  TCP 60  61773 → 28130 [ACK] Seq=1 Ack=1 Win=64240 Len=0
244 5.095225    pmdvportal  10.203.205.210  TLSv1.2 126 Ignored Unknown Record
245 5.095226    pmdvportal  10.203.205.210  TLSv1.2 75  Ignored Unknown Record
246 5.095236    10.203.205.210  pmdvportal  TCP 54  28130 → 61773 [ACK] Seq=1 Ack=94 Win=64240 Len=0
247 5.095436    10.203.205.210  pmdvportal  TCP 55  [TCP segment of a reassembled PDU]
248 5.095757    pmdvportal  10.203.205.210  TLSv1.2 230 Client Hello
249 5.097430    10.203.205.210  pmdvportal  TLSv1.2 1277    Server Hello, Certificate, Server Key Exchange, Server Hello Done
250 5.098518    pmdvportal  10.203.205.210  TLSv1.2 147 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
251 5.099144    10.203.205.210  pmdvportal  TLSv1.2 105 Change Cipher Spec, Encrypted Handshake Message
252 5.102626    pmdvportal  10.203.205.210  TLSv1.2 84  Application Data
253 5.102685    10 ...
(more)
edit retag flag offensive close merge delete

Comments

Can you provide a capture of this to make it easier to dig into the packet details?
Have you looked at capturing the SSL keys to decode and check what the application is doing?

Chuckc gravatar imageChuckc ( 2020-05-15 15:20:17 +0000 )edit

Your server pmdvportal is ending the TLS connection by sending a reset. That points more to an TLS or application issue. Due the fact that the connection is established, the needed port is open in the firewall.

But maybe another port is needed for a full conversation. Its difficult to say without a full capture. Please provide a full capture of both servers for further analyze.

JasMan gravatar imageJasMan ( 2020-05-15 15:22:32 +0000 )edit

1 Answer

Sort by » oldest newest most voted
0

answered 2020-05-15 15:22:31 +0000

grahamb gravatar image

I seem to have two streams there, one is from 10.203.205.210 to pmdvportal and looks like RDP traffic and probably isn't off interest.

The other is a TLS connection from pmdvportal to 10.203.205.210 which is accepted, the TLS handshake completes, application data is exchanged and then the client (pmdvportal) closes the connection with a RST. No real evidence of a firewall although as the capture seems to have been taken at the 10.203.205.210 side there might be an intervening proxy that sent the RST.

Repeat the capture on pmdvportal and if it is sending the RST, then it's an application issue. If it's not, then you have an intervening device.

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

1 follower

Stats

Asked: 2020-05-15 14:27:19 +0000

Seen: 231 times

Last updated: May 15 '20