Eu vejo um grande problema aqui: as respostas do seu servidor não passam pelo mesmo caminho que os pacotes que vão para ele.
Sua estação de trabalho está usando seu roteador 10.10.10.190 para alcançar o servidor através de seu endereço 10.10.10.16/32 (/ 32? seu desenho também diz / 28) em vez de usar seu endereço 10.10.10.148 que está no mesmo segmento da LAN como o WS.
No entanto, os pacotes TCP que vão do servidor para o WS não usam o roteador, pois o servidor pode atingir o WS diretamente.
Por que isso importa?
A conseqüência é que seu roteador não vê as respostas do seu servidor e tem uma idéia errada do estado da conexão (apesar do servidor ter respondido com um SYN + ACK, do ponto de vista do roteador o estado da conexão ainda é inicial SYN).
Como a maioria dos roteadores de hoje, ele provavelmente bloqueia qualquer pacote TCP subseqüente que vai do WS para o servidor até ver o SYN + ACK do servidor (isso não acontecerá).
Assim, seu problema real provavelmente não é que seu servidor espere 60 segundos antes de enviar o SYN + ACK, mas que seu roteador bloqueie o tráfego TCP de seu WS para o servidor após o SYN inicial.
Por que esse despejo de tráfego, então?
Se minha teoria estiver correta, o tráfego que você postou na sua pergunta está enganando porque não temos o despejo completo:
- o servidor não responde aos pedidos de SYN porque já respondeu ao primeiro e estes são considerados como duplicados
- o que você vê em 10: 16: 24.062769 e em 10: 16: 24.062860 é provavelmente o servidor enviando sua resposta SYN + ACK novamente após um certo atraso sem receber nada do WS
Como consertar isso?
Você tem várias opções:
- Alcance o servidor diretamente através de seu endereço IP 10.10.10.148 (não é uma correção, na verdade)
- Remova o endereço IP 10.10.10.148 do servidor (não é uma opção, eu acho)
- Desabilite o rastreamento de conexão do firewall no roteador (não é uma opção, eu acho, e não é desejável de qualquer maneira)
- Ponha o endereço MAC do roteador 00: 19: e2: 9e: df: f0 na tabela ARP do servidor para 10.10.10.160 (um hack feio IMHO e você acabará tendo outro problema semelhante ao alcançar o servidor diretamente através de seu 10.10 .10.148 endereço IP, uma vez que os pacotes SYN não usam o roteador, mas as respostas do servidor serão)
- Use roteamento baseado em origem (roteamento de política) para informar ao servidor para usar o roteador quando o endereço de origem dos pacotes de saída for 10.10.10.16, qualquer que seja o endereço de destino
Claro, as opções que na verdade não são opções reais são dadas para que você possa experimentar e validar minha teoria. Roteamento baseado na origem é o que você deve fazer.