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

    OpenVPN peer to peer - connects but won't pass traffic

    OpenVPN
    3
    23
    5.9k
    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.
    • mclabornM
      mclaborn
      last edited by

      I must still be missing something.

      I assigned the interfaces as you suggested, on both the server and client sides. On the server side, ovpns1 is assigned to OPT5 for the original server that is used by various individuals. ovpns2 is assigned to OPT6 for the new peer-to-peer that is not yet working.

      On the client side, ovpns1 is assigned to OPT1 for the server running there - I use this from my computer when traveling. ovpnc2 is assigned to OPT2 - the other side of the peer-to-peer that is not yet working.

      Both client and server have an allow all rule for IPV4 on the OpenVPN tab.

      The VPN shows connected on both sides.

      I can still ping from the client pfSense to addresses on the server network if I use "Open VPN Client (perr-to-peer)" as the source address. I think this means that traffic can pass from the client pfSense over the VPN tunnel.

      The routes on the client pfSense appear to me to be correct, as do the routes on the computers on the client network.

      Mitch

      1 Reply Last reply Reply Quote 0
      • V
        viragomann
        last edited by

        @mclaborn:

        I can still ping from the client pfSense to addresses on the server network if I use "Open VPN Client (perr-to-peer)" as the source address. I think this means that traffic can pass from the client pfSense over the VPN tunnel.

        And if you select the LAN address here it's not working?

        1 Reply Last reply Reply Quote 0
        • mclabornM
          mclaborn
          last edited by

          Correct.  I can ping (from pfSense) addresses on the server network from "Open VPN Client" but cannot ping from LAN.

          The routes look correct as far as I can tell (see attached). There is a an allow all rule from the LAN network to any.

          Selection_001.png
          Selection_001.png_thumb

          Mitch

          1 Reply Last reply Reply Quote 0
          • V
            viragomann
            last edited by

            The routes on site A pfSense may be essential here. Check if there is a route for 192.168.5.0/24 pointing to the VPN clients IP.

            1 Reply Last reply Reply Quote 0
            • mclabornM
              mclaborn
              last edited by

              Yes, there is a route on site A to B's internal network.  See attached.
              10.0.27.2 is the client end of the VPN tunnel network.
              I can also ping from pfSense A to addresses on B's internal network if I use the OPT6 (VPN) source address. It fails using the LAN address.

              I forgot to mention earlier - the LAN, WAN1 and WAN2 interfaces on site A are CARP. The OpenVPN server is not running on the CARP virtual IP address but the real address of WAN1 on one of the pfSense boxes in site A.

              Selection_001.png
              Selection_001.png_thumb

              Mitch

              1 Reply Last reply Reply Quote 0
              • V
                viragomann
                last edited by

                So it seems the LAN computer does not response if the source address is one from LAN B network.
                Hardly to believe, since it does though if the source address is out of the vpn tunnel.
                Maybe the response goes up to another gateway?

                To see what's going on here, run a packet capture on site A LAN while you try to ping a LAN computer from site B LAN. Set to filter to ICMP to avoid too much noise.
                Also run a capture while pinging the same computer from the site B pfSense with the default source.

                1 Reply Last reply Reply Quote 0
                • mclabornM
                  mclaborn
                  last edited by

                  I am now more confused than ever.

                  Trying from a computer on the B network, a packet capture on site A LAN does not capture anything. A capture on the site A OpenVPN interface captures echo and reply messages between the 2 sides of the tunnel.

                  10:42:40.190119 AF IPv4 (2), length 32: (tos 0x0, ttl 64, id 3651, offset 0, flags [none], proto ICMP (1), length 28)
    10.0.27.1 > 10.0.27.2: ICMP echo request, id 41407, seq 928, length 8
10:42:40.228986 AF IPv4 (2), length 32: (tos 0x0, ttl 64, id 29671, offset 0, flags [none], proto ICMP (1), length 28)
    10.0.27.2 > 10.0.27.1: ICMP echo reply, id 41407, seq 928, length 8
10:42:40.595307 AF IPv4 (2), length 32: (tos 0x0, ttl 64, id 26687, offset 0, flags [none], proto ICMP (1), length 28)
    10.0.27.2 > 10.0.27.1: ICMP echo request, id 39100, seq 931, length 8
