Can only ping one way inside site-to-site VPN link

viragomann

@deon-0 said in Can only ping one way inside site-to-site VPN link:

at the primary site the router and VPN are different machines.

So you'll have to add a static route to each server for 192.168.21.0/24 pointing to the OpenVPN server.

@deon-0 said in Can only ping one way inside site-to-site VPN link:

adding route 192.168.21.0 255.255.255.0 to server.conf, adding 192.168.20.0/24 to IPv4 Remote networks in OpenVPN client settings on the secondary site pfSense/OpenVPN box

Both is necessary for the routing. However, your server pushes the default route (push "redirect-gateway def1 bypass-dhcp"), that should direct the packets for the side A LAN back, but I guess that is not what you want. So I'd remove that line from the server config.

If that doesn't work, post the routing tables of both vpn endpoints while the connection is established.

Deon 0

@viragomann Thanks for your response

So you'll have to add a static route to each server for 192.168.21.0/24 pointing to the OpenVPN server.

Yes, I'm happy to do this but wanted to get the two endpoints talking to each other first. If I can get that sorted, the static routes on each side to their respective endpoints should be easy :)

I've removed redirect-gateway def1 bypass-dhcp from the config on the server side and added route 192.168.21.0 255.255.255.0 but still no go. The secondary site already had 192.168.20.0/24 in 'IPv4 Remote Networks' section of OpenVPN client settings in pfSense.

Here are the route tables on both endpoints:

Primary (standalone VPN server):

root@xxx-vpn01:/etc/openvpn# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.20.1    0.0.0.0         UG    0      0        0 eth0
10.8.0.0        *               255.255.255.0   U     0      0        0 tun0
192.168.20.0    *               255.255.255.0   U     0      0        0 eth0
192.168.21.0    10.8.0.2        255.255.255.0   UG    0      0        0 tun0

Secondary (OpenVPN running on pfSense):

[2.4.5-RELEASE][root@xxx-PFS02.xxxx.com]/root: netstat -r4
Routing tables

Internet:
Destination	Gateway			Flags	Netif Expire
0.0.0.0/1	10.8.0.1		UGS	ovpnc1
default		192.168.1.1		UGS	hn0
10.8.0.0/24	10.8.0.1		UGS	ovpnc1
10.8.0.1	link#7			UH	ovpnc1
10.8.0.2	link#7			UHS	lo0
43.x.x.165/32	192.168.1.1		UGS	hn0
localhost	link#1			UH	lo0
128.0.0.0/1	10.8.0.1		UGS	ovpnc1
192.168.1.0/24	link#5			U	ovpnc1
192.168.1.1	00:15:5d:14:19:00	UHS	hn0
192.168.1.39	link#5			UHS	hn0
192.168.20.0/24	10.8.0.1		UGS	ovpnc1
192.168.21.0/24	link#6			U	hn1
IAD-PFS02	link#6			UHS	lo0

Thanks!

viragomann

@deon-0
The client still shows the default route pointing to the vpn server instead of 192.168.20.0/24.

However, with that you should be able to access the vpn secondary vpn endpoint from the primary and vice versa. You should also be able to ping the respective LAN IP of the routers.
Is there a firewall rule in place on the secondary to allow the access?

Deon 0

@viragomann

Firewalls are either disabled or allowing all traffic on both ends:

Primary (server):

root@xxx-vpn01:/etc/openvpn# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere             udp dpt:openvpn
ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Secondary (client):

[2.4.5-RELEASE][root@xxx-PFS01.xxxx.com]/root: pfctl -d
pfctl: pf not enabled

You should also be able to ping the respective LAN IP of the routers.

Each endpoint can ping the other, and the secondary/client side can ping the servers on the primary side. It's just the primary side that can't ping the servers on the secondary side (from 192.168.20.0/24 to 192.168.21.0/24)

viragomann

@deon-0 said in Can only ping one way inside site-to-site VPN link:

It's just the primary side that can't ping the servers on the secondary side (from 192.168.20.0/24 to 192.168.21.0/24)

That cannot work without the mentioned static route on the servers, only from the vpn endpoint.

Also check the firewall on the destination server. By default the firewalls block access from outside of their own subnet.

Also check the routing table of the destination device.

Deon 0

@viragomann said in Can only ping one way inside site-to-site VPN link:

That cannot work without the mentioned static route on the servers, only from the vpn endpoint.

Yes but even from the primary endpoint, I cannot ping any servers in the secondary subnet (however those same secondary servers can ping back to the primary endpoint)

Primary endpoint (192.168.20.101 / 10.8.0.1) pinging secondary site server (192.168.21.65):

root@xxx-vpn01:/etc/openvpn# ifconfig | grep "inet "
          inet addr:192.168.20.101  Bcast:192.168.20.255  Mask:255.255.255.0
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet addr:10.8.0.1  P-t-P:10.8.0.1  Mask:255.255.255.0

