0

We have some ubuntu 18.04 servers (both physical and VMs) that will ignore pings and TCP connections coming from clients connected to our intranet via VPN.

It is only fresh installs of 18.04 that are exhibiting this problem (16.04 upgraded to 18.04 is fine).

I'm a software dev, not a network/sys admin. These are test servers - our IT department has no inclination to look at the issue (and aren't comfortable off windows). I don't have access to any company networking infrastructure or settings.

I have two physical servers:

  • serverA: 172.24.8.114 ubuntu 18.04 (upgraded from 16.04). This works.
  • serverB: 172.24.8.96 ubuntu 18.04 (fresh install). This fails for VPN clients.

If I'm on the 172.24.8.X subnet (i.e. at the office), I can ping and curl/ssh to both serverA and serverB If I'm working from home (windows laptop, with WSL and linux VMs), I'm on 10.50.50.X subnet and I can ping and curl/ssh only to serverA. VPN is Sonicwall NetExtender (mandated by work).

When attempting a TCP connection to serverB, serverB gets the SYN, but never replies with the SYN-ACK. A TCP Retransmission comes along 3 seconds later. Likewise, the ping ICMP requests are received, but never replied to. (confirmed with tshark/wireshark)

But I can't see any difference between serverA and serverB that would cause this. It's not a hardware issue - there are other server VMs exhibiting the same problem.

None of the suggestions in Server not sending a SYN/ACK packet in response to a SYN packet worked.

  • sysctl settings are essentially the same.
  • ufw is inactive.
  • iptables -L is essentially the same.

What else should I look at to determine why serverA can be pinged and make TCP connections from anywhere, but serverB will only respond to pings and make TCP connections from it's local subnet?

Edit: ss -tan shows no sockets in a SYN_RECV state on serverB. Both serverA and serverB can ping and make TCP connections to my laptop. tshark was used to collect packets on serverA and serverB, then copied and analysed with wireshark.

cdjc
  • 101
  • 2
  • Are there any sockets in SYN_RECV state on serverB after they receive SYN packet? How did you check that serverB gets the SYN/ICMP packets? Wireshark on that server? Do you have default route or route to VPN subnet on that server? – Tomek Oct 03 '18 at 06:11

2 Answers2

0

On a machine with multiple NICs, There are some cases where the SYN/ACK is sent to the other network, instead of the network where the SYN came from.

An explicit route needs to be in the netplan file. See https://askubuntu.com/questions/1030527/multiple-nics-under-ubuntu-18-04

cdjc
  • 101
  • 2
0

I see exactly the same issue. In our case it seems to be fault of "docker" interfaces. If those interfaces are brought down then we can connect to the services.

Fernando Miguélez
  • 101
  • 1