I’m struggling to determine connectivity throughout two VLANs. Two gadgets on completely different VLANs don’t speak to one another (ssh, traceroute, and many others.) except I provoke a ping first. Pinging additionally initially instances out and now and again doesn’t work in any respect (is inconsistent). The community in query is beneath:
I’ve an HPE 1920S change with Layer 3 capabilities internet hosting two VLANs (VLAN 100 and 300). Every VLAN has its personal gateway (named ASUS1 and ASUS2, mannequin DSL-AC88U). All gadgets on VLAN 100 are configured to make use of ASUS1 (192.168.1.2) as their gateway, and equally, all gadgets on VLAN 300 are configured to make use of ASUS2 (192.168.4.2) as their gateway. Every router hosts a DHCP Server. Each DHCP servers have been added as a DHCP relay on the change with their respective IPs. Every router has firewall enabled. ASUS1 additionally serves an OpenVPN Server in TUN configuration which I take advantage of (windows1 makes use of) to hook up with the community remotely.
I’ve enabled routing between the 2 VLANs on the change. I’ve additionally added the next static routes:
-
OpenVPN consumer config file
- 192.168.1.0/24 through 10.8.0.1
- 192.168.4.0/24 through 10.8.0.1
-
ASUS1 Router
- 10.8.0.0/24 through 10.8.0.1
- 192.168.4.0/24 through 192.168.1.3
-
Change
- 10.8.0.0/24 through 192.168.1.2 (Subsequent Hop Interface: VLAN 100)
- 192.168.1.0/24 through 192.168.1.3 (Subsequent Hop Interface: VLAN 100)
- 192.168.4.0/24 through 192.168.4.3 (Subsequent Hop Interface: VLAN 300)
-
ASUS2 Router
- 10.8.0.0/24 through 192.168.4.3
- 192.168.1.0/24 through 192.168.4.3
I’ve confirmed the next:
- The ARP tables on vacation spot and supply gadgets, the 2 routes and the change DO NOT change BEFORE and AFTER the ping resolves
- The difficulty persists with the firewalls on routers disabled
- There are not any firewalls on linux1 or linux2
- I can ping all supply and vacation spot gadgets (apart from 10.8.0.2 – the VPN consumer) from the change and so they begin working instantly
For prognosis, I’m together with numerous dumps that present my traceroute, ping and SSH makes an attempt between gadgets. I’m additionally together with them so as, as a result of I consider it issues, because the habits of traceroute and ping modifications from one try to a different.
The primary dump exhibits my traceroute makes an attempt from my VPN consumer (windows1) on 10.8.0.2 to 192.168.1.19, 192.168.4.20 and 192.168.4.21, respectively. Observe the primary asterisk on the final hop when crossing VLANs.
(base) PS C:Usersmyuser> tracert -d 192.168.1.19
Tracing path to 192.168.1.19 over a most of 30 hops
1 141 ms 141 ms 143 ms 10.8.0.1
2 143 ms 142 ms 142 ms 192.168.1.19
Hint full.
(base) PS C:Usersmyuser> tracert -d 192.168.4.20
Tracing path to 192.168.4.20 over a most of 30 hops
1 142 ms 142 ms 142 ms 10.8.0.1
2 143 ms 143 ms 143 ms 192.168.1.3
3 * 142 ms 142 ms 192.168.4.20
Hint full.
(base) PS C:Usersmyuser> tracert -d 192.168.4.21
Tracing path to 192.168.4.21 over a most of 30 hops
1 142 ms 142 ms 142 ms 10.8.0.1
2 143 ms 143 ms 145 ms 192.168.1.3
3 * 141 ms 141 ms 192.168.4.21
Hint full.
The second dump exhibits my traceroute and ping makes an attempt from 192.168.4.20 to 192.168.1.19. The primary traceroute finishes with a ‘!H’ and two asterisks. The second traceroute fails to resolve and I ship a Keyboard Interrupt. The ping works however with 33% packet loss. The ultimate traceroute try is profitable after the ping.
[email protected]:~$ sudo traceroute -d 192.168.1.19
[sudo] password for myuser:
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
1 _gateway (192.168.4.2) 0.464 ms 0.515 ms 0.649 ms
2 192.168.4.3 (192.168.4.3) 3.674 ms 5.102 ms 11.126 ms
3 192.168.4.3 (192.168.4.3) 14.924 ms !H * *
[email protected]:~$ sudo traceroute -d 192.168.1.19
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
1 _gateway (192.168.4.2) 0.488 ms 0.504 ms 0.640 ms
2 192.168.4.3 (192.168.4.3) 2.594 ms 3.597 ms 4.354 ms^C
[email protected]:~$ ping 192.168.1.19
PING 192.168.1.19 (192.168.1.19) 56(84) bytes of knowledge.
64 bytes from 192.168.1.19: icmp_seq=2 ttl=63 time=0.410 ms
64 bytes from 192.168.1.19: icmp_seq=3 ttl=63 time=0.462 ms
^C
--- 192.168.1.19 ping statistics ---
3 packets transmitted, 2 obtained, 33.3333% packet loss, time 2080ms
rtt min/avg/max/mdev = 0.410/0.436/0.462/0.026 ms
[email protected]:~$ sudo traceroute -d 192.168.1.19
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
1 192.168.4.3 (192.168.4.3) 1.671 ms 2.486 ms 3.258 ms
2 192.168.1.19 (192.168.1.19) 0.477 ms 0.464 ms 0.451 ms
The third dump exhibits how the SSH connection from 192.168.4.21 to 192.168.19 initially instances out, however finally begins working after a ping. Observe the ‘Redirect Host (New nexthop: 192.168.4.3)’ warning earlier than the ping begins working.
(base) [email protected]:~$ ssh [email protected] -p [redacted]
ssh: connect with host 192.168.1.19 port [redacted]: Connection timed out
(base) [email protected]:~$ sudo traceroute -d 192.168.1.19
[sudo] password for myuser:
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
1 _gateway (192.168.4.2) 0.373 ms 30.085 ms 30.066 ms
2 192.168.4.3 (192.168.4.3) 2.299 ms 3.130 ms 3.890 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * *^C
(base) [email protected]:~$ ping 192.168.1.19
PING 192.168.1.19 (192.168.1.19) 56(84) bytes of knowledge.
From 192.168.4.2: icmp_seq=2 Redirect Host(New nexthop: 192.168.4.3)
64 bytes from 192.168.1.19: icmp_seq=2 ttl=63 time=0.632 ms
64 bytes from 192.168.1.19: icmp_seq=3 ttl=63 time=0.483 ms
64 bytes from 192.168.1.19: icmp_seq=4 ttl=63 time=0.389 ms
64 bytes from 192.168.1.19: icmp_seq=5 ttl=63 time=0.395 ms
^C
--- 192.168.1.19 ping statistics ---
5 packets transmitted, 4 obtained, 20% packet loss, time 4132ms
rtt min/avg/max/mdev = 0.389/0.474/0.632/0.098 ms
(base) [email protected]:~$ sudo traceroute -d 192.168.1.19
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
1 192.168.4.3 (192.168.4.3) 1.483 ms 2.294 ms 3.037 ms
2 192.168.1.19 (192.168.1.19) 0.439 ms 0.405 ms 0.385 ms
(base) [email protected]:~$ ssh [email protected] -p [redacted]
The authenticity of host '[192.168.1.19]:[redacted] ([192.168.1.19]:[redacted])' cannot be established.
ED25519 key fingerprint is SHA256:[redacted].
This key isn't recognized by every other names.
Are you certain you wish to proceed connecting (sure/no/[fingerprint])? ^C
The ultimate dump exhibits how the SSH and traceroute makes an attempt each fail between 10.8.0.2 and 192.168.4.21. The traceroute between the 2 had labored as seen within the first dump, however one thing clearly has modified between makes an attempt…
My query: how can I get SSH and traceroute to work persistently over VPN and between two gadgets onsite however on completely different VLANs, with out having to ping first, as in the event that they have been on the identical subnet?