Host can't reach hosts on other LAN connected via OpenVPN



  • Host can't reach hosts on other LAN connected via OpenVPN
    Hi have two sites connected via OpenVPN site to site. It works normally, the pfsense boxes can reach each other via the tunnel.

    One of the hosts cannot reach any hosts on the other side of the tunnel, and I can't figure out why.

    Set up is like this:

    192.168.51.5 (Linux) -> 192.168.51.4 (pfsense) -> OpenVPN (Internet) -> 192.168.22.4 (pfsense) -> 192.168.22.5 (Linux)

    All hosts can ping each other, except for:

    192.168.51.5 -> 192.168.22.4 (fail)
    192.168.51.5 -> 192.168.22.5 (fail)

    Routes on both pfsense boxes look ok:
    On 192.168.22.4:
    192.168.51.0/24 10.32.137.1 UGS 20 1500 ovpnc5

    On 192.168.51.4:
    192.168.22.0/24 10.32.137.2 UGS 10 1500 ovpns4

    LAN firewall rules are set to "Default allow LAN to any rule" and nothing else on both pfsense boxes.

    OpenVPN firewall rules are set to "Allow all" on both firewalls.

    Networking works fine in general on 192.168.51.5. Netplan rules look like this:

    network:
      version: 2
      renderer: networkd
      ethernets:
        ens7:
          match:
            macaddress: 5a:00:01:d6:a6:59
          mtu: 1450
          dhcp4: no
          addresses: [192.168.51.5/24]
          gateway4: 192.168.51.4
          nameservers:
             addresses: [8.8.8.8, 8.8.4.4]
    

    Routes look normal:

    Destination Gateway Genmask Flags Metric Ref Use Iface
    0.0.0.0 192.168.51.4 0.0.0.0 UG 0 0 0 ens7
    192.168.51.0 0.0.0.0 255.255.255.0 U 0 0 0 ens7
    

    Running a packet capture on 192.168.22.4 while pinging it from 192.168.51.5 shows the requests coming in, but no response.

    16:02:09.382510 IP 192.168.51.5 > 192.168.22.4: ICMP echo request, id 2012, seq 7691, length 64
    16:02:09.510445 IP 192.168.51.5 > 192.168.22.4: ICMP echo request, id 2430, seq 24, length 64
    16:02:10.405681 IP 192.168.51.5 > 192.168.22.4: ICMP echo request, id 2012, seq 7692, length 64
    16:02:10.533736 IP 192.168.51.5 > 192.168.22.4: ICMP echo request, id 2430, seq 25, length 64
    

    What am I missing? Any hints highly appreciated, have wasted half a day on this already :/


  • LAYER 8 Rebel Alliance

    You have other hosts in the 192.168.51.0/24 network able to ping 192.168.22.4 and 192.168.22.5?

    -Rico



  • Yes I have another host on 192.168.51.0/24 and the issue is the same:

    [root@freepbx ~]# ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
        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> mtu 1500 qdisc noop state DOWN qlen 1000
        link/ether 56:00:01:7f:73:dc brd ff:ff:ff:ff:ff:ff
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
        link/ether 5a:00:01:7f:73:dc brd ff:ff:ff:ff:ff:ff
        inet 192.168.51.3/24 brd 192.168.51.255 scope global eth1
           valid_lft forever preferred_lft forever
        inet6 fe80::5800:1ff:fe7f:73dc/64 scope link 
           valid_lft forever preferred_lft forever
    
    
    [root@freepbx ~]# ping 192.168.22.5
    PING 192.168.22.5 (192.168.22.5) 56(84) bytes of data.
    ^C
    --- 192.168.22.5 ping statistics ---
    8 packets transmitted, 0 received, 100% packet loss, time 6999ms
    
    
    [root@freepbx ~]# ping google.com
    PING google.com (216.58.208.174) 56(84) bytes of data.
    64 bytes from lhr25s09-in-f174.1e100.net (216.58.208.174): icmp_seq=1 ttl=56 time=1.76 ms
    64 bytes from lhr25s09-in-f174.1e100.net (216.58.208.174): icmp_seq=2 ttl=56 time=2.06 ms
    ^C
    --- google.com ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1000ms
    rtt min/avg/max/mdev = 1.766/1.914/2.063/0.154 ms
    

  • LAYER 8 Rebel Alliance

    Show both sides OpenVPN config and Firewall Rules (screenshots).

    -Rico



  • This is one side of the tunnel:
    alt text

    And the other side:
    alt text

    Firewall rules:
    alt text

    alt text

    alt text

    alt text



  • Ahh, found the culprit finally. There was an old IPSEC tunnel still set up from when we were trialling a SD-WAN provider last year. This borked the routes (same subnet was also present in the OpenVPN set up).

    Sorry for the forum traffic - hopefully it will help someone else in the future. And thank you Rico for helping out.


  • LAYER 8 Rebel Alliance

    Glad you have it working now.

    -Rico


Log in to reply