Strange IPv4 issues

aurimas · January 6, 2021, 11:45am

I have been running my current VyOS setup for a long period of time, but just now discovered very strange behavior at the moment my current setup is:

Dell Precision T1700 running natively VyOS 1.3-rolling-202012160217
I am using motherboard 1G LAN port for internal 1G LAN (eth0) and also using Intel X550-T2 2 x 10Gbe NIC:
ETH2 (1Gbe) connected to my FTTH ONU converter
ETH1 (10Gbe) connected to SFP+ RJ45 module inside Gnodal GS4008 switch in which at the moment only 2 x QSFP 40Gbe to a single windows machine connected via Mellanox ConnectX 3 Pro EN card (all switch/nic settings default)

My current VyOS config:

gist.github.com

https://gist.github.com/aurimasniekis/a938af387f70d1dfb87a2786f98d8805

vyos_config.sh

set firewall all-ping 'enable'
set firewall broadcast-ping 'disable'
set firewall config-trap 'disable'
set firewall ipv6-receive-redirects 'enable'
set firewall ipv6-src-route 'disable'
set firewall ip-src-route 'disable'
set firewall log-martians 'enable'
set firewall name NET-IN default-action 'drop'
set firewall name NET-IN rule 10 action 'accept'
set firewall name NET-IN rule 10 state established 'enable'

This file has been truncated. show original

The issue I am having is that after the Windows machine it somehow loses IPv4 connection to the outside world 1.1.1.1 but IPv6 works perfectly fine. I can ping my router on 192.168.0.1 and any other local IPv4 address but not the outside world. I have tried:

ping 1.1.1.1 result is Request Timed Out
tracert 1.1.1.1 result is not even router is reached and says Request Timed Out

The fix right now I have for this issue is unplugging the ETH1 LAN cable and plugging back in after ~30s and then everything works. So at this moment, I am not really sure where to even look for the issue is it VyOS or Switch or Windows or Mellanox Card. I had compared route print before the fix and after the fix and it’s exactly the same so I am not sure where is the issue. Maybe someone will have some better ideas regarding this. I am not too much into networking.

hagbard · January 6, 2021, 2:48pm

To further analyze this, I would recommend to test from the router. Your issue sounds like a driver reset on the windows side. When the issue is present, login into the router from a different device or via console and try to ping the windows host IPv4 address ad well as the upstream IPv4 gw.
If both works it can also be a contrack table overflowing, but i would start with testing via ping first.

aurimas · January 12, 2021, 8:55am

Thanks for the help, I was testing and after switched to windows to double check it doesn’t work it was working, so I am not sure if it’s something like WSL/Docker VMware stuff taking longer time to spawn it’s shit or etc thanks for helping!

hagbard · January 12, 2021, 3:10pm

Did you check that you have the mac addresses in the arp table? Ping or any other L4 protocol might be filtered. Check on both sides that the mac address is resolved for the IP address. If that’s the case check via tcpdump if a packet is sent from the src and received at the dst.

system · January 14, 2021, 3:10pm

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.