I'm trying to set up a site-site VPN tunnel between two LANs (A and B) with the end goal that any device on LAN A can access any device on LAN B and vice-versa.
LAN A: 192.168.0.0/24
LAN B: 192.168.1.0/24
LAN A is an office site with a static public IP address. I'm testing access from an Ubuntu desktop client with IP address 192.168.0.194.
LAN B is a remote site using a 4G router (and therefore doesn't have a public IP address). It contains one Ubuntu desktop client and other network devices that I need to be able to ping, ssh into and rsync with. All of these actions need to be performed from devices within the LAN A subnet.
LAN A:
Has a static public IP address
Subnet: 192.168.0.0/24
Router: 192.168.0.1
OpenVPN server: 192.168.0.180 (running on a raspberry pi, config generated by PiVPN)
VPN tunnel subnet: 10.50.126.0
Ubuntu desktop client: 192.168.0.194
Server config:
Server config
dev tun
proto udp
port 1776
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/raspberrypi_446faad8-a7c2-4c27-8c48-7cbdb6152300.crt
key /etc/openvpn/easy-rsa/pki/private/raspberrypi_446faad8-a7c2-4c27-8c48-7cbdb6152300.key
dh none
ecdh-curve prime256v1
topology subnet
server 10.50.126.0 255.255.255.0
route 192.168.1.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
# Set your primary domain name server address for clients
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
# Prevent DNS leaks on Windows
push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
client-to-client
client-config-dir /etc/openvpn/ccd
keepalive 15 120
remote-cert-tls client
tls-version-min 1.2
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
cipher AES-256-CBC
auth SHA256
user openvpn
group openvpn
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3
#DuplicateCNs allow access control on a less-granular, per user basis.
#Remove # if you will manage access by user instead of device.
#duplicate-cn
# Generated for use by PiVPN.io
ccd client config:
ccd client config
ifconfig-push 10.50.126.2 255.255.255.0
iroute 192.168.1.0 255.255.255.0
Static routes for LAN A router:
Destination Subnet Mask Gateway Interface
192.168.1.0 255.255.255.0 192.168.0.180 LAN
10.50.126.0 255.255.255.0 192.168.0.180 LAN
Raspberry Pi OpenVPN Server Routing Table:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 302 0 0 wlan0
10.50.126.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.0.0 0.0.0.0 255.255.255.0 U 302 0 0 wlan0
192.168.1.0 10.50.126.2 255.255.255.0 UG 0 0 0 tun0
LAN B:
Uses 4G internet (does not have a static public IP address)
Subnet: 192.168.1.0/24
Router: 192.168.1.1
OpenVPN Client Server: 192.168.1.101, 10.50.126.2 [tunnel IP] (running on a raspberry pi)
Ubuntu desktop client: 192.168.1.102
Static routes for LAN B router:
Destination Subnet Mask Gateway Interface
192.168.0.0 255.255.255.0 192.168.1.101 LAN & WLAN
10.50.126.0 255.255.255.0 192.168.1.101 LAN & WLAN
Raspberry Pi OpenVPN Client Routing Table:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.50.126.1 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.1.1 0.0.0.0 UG 202 0 0 eth0
10.50.126.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
128.0.0.0 10.50.126.1 128.0.0.0 UG 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
192.168.220.0 0.0.0.0 255.255.255.0 U 303 0 0 wlan0
217.23.228.92 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
The Problem
The set-up almost works:
1. From the Ubuntu desktop client on LAN B I can ping / access any device on the LAN A network.
2. From the Ubuntu desktop on LAN A I can ping / access the openvpn client server raspberry pi using either 192.168.1.101 or 10.50.126.2 (tunnel IP).
3. From the Ubuntu desktop on LAN A network I can ping / access the LAN B router using 192.168.1.1
Here are the traceroutes for those tests from the LAN A Ubuntu desktop (ping also works fine):
~$ traceroute 192.168.1.101
traceroute to 192.168.1.101 (192.168.1.101), 30 hops max, 60 byte packets
1 _gateway (192.168.0.1) 4.712 ms 4.671 ms 4.651 ms
2 192.168.0.180 (192.168.0.180) 174.112 ms 174.096 ms 174.080 ms
3 192.168.1.101 (192.168.1.101) 174.059 ms 174.044 ms 174.028 ms
~$ traceroute 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 60 byte packets
1 _gateway (192.168.0.1) 4.524 ms 4.473 ms 4.455 ms
2 192.168.0.180 (192.168.0.180) 16.726 ms 16.708 ms 16.692 ms
3 10.50.126.2 (10.50.126.2) 34.282 ms 38.323 ms 41.374 ms
4 192.168.1.1 (192.168.1.1) 41.348 ms 41.332 ms 41.315 ms
The issue is that I can't ping / access the LAN B Ubuntu desktop from the LAN A Ubuntu desktop.
I can traceroute to the LAN B Ubuntu desktop at 192.168.1.102:
~$ traceroute 192.168.1.102
traceroute to 192.168.1.102 (192.168.1.102), 30 hops max, 60 byte packets
1 _gateway (192.168.0.1) 10.745 ms 10.696 ms 10.676 ms
2 192.168.0.180 (192.168.0.180) 219.790 ms 219.770 ms 219.751 ms
3 10.50.126.2 (10.50.126.2) 219.728 ms 219.710 ms 219.692 ms
4 192.168.1.102 (192.168.1.102) 219.718 ms 219.700 ms 219.680 ms
But when I attempt to ping the LAN B Ubuntu desktop at 192.168.1.102 I get no response:
~$ ping 192.168.1.102
PING 192.168.1.102 (192.168.1.102) 56(84) bytes of data.
From 192.168.0.1 icmp_seq=2 Redirect Host(New nexthop: 180.0.168.192)
tcpdump tests
I've been using tcpdump to try and diagnose the problem. Here's a summary of what I've found:
Ping requests from the LAN A desktop reach the LAN B desktop (hostname: anglachel) successfully, and the LAN B desktop tries to send a reply. Here's the tcpdump from within LAN B desktop to show that:
12:49:17.300981 IP 192.168.0.194 > anglachel: ICMP echo request, id 2, seq 1, length 64
12:49:17.301055 IP anglachel > 192.168.0.194: ICMP echo reply, id 2, seq 1, length 64
12:49:17.301824 IP anglachel.47348 > _gateway.domain: 59840+ [1au] PTR? 194.0.168.192.in-addr.arpa. (55)
12:49:17.312731 IP _gateway.domain > anglachel.47348: 59840 NXDomain 0/0/1 (55)
12:49:17.312914 IP anglachel.47348 > _gateway.domain: 59840+ PTR? 194.0.168.192.in-addr.arpa. (44)
12:49:17.330990 IP _gateway.domain > anglachel.47348: 59840 NXDomain 0/0/0 (44)
I'm not sure if anything else happens as I'm a novice when it comes to interpreting tcpdump outputs.
I can also see that the ping request passes through the LAN B raspberry pi client server via tun0:
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:55:16.500955 IP 192.168.0.194 > 192.168.1.102: ICMP echo request, id 3, seq 1, length 64
12:55:17.511768 IP 192.168.0.194 > 192.168.1.102: ICMP echo request, id 3, seq 2, length 64
12:55:18.513301 IP 192.168.0.194 > 192.168.1.102: ICMP echo request, id 3, seq 3, length 64
12:55:19.526995 IP 192.168.0.194 > 192.168.1.102: ICMP echo request, id 3, seq 4, length 64
12:55:20.548044 IP 192.168.0.194 > 192.168.1.102: ICMP echo request, id 3, seq 5, length 64
12:55:21.572832 IP 192.168.0.194 > 192.168.1.102: ICMP echo request, id 3, seq 6, length 64
But the ping responses don't go back through the client server pi on tun0. I have a suspicion the ping replies are returning to the client server via eth0 with a new destination of the LAN A public IP address. But I could be interpreting it incorrectly. Here's a tcpdump listening on eth0 within the raspberry pi client server:
13:01:54.300684 IP 192.168.1.101.55222 > 192.168.1.1.domain: 19251+ PTR? 101.1.168.192.in-addr.arpa. (44)
13:01:54.301006 IP 192.168.1.101.55826 > LAN_A_Public_IP.1776: UDP, length 96
13:01:54.301339 IP 192.168.1.101.55826 > LAN_A_Public_IP.1776: UDP, length 96
13:01:54.310970 IP 192.168.1.1.domain > 192.168.1.101.55222: 19251 NXDomain 0/0/0 (44)
13:01:54.312496 IP 192.168.1.101.60154 > 192.168.1.1.domain: 16973+ PTR? 102.1.168.192.in-addr.arpa. (44)
13:01:54.325837 IP LAN_A_Public_IP.1776 > 192.168.1.101.55826: UDP, length 96
13:01:54.325904 IP 192.168.1.1.domain > 192.168.1.101.60154: 16973 NXDomain 0/0/0 (44)
13:01:54.326436 IP LAN_A_Public_IP.1776 > 192.168.1.101.55826: UDP, length 96
13:01:54.326611 IP 192.168.1.101.55826 > LAN_A_Public_IP: UDP, length 124
Conclusion
Can someone help me figure out what is going on? I want the final fix to mean that I can ping / access / ssh into the LAN B desktop from the LAN A desktop. More than happy to provide more detail if needed. Any help at all would be massively appreciated!
Thanks,
Cameron