 | 1 | initial version |
It appears that the Linksys device as a middle-ware NAT box is reframing the postage machine's traffic ultimately suppressing a superfluous trailing byte included at the end of the postage machine's "Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message" packets.
In the non-working capture, these particular packets will appear to have a "VSS Monitoring Ethernet trailer" (when using a Default Wireshark profile, these frames can be selected with the display filter vssmonitoring).
Note: It is very likely that these captures have no VSS trailer. The heuristic for the VSS trailer dissector is weak and false positives are common. But with the VSS trailer dissector enabled it is sometimes easier to find packets with extraneous trailing data.
In your original non-working capture the postage machine appears to be on the same lan segment as the firewall. The firewall is likely dropping these particular packets because the extraneous trailing byte. Extraneous trailing bytes could be perceived as a covert channel.
In the working capture the Linksys (Cisco) device, serving as a NAT middle-box between the postage-machine and the firewall, does not include the extraneous trailing bytes in the "Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message" packets.
The initial "Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message" packets can be isolated with the following display filter:
(tls.record.content_type == 22) && (tls.handshake.type == 16) && (ip.addr==199.231.0.0/16)
| | 2 | No.2 Revision |
It appears that the Linksys device as a middle-ware NAT box is reframing the postage machine's traffic ultimately suppressing a superfluous trailing byte included at the end of the postage machine's "Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message" packets.
In the non-working capture, these particular packets will appear to have a "VSS Monitoring Ethernet trailer" (when using a Default Wireshark profile, these frames can be selected with the display filter vssmonitoring).
Note: It is very likely that these captures have no VSS trailer. The heuristic for the VSS trailer dissector is weak and false positives are common. But with the VSS trailer dissector enabled it is sometimes easier to find packets with extraneous trailing data.
In your original non-working capture the postage machine appears to be on the same lan segment as the firewall. The firewall is likely dropping these particular packets because the extraneous trailing byte. Extraneous trailing bytes could be perceived as a covert channel.
In the working capture the Linksys (Cisco) device, serving as a NAT middle-box between the postage-machine and the firewall, does not include the extraneous trailing bytes in the "Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message" packets.
The initial "Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message" packets can be isolated with the following display filter:
(tls.record.content_type == 22) && (tls.handshake.type == 16) && (ip.addr==199.231.0.0/16)
FWIW: In the past I've occasionally found the need to keep a middle-box in place to work around the shortcomings (i.e. bug) in the vendor's implementation of some protocol.
