Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

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

    OpenVPN
    2
    7
    168
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      gdi2k last edited by gdi2k

      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 :/

      1 Reply Last reply Reply Quote 0
      • Rico
        Rico LAYER 8 Rebel Alliance last edited by

        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

        2x Netgate XG-7100 | 11x Netgate SG-5100 | 6x Netgate SG-3100 | 2x Netgate SG-1100

        1 Reply Last reply Reply Quote 0
        • G
          gdi2k last edited by gdi2k

          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
          
          1 Reply Last reply Reply Quote 0
          • Rico
            Rico LAYER 8 Rebel Alliance last edited by

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

            -Rico

            2x Netgate XG-7100 | 11x Netgate SG-5100 | 6x Netgate SG-3100 | 2x Netgate SG-1100

            1 Reply Last reply Reply Quote 0
            • G
              gdi2k last edited by gdi2k

              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

              1 Reply Last reply Reply Quote 0
              • G
                gdi2k last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • Rico
                  Rico LAYER 8 Rebel Alliance last edited by

                  Glad you have it working now.

                  -Rico

                  2x Netgate XG-7100 | 11x Netgate SG-5100 | 6x Netgate SG-3100 | 2x Netgate SG-1100

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post