10:42:40.595328 AF IPv4 (2), length 32: (tos 0x0, ttl 64, id 50986, offset 0, flags [none], proto ICMP (1), length 28)
    10.0.27.1 > 10.0.27.2: ICMP echo reply, id 39100, seq 931, length 8

                  From pfSense B default source, capturing on the A site Lan:

                  10:47:36.624118 0c:c4:7a:17:17:57 > ec:f4:bb:cf:2b:60, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 53205, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.27.2 > 172.16.0.212: ICMP echo request, id 39056, seq 0, length 64
10:47:36.624306 ec:f4:bb:cf:2b:60 > 00:00:5e:00:01:03, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 27802, offset 0, flags [none], proto ICMP (1), length 84)
    172.16.0.212 > 10.0.27.2: ICMP echo reply, id 39056, seq 0, length 64

                  From pfSense B default source, capturing on site A OpenVPN:

                  10:49:52.181762 AF IPv4 (2), length 32: (tos 0x0, ttl 64, id 4772, offset 0, flags [none], proto ICMP (1), length 28)
    10.0.27.2 > 10.0.27.1: ICMP echo request, id 39100, seq 1771, length 8
10:49:52.181786 AF IPv4 (2), length 32: (tos 0x0, ttl 64, id 10633, offset 0, flags [none], proto ICMP (1), length 28)
    10.0.27.1 > 10.0.27.2: ICMP echo reply, id 39100, seq 1771, length 8
10:49:52.278123 AF IPv4 (2), length 32: (tos 0x0, ttl 64, id 37252, offset 0, flags [none], proto ICMP (1), length 28)
    10.0.27.1 > 10.0.27.2: ICMP echo request, id 41407, seq 1761, length 8
10:49:52.314909 AF IPv4 (2), length 32: (tos 0x0, ttl 64, id 19078, offset 0, flags [none], proto ICMP (1), length 28)
    10.0.27.2 > 10.0.27.1: ICMP echo reply, id 41407, seq 1761, length 8

                  Mitch

                  1 Reply Last reply Reply Quote 0
                  • V
                    viragomann
                    last edited by

                    The captures on the OpenVPN interface only show ICMP packets between the OpenVPN client an server, not any packet destined to the LAN computer.
                    These seem to be the pings from dpinger on both sites. For Testing it will be better to turn off dpinger on the OpenVPN interfaces.

                    Maybe packets from the site B LAN are never routed into the tunnel.

                    1 Reply Last reply Reply Quote 0
                    • mclabornM
                      mclaborn
                      last edited by

                      The packets from site B LAN are making it to and through the tunnel.  Here is a packet trace on the Open VPN interface on site A (server):

                      10:47:34.720334 AF IPv4 (2), length 88: (tos 0x0, ttl 63, id 60640, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.5.5 > 172.16.0.212: ICMP echo request, id 51458, seq 0, length 64
10:47:35.724967 AF IPv4 (2), length 88: (tos 0x0, ttl 63, id 55095, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.5.5 > 172.16.0.212: ICMP echo request, id 51458, seq 1, length 64

                      The same trace on the LAN interface of A does not see those packets. I suppose that means that either pfSense A does not know how to route those packets, or they are being blocked. pfSense A can ping an internal address from both the LAN and OpenVPN interfaces.

                      There are 2 OpenVPN tabs in the firewall -> rules page and both of them have an allow all rule.

                      Does this setup need an outbout NAT rule? I've tried both with and without one - see attached.

                      Selection_002.png
                      Selection_002.png_thumb

                      Mitch

                      1 Reply Last reply Reply Quote 0
                      • V
                        viragomann
                        last edited by

                        The outbound NAT should not be necessary if the routing work.
                        Beyond that, the rule source in the route would have to be the site B LAN network.

                        What's your OpenVPN tunnel settings? At server it should be a /30 subnet, on client the tunnel field it should be empty.

                        1 Reply Last reply Reply Quote 0
                        • mclabornM
                          mclaborn
                          last edited by

                          The tunnel is defined as 10.0.27.0/30 on both server and client.  Leaving it blank on the client did not work.

                          Mitch

                          1 Reply Last reply Reply Quote 0
                          • mclabornM
                            mclaborn
                            last edited by

                            Any further thoughts or ideas on this?

                            Mitch

                            1 Reply Last reply Reply Quote 0
                            • P
                              peterlinuxgeek
                              last edited by

                              For what it is worth, you seem to have the same problem as me: https://forum.pfsense.org/index.php?topic=142389.0

                              My main concern is that there is no 'local network' entry in the server setup, could that be the key to a solution?

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.