Weird issue related to ips

AlexnadreAlexnadre
in Firebox - Networking, Multi-Wan, VLAN, NAT, SD-WAN

Hello,

In my company, we have recently installed a VPN using WatchGuard Firebox.
it worked well for few weeks but past week, we encoutered a weird issue.

We can connect to the VPN with OpenVPN (private ips are 192.168.113.0/24, really important for the next); or connect with IKEv2 (192.168.114.0/24).

Another important note : i'm using a windows host (outside private network) and i connect to a debian 10 machine (with static IP inside 192.168.10.0/24 range) behind the WatchGuard Firebox, using SSH.

Last thursday, around 3:00 pm, i am brutally disconnected from VPN. OK. But i can't connect anymore to my debian... We tested a lot of things, but most relevant are :

  • Debian are receiving ping and SSH network packets but NEVER respond (i can't find why btw)
  • any ip inside 113.0/24 or 114.0/24 cannot connect to my debian
  • any ip inside 10.0/24 can connect to my debian
  • Changing private ip range from 113.0/24 to 115.0/24 doesn't resolve problem
  • Same for changing 114.0/24 to 116.0/24
  • Rebooting debian allow me to connect from any 113, 114, 115 or 116.0/24 to my debian for ~ 2 mins (after that, we back to the problems)
  • BUT changing 113.0/24 to 21.0/24 allow me to connect to my debian

So, my problem is solved but we still don't know why...

Any ideas about this really weird issue ? We don't know if the problem is from my debian or the WatchGuard.
We cannot test more things like another machine inside the network due to the confinement...

Thank you in advance,
Alex

Comments

  • Bruce_BriggsBruce_Briggs

    You can do packet captures on a firewall interface using TCPDUMP.
    With the advanced options you can specify the IP addr for the capture.
    This will at least tell you if reply packets from the Debian are getting back to the firewall interface to which the Debian is connected.
    If not, look downstream from the firewall.

    Also, make sure that there is not the possibility of packets routing from the Debian via multiple paths to the firewall, such as to 2 different firewall interfaces. Dual NICs are often an issue.

    Could also be some sort of odd switch issue. Consider rebooting the switch to make sure that it is not involved.

  • AlexnadreAlexnadre

    Thanks for your help
    I have run tcpdump like this :
    sudo tcpdump -i any -nn host 192.168.21.6 -vvv -B 4096

    For informations, i'm connected with OpenVPN.
    The destination machine is : 192.168.10.55
    The source (who start ssh connection) is : 192.168.21.6

    The tcpdump's command output : https://pastebin.com/enSD3S6W

    The ip range change has worked until today. I was brutally disconnected from my SSH session and then nothing. Cannot connect anymore.

    We cannot reboot the switch during the day, others people use it, in another way than me, but internet work good.
    Other devices connected throw the VPN cannot ping my debian but into the local network (without VPN, on site), it works great...

    We have done a nat redirection to not pass through the VPN and it's OK.
    The only thing i can say is that i use docker and have many network interfaces created. And possibly, both times i was disconnected is after a docker-compose up.
    But why i can connect over nat port redirection and not over VPN connection ?! And if i down all the docker and remove useless interfaces, it still does not work...

  • AlexnadreAlexnadre

    And i have only 1 ethernet card. No wireless card !

  • Bruce_BriggsBruce_Briggs

    The TCP Dump suggests that the firewall is not replying to the ARP requests or that something in between the Debian and the firewall interface is dropping the ARP packets or the reply to the ARP packets.
    A TCP Dump on the firewall interface will tell you if the firewall is seeing the ARP requests and if so if it is replying to them.

    You can display the firewall ARP table using WSM Firebox System Manager -> Status Report, or the Web UI -> System Status -> ARP Table
    Doing so will validate that the firewall does have an ARP entry for 192.168.21.6

  • AlexnadreAlexnadre

    Thanks for your reply !

    We will check the ARP table and give you news soon.

Sign In to comment.