Routing Issue on a Traveling Virtual Lab

Hi Friends,
Hope you can help, my job has me on a highly secure network and its been YEARS since I’ve done network level stuff. So testing things is a nightmare, I never know if I’m fighting internal security protocols, my own stupid or the products. In order to eliminate this I am running a lab on a laptop that travels between my home router for internet access and a network drop at work with internet access.

Both home and quarantine networks are 192.168.10.0/24 with the default gateway of 192.168.10.1

My goal is to end up with 4 separate networks functioning as internal lans, with being able to see each other and for the router to send traffic for the internet out 192.168.10.1

Vyos is currently setup with:

Network 0: 192.168.10.0/24
eth0: 192.168.10.2
dg exists on this network as another router 192.168.10.1

Network 1: 192.168.4.0/24
eth1: 192.168.4.1

Network 2: 192.168.6.0/24
eth2: 192.168.6.1

Network 3: 192.168.12.0/24
eth3: 192.168.12.1

Currently:

Vyos can ping clients on all 4 interfaces, is able to resolve and ping google.com from cli.
Clients have the default gateway set to the corresponding vyos network card.
Clients on network 1,2,3 can ping each other.
Clients on network 1,2,3 can ping the vyos eth0 (192.168.10.2) however, they cannot ping the next hop which is 192.168.10.1. Internet name resolution fails as well.

vyos@vyos:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] via 192.168.10.1, eth0
(Doesn’t this tell the router to send all other traffic 192.168.10.1?)
C>* 127.0.0.0/8 is directly connected, lo
C>* 192.168.4.0/24 is directly connected, eth1
C>* 192.168.6.0/24 is directly connected, eth2
C>* 192.168.10.0/24 is directly connected, eth0
C>* 192.168.12.0/24 is directly connected, eth3

vyos@vyos:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:f9:67:cf brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fef9:67cf/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:f9:67:d9 brd ff:ff:ff:ff:ff:ff
inet 192.168.4.1/24 brd 192.168.4.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fef9:67d9/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:f9:67:e3 brd ff:ff:ff:ff:ff:ff
inet 192.168.6.1/24 brd 192.168.6.255 scope global eth2
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fef9:67e3/64 scope link
valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:f9:67:ed brd ff:ff:ff:ff:ff:ff
inet 192.168.12.1/24 brd 192.168.12.255 scope global eth3
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fef9:67ed/64 scope link
valid_lft forever preferred_lft forever

I figured it out, the destination router needed static routes for the lab networks. It came to me as always, while doing something mundane.

2 Likes

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