first ,you should check if it’s possible to reach internet with 192.168.1.x/eth1 ,after you can change the source to 23.1.2.1/eth0 (on VyOS’s instance) ,here’s an example:
vyos@vyos:~$ sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
S>* 0.0.0.0/0 [210/0] via 192.168.1.1, eth1, weight 1, 00:03:28
C>* 23.1.2.0/24 is directly connected, eth0, 00:03:28
C>* 192.168.1.0/24 is directly connected, eth1, 00:03:28
vyos@vyos:~$ sh config comm | match static
set protocols static
Based on the settings - the gateway towards the Internet is 192.168.1.1.
While the public SW address is configured on a different interface
Is it true? It’s usually the opposite
You can delete the blank command just in case delete protocols static
Also in the VyOS 1.4-rolling-202201260317 there is a bug with DHCP
What version do you have? sh version
My eth0 is running the network side IP (I’m doing a CBT Nuggets NSE4 Training lab), that’s imitating the public internet, while the eth1 interface is actually connecting to my firewall, which is the true gateway.
The true gateway (a fortigate firewall) has the ip address of 192.168.1.1.
What I seem to be able to do is a traceroute. Details below:
vyos@vyos:~$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.358 ms 0.327 ms 0.298 ms
2 202.63.66.1 (202.63.66.1) 13.637 ms 13.600 ms 13.532 ms
3 27.122.114.132 (27.122.114.132) 13.154 ms 13.118 ms 13.061 ms
4 103.200.13.109 (103.200.13.109) 25.360 ms 25.271 ms 25.304 ms
5 72.14.197.210 (72.14.197.210) 24.874 ms 19.211 ms 24.835 ms
6 108.170.247.33 (108.170.247.33) 26.587 ms 25.970 ms 108.170.247.65 (108.170.247.65) 24.500 ms
7 209.85.247.133 (209.85.247.133) 26.038 ms 25.903 ms 142.250.224.191 (142.250.224.191) 24.542 ms
8 8.8.8.8 (8.8.8.8) 19.682 ms 23.478 ms 22.990 ms
Thank you to all that have helped so far, I really appreciate your input.
Does anyone have any recommendations? I’m totally out of ideas here. I’ve tried messing with my vmware interfaces, but there was no change either. It really stumps me that I can traceroute but can’t ping, and there aren’t any visible firewall rules. Should there be a firewall rule?
The traceroute seems to be getting to the internet, which makes me believe that the vswitch is working, and I’ve got other vms using the same without any hassles.
I’d use tcpdump on eth1 interface, to verify if ping packets are sent out.
Also, on the VM, test with all hardware acceleration on NIC disabled, or try different NIC type