root@xxx-vpn01:/etc/openvpn# ping 192.168.21.65
PING 192.168.21.65 (192.168.21.65) 56(84) bytes of data.
^C
--- 192.168.21.65 ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12095ms

root@xxx-vpn01:/etc/openvpn# traceroute 192.168.21.65
traceroute to 192.168.21.65 (192.168.21.65), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
root@xxx-vpn01:/etc/openvpn#

In reverse: secondary site server (192.168.21.65) pinging primary endpoint (192.168.20.101 / 10.8.0.1):

C:\>ipconfig | find "192"
   IPv4 Address. . . . . . . . . . . . . . . : 192.168.21.65
   Default Gateway . . . . . . . . . . . . . : 192.168.21.55

C:\>ping 192.168.20.1

Pinging 192.168.20.1 with 32 bytes of data:
Reply from 192.168.20.1: bytes=32 time=386ms TTL=62
Reply from 192.168.20.1: bytes=32 time=373ms TTL=62
Reply from 192.168.20.1: bytes=32 time=371ms TTL=62
Reply from 192.168.20.1: bytes=32 time=375ms TTL=62

Ping statistics for 192.168.20.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 371ms, Maximum = 386mx, Average = 376ms

C:\>ping 10.8.0.1

Pinging 192.168.20.1 with 32 bytes of data:
Reply from 192.168.20.1: bytes=32 time=435ms TTL=62
Reply from 192.168.20.1: bytes=32 time=418ms TTL=62
Reply from 192.168.20.1: bytes=32 time=417ms TTL=62
Reply from 192.168.20.1: bytes=32 time=388ms TTL=62

Ping statistics for 10.8.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 388ms, Maximum = 435mx, Average = 414ms

C:\>tracert 192.168.20.1

Tracing route to 192.168.20.1 over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  IAD-PFS02.xxxx.com [192.168.21.55]
  2   551 ms   391 ms   382 ms  10.8.0.1
  3   431 ms   378 ms   379 ms  192.168.20.1

Trace complete.

viragomann

@deon-0
Strange. Basically I'd suggest to use a /30 OpenVPN tunnel network for a site-to-site connection, but I don't really think, that this is the issue here.

Are you able to ping the secondary by its vpn tunnel IP 10.8.0.2?
It's strange, that this isn't shown in the traceroute, even if it is in the routing table.

Deon 0

@viragomann
Yeah something definitely seems weird but I can't quite see it :(

I posted on the OpenVPN forum and got "Read the HOWTO" so that was super helpful.

The primary endpoint and secondary servers can reach the secondary endpoint on 10.8.0.2. Primary servers cannot reach 10.8.0.2 (but can reach 10.8.0.1 so the route table is probably correct on the servers, but maybe not the endpoint. They make the first hop to the primary endpoint but can't get further)

root@xxx-web03:/home/webadmin# traceroute 10.8.0.2
traceroute to 10.8.0.2 (10.8.0.2), 30 hops max, 60 byte packets
 1  192.168.20.101 (192.168.20.101)  0.356 ms * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *^C

root@xxx-web03:/home/webadmin# traceroute 10.8.0.1
traceroute to 10.8.0.1 (10.8.0.1), 30 hops max, 60 byte packets
 1  10.8.0.1 (10.8.0.1)  0.473 ms  0.458 ms  0.450 ms

root@xxx-web03:/home/webadmin# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.20.1    0.0.0.0         UG    0      0        0 eth0
10.8.0.0        192.168.20.101  255.255.255.0   UG    0      0        0 eth0
192.168.20.0    *               255.255.255.0   U     0      0        0 eth0

viragomann

@deon-0
Is IP forwarding enabled on the primary endpoint?

The routes shown in this screenshot may probably belong to a primary server, but there is the route for the secondary LAN missing. It shows only the tunnel subnet, which is not really needed, since it's only a transit network. But it's needed though to ping the secondary virtual IP, of course.

Deon 0

@viragomann

Is IP forwarding enabled on the primary endpoint?

Yes:

root@xxx-vpn01:/etc/openvpn# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
root@xxx-vpn01:/etc/openvpn# cat /proc/sys/net/ipv4/ip_forward
1

The routes shown in this screenshot may probably belong to a primary server, but there is the route for the secondary LAN missing

Can you explain this a little more? What route/gateway should I add?

edit: oh yes, I hadn't added the route to that primary server yet, since I figured something upstream is broken (between the two endpoints) that I haven't pushed out the static routes to all the downstream servers until I get the endpoints talking first

viragomann

@deon-0
It seems as if the IP forwarding doesn't work. Did you restart the primary endpoint machine after adding it?

To investigate do some tcpdump on the primary on the vpn interface and on pfSense, while you try to ping 10.8.0.2.