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

    [Solved] OpenVPN no access to multiple LANs

    Scheduled Pinned Locked Moved OpenVPN
    7 Posts 2 Posters 890 Views
    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.
    • Z
      zulasch
      last edited by zulasch

      Hi all,

      I have a similar issue like in this post:
      https://forum.netgate.com/topic/133742/openvpn-to-two-lan-networks/3

      Unfortunately there was no solution for my case.

      I have the following configuration:
      pfSense 2.4.5 with 3 Interfaces and OpenVPN configured
      1 – WAN (Static IP)
      2 – LANO (10.20.30.0/24)
      3 - LANH (192.168.178.0/24)

      I setup the OpenVPN wizzard and I am able to connect to the VPN without any errors. But I am not able to reach any IPs from LANH (192.168.178.0/24)

      OpenVPN Client to LANO (10.20.30.0/24) – works fine
      OpenVPN Client to LANH (192.168.178.0/24) – works only 1 single IP (192.168.178.2 – this ist he pfSense IP)

      I can see the ping request in the firewall log and it`s ALLOW (I set the OpenVPN rule to log) also every other request like http is marked as ALLOW but nevertheless I am not able to ping or get a website from LANH (192.168.178.0/24) via my OpenVPN client.

      I have:

      • tested this with android and a windows 10 Notebook.
      • Created the OpenVPN OPT interface
      • Force all client-generated IPv4 traffic through the tunnel
      • push "route 192.168.178.0 255.255.255.0"
      • set the IPv4 Local network(s) to 192.168.178.0/24

      But nothing changed so I am still not able to reach the subnet LANH (192.168.178.0/24)

      This is very frustrating, but maybe some have a idea?
      Thanks a lot.
      zulasch

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

        Since you see the firewall log entries on the remote pfSense, the routing should work well.

        To investigate use Diagnostic > Packet Capture.
        Take a capture on the OpenVPN interface or on the interface you've assigned to the particular OpenVPN instance and try to access a device in 192.168.178.0/24.
        You shloud see the packets here. Then also take a capture on LANH and post both results, please.

        1 Reply Last reply Reply Quote 0
        • Z
          zulasch
          last edited by

          Hi Viragomann,

          thanks for your reply and hint for the packet capture... here are the results:

          192.168.168.0/24 = OpenVPN subnet

          Interface OpenVPN:

          17:59:46.127012 IP 192.168.168.2.40400 > 31.13.92.48.443: tcp 0
17:59:46.853688 IP 192.168.168.2.40400 > 31.13.92.48.443: tcp 0
17:59:48.873411 IP 192.168.168.2.40400 > 31.13.92.48.443: tcp 0
17:59:50.548697 IP 192.168.168.2.11003 > 192.168.178.2.53: UDP, length 34
17:59:50.549023 IP 192.168.178.2.53 > 192.168.168.2.11003: UDP, length 79
17:59:50.577691 IP 192.168.168.2.40232 > 64.233.167.188.5228: tcp 0
17:59:51.588704 IP 192.168.168.2.40232 > 64.233.167.188.5228: tcp 0
17:59:53.073651 IP 192.168.168.2.40400 > 31.13.92.48.443: tcp 0
17:59:53.618672 IP 192.168.168.2.40232 > 64.233.167.188.5228: tcp 0
17:59:57.701822 IP 192.168.168.2.40232 > 64.233.167.188.5228: tcp 0
17:59:58.958538 IP 192.168.168.2.9987 > 192.168.178.2.53: UDP, length 19
17:59:58.980691 IP 192.168.178.2.53 > 192.168.168.2.9987: UDP, length 94
17:59:59.478889 IP 192.168.168.2.53311 > 192.168.178.2.53: UDP, length 20
17:59:59.502569 IP 192.168.178.2.53 > 192.168.168.2.53311: UDP, length 95
17:59:59.868916 IP 192.168.168.2.45352 > 192.168.178.2.53: UDP, length 21
17:59:59.880158 IP 192.168.178.2.53 > 192.168.168.2.45352: UDP, length 96
18:00:01.269164 IP 192.168.168.2.40400 > 31.13.92.48.443: tcp 0
18:00:03.268694 IP 192.168.168.2.22347 > 192.168.178.2.53: UDP, length 42
18:00:03.268942 IP 192.168.178.2.53 > 192.168.168.2.22347: UDP, length 58
18:00:03.301729 IP 192.168.168.2.57192 > 10.10.10.1.443: tcp 0
18:00:03.301855 IP 10.10.10.1.443 > 192.168.168.2.57192: tcp 0
18:00:03.334709 IP 192.168.168.2.57192 > 10.10.10.1.443: tcp 0
18:00:03.343542 IP 192.168.168.2.57192 > 10.10.10.1.443: tcp 190
18:00:03.343581 IP 10.10.10.1.443 > 192.168.168.2.57192: tcp 0
18:00:03.345666 IP 10.10.10.1.443 > 192.168.168.2.57192: tcp 1349
18:00:03.345702 IP 10.10.10.1.443 > 192.168.168.2.57192: tcp 275
18:00:03.378394 IP 192.168.168.2.57192 > 10.10.10.1.443: tcp 0
18:00:03.378501 IP 192.168.168.2.57192 > 10.10.10.1.443: tcp 0
18:00:03.390534 IP 192.168.168.2.57192 > 10.10.10.1.443: tcp 7
18:00:03.390564 IP 10.10.10.1.443 > 192.168.168.2.57192: tcp 0
18:00:03.390829 IP 10.10.10.1.443 > 192.168.168.2.57192: tcp 0
18:00:03.393347 IP 192.168.168.2.57192 > 10.10.10.1.443: tcp 0
18:00:03.425570 IP 192.168.168.2.57192 > 10.10.10.1.443: tcp 0
18:00:03.429046 IP 192.168.168.2.57192 > 10.10.10.1.443: tcp 0
18:00:05.288761 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 261, seq 1, length 64
18:00:05.883620 IP 192.168.168.2.40232 > 64.233.167.188.5228: tcp 0
18:00:06.298821 IP 192.168.168.2.48195 > 192.168.178.2.53: UDP, length 44
18:00:06.299072 IP 192.168.178.2.53 > 192.168.168.2.48195: UDP, length 103
18:00:06.337741 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 262, seq 1, length 64
18:00:07.358952 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 263, seq 1, length 64
18:00:08.378578 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 264, seq 1, length 64
18:00:09.413703 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 265, seq 1, length 64
18:00:10.413740 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 266, seq 1, length 64
18:00:11.434295 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 267, seq 1, length 64
18:00:12.463675 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 268, seq 1, length 64
18:00:13.463659 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 269, seq 1, length 64
18:00:14.483820 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 270, seq 1, length 64
18:00:15.893624 IP 192.168.168.2.9165 > 192.168.178.2.53: UDP, length 32
18:00:15.916371 IP 192.168.178.2.53 > 192.168.168.2.9165: UDP, length 71
18:00:15.954630 IP 192.168.168.2.40556 > 157.240.27.55.80: tcp 0
18:00:16.963890 IP 192.168.168.2.40556 > 157.240.27.55.80: tcp 0
18:00:17.383613 IP 192.168.168.2.40400 > 31.13.92.48.443: tcp 0

          Interface LANH:

          18:03:16.574503 IP 88.99.184.150.443 > 192.168.178.13.60959: tcp 1195
18:03:16.601786 IP 192.168.178.200.5353 > 224.0.0.251.5353: UDP, length 65
18:03:16.623646 IP 192.168.178.13.60959 > 88.99.184.150.443: tcp 0
18:03:16.637806 IP 192.168.178.135.5353 > 224.0.0.251.5353: UDP, length 65
18:03:16.885063 IP 192.168.178.13.52122 > 224.0.0.252.5355: UDP, length 22
18:03:17.017654 IP 157.240.27.54.443 > 192.168.178.13.60937: tcp 384
18:03:17.017690 IP 157.240.27.54.443 > 192.168.178.13.60937: tcp 671
18:03:17.018044 IP 192.168.178.13.60937 > 157.240.27.54.443: tcp 0
18:03:17.223601 IP 192.168.178.13.137 > 192.168.178.255.137: UDP, length 50
18:03:17.465047 IP 157.240.27.54.443 > 192.168.178.13.60937: tcp 106
18:03:17.473505 IP 192.168.178.13.5353 > 224.0.0.251.5353: UDP, length 28
18:03:17.505295 IP 192.168.178.13.60937 > 157.240.27.54.443: tcp 0
18:03:17.530285 IP 192.168.178.201.5353 > 224.0.0.251.5353: UDP, length 45
18:03:17.564873 IP 192.168.178.200.5353 > 224.0.0.251.5353: UDP, length 65
18:03:17.634898 IP 192.168.178.135.5353 > 224.0.0.251.5353: UDP, length 65
18:03:17.662132 IP 148.251.127.85.80 > 192.168.178.13.60907: tcp 0
18:03:17.662290 IP 192.168.178.13.60907 > 148.251.127.85.80: tcp 0
18:03:17.683666 IP 192.168.178.135.5353 > 224.0.0.251.5353: UDP, length 65
18:03:17.973634 IP 192.168.178.13.137 > 192.168.178.255.137: UDP, length 50
18:03:20.658257 IP 109.90.49.205.443 > 192.168.178.13.61026: tcp 114
18:03:20.698480 IP 192.168.178.13.61026 > 109.90.49.205.443: tcp 0
18:03:20.742084 IP 192.168.178.199.39542 > 52.57.224.199.80: tcp 32
18:03:20.754524 IP 52.57.224.199.80 > 192.168.178.199.39542: tcp 32
18:03:20.756621 IP 192.168.178.199.39542 > 52.57.224.199.80: tcp 0
18:03:20.993042 IP 192.168.178.13.5050 > 192.168.178.255.5050: UDP, length 43
18:03:21.044135 IP 157.240.27.54.443 > 192.168.178.13.60937: tcp 47
18:03:21.084817 IP 192.168.178.13.60937 > 157.240.27.54.443: tcp 0
18:03:21.961449 IP 52.95.119.186.443 > 192.168.178.135.35992: tcp 46
18:03:22.059849 IP 192.168.178.135.35992 > 52.95.119.186.443: tcp 46
18:03:22.099474 IP 52.95.119.186.443 > 192.168.178.135.35992: tcp 0
18:03:23.934540 IP 192.168.101.10.138 > 192.168.101.255.138: UDP, length 201
18:03:24.214079 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 271, seq 1, length 64
18:03:25.255665 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 272, seq 1, length 64
18:03:25.451156 IP 74.125.143.189.443 > 192.168.178.13.64220: UDP, length 43
18:03:25.477468 IP 192.168.178.13.64220 > 74.125.143.189.443: UDP, length 33
18:03:25.487422 IP 192.168.178.13.60959 > 88.99.184.150.443: tcp 819
18:03:25.503018 IP 88.99.184.150.443 > 192.168.178.13.60959: tcp 0
18:03:25.503160 IP 192.168.178.13.60959 > 88.99.184.150.443: tcp 127
18:03:25.517910 IP 88.99.184.150.443 > 192.168.178.13.60959: tcp 0
18:03:25.590211 IP 88.99.184.150.443 > 192.168.178.13.60959: tcp 1175
18:03:25.631521 IP 192.168.178.13.60959 > 88.99.184.150.443: tcp 0
18:03:26.001016 IP 192.168.178.13.5050 > 192.168.178.255.5050: UDP, length 43
18:03:26.303617 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 273, seq 1, length 64
18:03:27.303810 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 274, seq 1, length 64
18:03:27.578498 IP 192.168.178.13.57617 > 172.217.16.174.443: UDP, length 1350
18:03:27.578543 IP 192.168.178.13.57617 > 172.217.16.174.443: UDP, length 204
18:03:27.589014 IP 172.217.16.174.443 > 192.168.178.13.57617: UDP, length 25
18:03:27.637813 IP 172.217.16.174.443 > 192.168.178.13.57617: UDP, length 80
18:03:27.637863 IP 172.217.16.174.443 > 192.168.178.13.57617: UDP, length 410
18:03:27.638381 IP 192.168.178.13.57617 > 172.217.16.174.443: UDP, length 33
18:03:27.638435 IP 172.217.16.174.443 > 192.168.178.13.57617: UDP, length 32
18:03:27.638465 IP 172.217.16.174.443 > 192.168.178.13.57617: UDP, length 203
18:03:27.638934 IP 192.168.178.13.57617 > 172.217.16.174.443: UDP, length 33
18:03:27.898535 IP 148.251.127.85.80 > 192.168.178.13.60907: tcp 0
18:03:27.898691 IP 192.168.178.13.60907 > 148.251.127.85.80: tcp 0
18:03:28.323798 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 275, seq 1, length 64
18:03:29.338849 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 276, seq 1, length 64
18:03:30.269294 IP 192.168.178.13.56226 > 192.168.178.2.53: UDP, length 38
18:03:30.300315 IP 192.168.178.13.56226 > 10.20.30.10.53: UDP, length 38
18:03:30.343221 IP 10.20.30.10.53 > 192.168.178.13.56226: UDP, length 147
18:03:30.343902 IP 192.168.178.13.61028 > 52.157.234.37.443: tcp 0
18:03:30.344031 IP 52.157.234.37.443 > 192.168.178.13.61028: tcp 0
18:03:30.355403 IP 192.168.178.2.53 > 192.168.178.13.56226: UDP, length 147
18:03:30.369061 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 277, seq 1, length 64
18:03:30.575330 IP 192.168.178.13.60942 > 208.123.73.199.443: tcp 121
18:03:30.575392 IP 192.168.178.13.60942 > 208.123.73.199.443: tcp 46
18:03:30.575429 IP 192.168.178.13.60942 > 208.123.73.199.443: tcp 41
18:03:30.698936 IP 208.123.73.199.443 > 192.168.178.13.60942: tcp 0
18:03:30.699002 IP 208.123.73.199.443 > 192.168.178.13.60942: tcp 42
18:03:30.703417 IP 208.123.73.199.443 > 192.168.178.13.60942: tcp 0
18:03:30.703447 IP 208.123.73.199.443 > 192.168.178.13.60942: tcp 46
18:03:30.703579 IP 192.168.178.13.60942 > 208.123.73.199.443: tcp 0
18:03:30.704995 IP 208.123.73.199.443 > 192.168.178.13.60942: tcp 212
18:03:30.705023 IP 208.123.73.199.443 > 192.168.178.13.60942: tcp 244
18:03:30.705159 IP 192.168.178.13.60942 > 208.123.73.199.443: tcp 0
18:03:30.710000 IP 192.168.178.13.60942 > 208.123.73.199.443: tcp 118
18:03:30.844103 IP 192.168.178.13.61028 > 52.157.234.37.443: tcp 0
18:03:30.844259 IP 52.157.234.37.443 > 192.168.178.13.61028: tcp 0
18:03:30.877414 IP 208.123.73.199.443 > 192.168.178.13.60942: tcp 0
18:03:31.003747 IP 192.168.178.13.5050 > 192.168.178.255.5050: UDP, length 43
18:03:31.134339 IP 192.168.178.13.60907 > 148.251.127.85.80: tcp 1
18:03:31.148690 IP 148.251.127.85.80 > 192.168.178.13.60907: tcp 0
18:03:31.344271 IP 192.168.178.13.61028 > 52.157.234.37.443: tcp 0
18:03:31.344443 IP 52.157.234.37.443 > 192.168.178.13.61028: tcp 0
18:03:31.403808 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 278, seq 1, length 64
18:03:31.494569 IP 192.168.178.13.53053 > 216.58.212.142.443: UDP, length 33
18:03:31.533123 IP 216.58.212.142.443 > 192.168.178.13.53053: UDP, length 25
18:03:31.845134 IP 192.168.178.13.61028 > 52.157.234.37.443: tcp 0
18:03:31.845261 IP 52.157.234.37.443 > 192.168.178.13.61028: tcp 0
18:03:32.345765 IP 192.168.178.13.61028 > 52.157.234.37.443: tcp 0
18:03:32.345901 IP 52.157.234.37.443 > 192.168.178.13.61028: tcp 0
18:03:32.397759 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 279, seq 1, length 64
18:03:33.429072 IP 192.168.168.2 > 192.168.178.1: ICMP echo request, id 280, seq 1, length 64
18:03:33.633167 IP 109.90.49.205.443 > 192.168.178.13.61027: tcp 31
18:03:33.633201 IP 109.90.49.205.443 > 192.168.178.13.61027: tcp 0
18:03:33.633348 IP 192.168.178.13.61027 > 109.90.49.205.443: tcp 0
18:03:33.866128 IP 192.168.178.106.52638 > 52.169.82.131.443: tcp 0
18:03:33.897730 IP 52.169.82.131.443 > 192.168.178.106.52638: tcp 0
18:03:33.903052 IP 192.168.178.106.52638 > 52.169.82.131.443: tcp 0

          so as I can see there is a echo request but now echo reply...

          This test is from LANH to 8.8.8.8 witch works perfekt...

          18:06:15.121598 IP 192.168.178.13 > 8.8.8.8: ICMP echo request, id 1, seq 890, length 40
18:06:15.132941 IP 8.8.8.8 > 192.168.178.13: ICMP echo reply, id 1, seq 890, length 40
18:06:16.124011 IP 192.168.178.13 > 8.8.8.8: ICMP echo request, id 1, seq 891, length 40
18:06:16.133001 IP 8.8.8.8 > 192.168.178.13: ICMP echo reply, id 1, seq 891, length 40
18:06:17.126041 IP 192.168.178.13 > 8.8.8.8: ICMP echo request, id 1, seq 892, length 40
18:06:17.136814 IP 8.8.8.8 > 192.168.178.13: ICMP echo reply, id 1, seq 892, length 40
18:06:18.127662 IP 192.168.178.13 > 8.8.8.8: ICMP echo request, id 1, seq 893, length 40
18:06:18.136484 IP 8.8.8.8 > 192.168.178.13: ICMP echo reply, id 1, seq 893, length 40

          I have also checked the firewall rules, I have for any Interface a rule with:
          IPv4 ICMP any * * * * * -> this should always allow ICMP requests.

          Any ideas?

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

            Okay, you've tried to ping 192.168.178.1. Ensure that this device responses to pings to sources outside its subnet.
            You may use Diagnostic > Ping to check that.
            Try a ping with default options, you should get responses. Then change the source to the OpenVPN servers address and check again, then with LAN.

            1 Reply Last reply Reply Quote 0
            • Z
              zulasch
              last edited by zulasch

              I have tested more IPs located on LANH f.exp. 192.168.178.252 and same result via OpenVPN Client.

              With Diagnostic > Ping I am able to ping, so it works.
              As Source Address I have tried the following interfaces:

              OpenVPN (Interface Name)

              PING 192.168.178.252 (192.168.178.252): 56 data bytes
64 bytes from 192.168.178.252: icmp_seq=0 ttl=64 time=0.182 ms
64 bytes from 192.168.178.252: icmp_seq=1 ttl=64 time=0.179 ms
64 bytes from 192.168.178.252: icmp_seq=2 ttl=64 time=0.175 ms

              OpenVPN Server

              PING 192.168.178.252 (192.168.178.252): 56 data bytes
64 bytes from 192.168.178.252: icmp_seq=0 ttl=64 time=0.201 ms
64 bytes from 192.168.178.252: icmp_seq=1 ttl=64 time=0.221 ms
64 bytes from 192.168.178.252: icmp_seq=2 ttl=64 time=0.223 ms

              LANH

              PING 192.168.178.252 (192.168.178.252) from 192.168.178.2: 56 data bytes
64 bytes from 192.168.178.252: icmp_seq=0 ttl=64 time=0.230 ms
64 bytes from 192.168.178.252: icmp_seq=1 ttl=64 time=0.240 ms
64 bytes from 192.168.178.252: icmp_seq=2 ttl=64 time=0.288 ms

              Now I am relay confused why its not working via the OpenVPN Client?!?! 🤔

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

                So I am.
                You see the ping requests from 192.168.168.2 to 192.168.178.1 go out the LANH interface, but no responses are coming back.
                However, if you ping from 192.168.168.1 (OpenVPN server) to 192.168.178.1 it worked?

                The only reason I can think off is that there are strange routes on the destination device. However, as the LANH capture above showes, there is upstream traffic from that subnet directed to pfSense. So the default route should point to pfSense, I assume.

                1 Reply Last reply Reply Quote 0
                • Z
                  zulasch
                  last edited by

                  OMG 🤦 you are absolut right, I am the biggest idiot ever!
                  The IPs that I have tried have a different default gateway an this is not pfSense, so yes its totaly clear why the LANO is working (because all devices have the pfSense as default GW)
                  I have just tried a IP in LANH with pfSense as default GW and everything is fine...

                  Yes sometimes the solution can be so easy and you don't see it.

                  Many thanks for your support!
                  zulasch

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