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.
    • 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.