This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

RST packets from an Apache host using ProxyPass

0

I've got an Apache host that ProxyPass'es some connections for certain URL's, for example

<Location /partner/data >
ProxyPass https://incoming.partnervendor.com
ProxyPassReverse https://incoming.partnervendor.com
</Location>

Pretty standard. Anything coming from /partner/data should pass on to the vendor's host via https

What I'm seeing is very odd though. There are random clusters of RST packets being sent (from my host) to the IP of the above vendor. These don't make sense to me as

  • They're going from a high port >1024 to a high port >1024. The host only accepts connections on the standard web ports, and the ProxyPass is only to port 443
  • The RST packets all have a sequence ID of 1, which would indicate they're attempting to reset a connection that doesn't exist
  • They aren't consistent with any known connections. I see no SYN or ACK packets related to the IP's/ports of the RST, just RST's
  • I'm thinking this might be a bug with Apache or possibly the Linux OS, but as of yet Google search reveals nothing that would point to the root cause.

    Packets are being captured with a tcpdump which is essentially capturing local->nonlocal or nonlocal->local on high ports:

    tcpdump -nn -i eth0 'dst portrange 1024-65535 && src portrange 1024-65535 && ((src 192.168.50.1 && ! dst net 192.168.0.0/16) || ( dst 192.168.50.1 && ! src net 192.168.0.0/16))'

    asked 27 Oct '17, 13:12

    phx's gravatar image

    phx
    6112
    accept rate: 0%

    Not a Wireshark question. You should post this on an Apache Web Server forum of some kind.

    (28 Oct '17, 02:00) Jaap ♦

    One Answer:

    0

    I doubt it's an Apache question either, its just that Apache is the only place that references those IPs at all (but Apache itself is L7 and isn't low enough in the stack to cause this). I just showed the config for clarity of what the host is doing.

    It could be a kernel bug, networking bug, or possibly wireshark/tcpdump missing info. But in general a SEQ-1 RST and/or an RST without associated session would seem to be against TCP standard.

    answered 28 Oct '17, 10:28

    phx's gravatar image

    phx
    6112
    accept rate: 0%

    edited 28 Oct '17, 10:56

    sindy's gravatar image

    sindy
    6.0k4851