This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ACK Packets sometimes lost

My Astaro sometimes fails to forward some ACK packets coming in via a tunnel.
The affected communication between a local client and a remote server (in fact a printer) starts comletely normal with the client transmitting data, the server replying and ACKing and all ACKs forwarded to the client so that he continues. (The problem occurs also in aother contexts, e.g. drive mapping across the tunnel does not work well; but the printer thing was easiest to reproduce)
At some point, however, I observe that the client gets stuck and retransmits some packet again and again.
To troubleshoot, I did a tcpdump in parallel on interfaces ipsec0 and eth0.
I see the retransmits enter on eth0 and leave towards the remote via ipsec0.
I also see corresponding ACKs enter via ipsec0 (which implies that the tunnel itself is ok, so it's none of those nasty MTU problems).

However, these ACKs are not forwarded to eth0![:O]

What can be the cause? [:S]
I even temporarily enabled a rule "Any / Any /Any" but without success.


This thread was automatically locked due to age.
  • What are you seeing in the IPS log?

    Cheers - Bob
  • Well, in this case I find (caused by simply printing a test page):
    name="Intrusion protection alert" action="drop" reason="EXPLOIT SAPLPD 0x05 command buffer overflow attempt" group="232" srcip="" dstip="" proto="6" srcport="1639" dstport="515" sid="15887" class="Attempted Administrator Privilege Gain" priority="1"  generator="1" msgid="0"

    As a test I disabled IPS for source=internal IPs and things work now. Thanks!
  • This is a common issue with the SNMP messages from printers.  Rather than disabling for all internal IPs, disable only for printer IPs.  If your enterprise isn't running SAP, it looks like you could disable SID=15887.

    Cheers - Bob