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

OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue

Scheduled Pinned Locked Moved OpenVPN
13 Posts 2 Posters 971 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.
  • R
    r3uben
    last edited by r3uben Feb 19, 2020, 8:32 PM Feb 19, 2020, 4:59 PM

    Hello netgate community.

    I have a requirement for a few remote users ('road warriors') to be able to access the LAN behind my PFSense router. The 'road warriors' may roam across dynamic WAN IPs, and their local LAN net cannot be guaranteed to be the usual 192.168.1.xxx/24.

    PFSense OpenVPN server WAN: 212.1.1.100 (for the purpose of this thread)
    LAN behind PFSense that the client(s) need to access: 10.4.20.0/24
    Virtual net assigned to OpenVPN clients: 10.4.100.0/24

    Example connection:

    OpenVPN Client
    Lan IP: 192.168.1.10 --> Virtual ip given by OpenVPN server: 10.4.100.50
    I am using client specific overrides to give each client a 'static' virtual IP:

    ifconfig-push 10.4.100.2 255.255.255.0;
    

    Server behind PFSense
    LAN IP: 10.4.20.10

    So far, I have managed to establish a connection after using the OpenVPN wizard and exporting a configuration file. With the appropriate firewall settings I am able to ping 10.4.20.10 and connect successfully to application required over VPN.

    The problem comes when the server tries to initiate a connection back the the client.
    If I try to ping 10.4.100.50 from the server, this request times out. I have checked logs from PFSense and also windows firewall logs on the client - the server has no known route back to the OpenVPN client. I also cannot ping the client straight from PFSense (from the LAN). This is an issue as, after the client initiates a connection to the application on the server, the connection is closed for a while whilst it is thinking about the request, then attempts to reinitiate a connection back to the client.

    Any attempts at searching this issue appear to be saturated with the inverse; 'Client cannot access LAN etc...'

    Thank you
    Reuben

    OpenVPN server.png
    OpenVPN FW rules.png
    Client_override2.png

    V 1 Reply Last reply Feb 19, 2020, 6:03 PM Reply Quote 0
    • V
      viragomann @r3uben
      last edited by Feb 19, 2020, 6:03 PM

      @r3uben said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:

      the server has no known route back to the OpenVPN clien

      So the pfSense is not the default gateway on the server?

      @r3uben said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:

      I also cannot ping the client straight from PFSense.

      So either the client does not respond to pings or you OpenVPN settings are faulty. Show the settings.

      @r3uben said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:

      This is an issue as, after the client initiates a connection to the application on the server, the connection is closed for a while whilst it is thinking about the request, then attempts to reinitiate a connection back to the client.

      Seems to be a strange application.

      1 Reply Last reply Reply Quote 0
      • R
        r3uben
        last edited by r3uben Feb 19, 2020, 7:23 PM Feb 19, 2020, 7:22 PM

        @viragomann said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:

        So the pfSense is not the default gateway on the server?

        I can confirm PFSense is the default gateway
        dd0de824-fac2-4e5d-991c-a542b1b0926a-image.png

        @viragomann said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:

        So either the client does not respond to pings or you OpenVPN settings are faulty. Show the settings.

        The OpenVPN settings should be in images on first post ('OpenVPN server.png', 'Client_override2.png') I have made sure on the client firewall that ICMP will respond to pings from the server network.

        @viragomann said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:

        Seems to be a strange application.

        It is PACS ('Picture archiving and communication system') A standardised system in the medical industry for storing and retrieving image datasets (x-ray, CT etc) There is a listener on the server and a listener on the client application. The client sends a request for a particular set to the server, along with it's 'Application Entity Title' (Client ID). The PACS server does not use the same connection to return the dataset, it will look up the AE Title in it's database and send the dataset to the recorded IP & Port on a brand new connection.

        V 1 Reply Last reply Feb 19, 2020, 8:11 PM Reply Quote 0
        • V
          viragomann @r3uben
          last edited by Feb 19, 2020, 8:11 PM

          @r3uben said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:

          I can confirm PFSense is the default gateway

          So why do you think then, the server has no route back to the client? If pfSense is the default gateway he will send responses to pfSense and this node knows what to do with the packets, since the client is in the same subnet.

          @r3uben said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:

          The OpenVPN settings should be in images on first post ('OpenVPN server.png', 'Client_override2.png')

          I sadly can't see any.

          @r3uben said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:

          I have made sure on the client firewall that ICMP will respond to pings from the server network.

          Did you try a ping from Diagnostic > Ping. Try a ping with the default options and another after changing the source to LAN.

          R 1 Reply Last reply Feb 19, 2020, 8:29 PM Reply Quote 0
          • R
            r3uben @viragomann
            last edited by Feb 19, 2020, 8:29 PM

            @viragomann said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:

            @r3uben said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:

            I can confirm PFSense is the default gateway

            So why do you think then, the server has no route back to the client? If pfSense is the default gateway he will send responses to pfSense and this node knows what to do with the packets, since the client is in the same subnet.

            Only because I cannot ping the client from pfsense from the LAN net the server is on, I can only ping from default / 'OpenVPN server'.
            bce1623a-d712-42e8-9ee9-356da3152416-image.png

            278f6b32-20cb-4860-a403-ecf0d89e5d47-image.png

            @viragomann said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:

            I sadly can't see any.

            41314a7e-67cd-4c4a-88d8-8358e20d2a1f-image.png
            There were URLs at the bottom of the post; I've re-uploaded below
            Cheers

            Client_override2.png
            OpenVPN FW rules.png
            OpenVPN server.png

            1 Reply Last reply Reply Quote 0
            • V
              viragomann
              last edited by viragomann Feb 19, 2020, 8:56 PM Feb 19, 2020, 8:54 PM

              So the client doesn't respond if the ping is coming from the servers LAN (unkown network).
              Possible reason for this may be that the client blocks the access, which is the default behavior on most desktop systems, or that the client has no route to the remote LAN.

              Did you check the clients routes?

              For the first point if its a Windows client a do a trick to get its trust: I push the default route to it. Windows trust networks which provides a default gateway. However, since I don't want to direct all the clients upstream traffic over the vpn, I push the routes with a low metric.
              To do so I have this in the custom options:

              push "route-metric 512";push "route 0.0.0.0 0.0.0.0"
              

              With that I usually can access Windows clients on services that are open in a trusted network like ping or file shares.

              V 1 Reply Last reply Feb 19, 2020, 10:33 PM Reply Quote 0
              • R
                r3uben
                last edited by r3uben Feb 19, 2020, 9:09 PM Feb 19, 2020, 9:07 PM

                On the windows client I have tried the following:

                Add remote networks into the scope
                17e9082e-dde5-49d6-a1a7-288e8451e88d-image.png

                @viragomann said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:

                To do so I have this in the custom options:

                push "route-metric 512";push "route 0.0.0.0 0.0.0.0"
                

                With that I usually can access Windows clients on services that are open in a trusted network like ping or file shares.

                I have also added the custom option as above, however this doesn't seem to make any difference.

                I believe the client routes are correct, as I can ping devices on the remote lan, or access an SMB share from a server etc.
                991eab5d-1493-4d8d-b64a-0d1443751c98-image.png

                1 Reply Last reply Reply Quote 0
                • V
                  viragomann
                  last edited by Feb 19, 2020, 9:20 PM

                  Okay, then the routes should be added correctly.

                  I'd never trust a Windows firewall. You think you open something and it blocks the access anyway. You may try to disable the firewall for testing.

                  On pfSense you can easily check, what's going on with Diagnostic > Packet Capture. Select the OpenVPN interface and start the capture and try to access the server.
                  After stopping you see the result. Check if the packets from the server go into the tunnel and if the client responds.

                  1 Reply Last reply Reply Quote 1
                  • R
                    r3uben
                    last edited by r3uben Feb 19, 2020, 10:04 PM Feb 19, 2020, 9:57 PM

                    Okay I have now checked using packet capture;

                    When I ping from the VPN client > server, I can see traffic with the server response.
                    3470a495-5097-4fb3-afe7-fafff8e0ad77-image.png
                    When I ping the VPN client from the server, there are no replies logged in the capture.
                    ad807f53-e306-4641-8dc8-82e9dab915cb-image.png

                    Windows firewall is completely disabled at this point.

                    1 Reply Last reply Reply Quote 0
                    • V
                      viragomann
                      last edited by Feb 19, 2020, 10:20 PM

                      So obviously the client does not respond. Never trust a Windows firewall even if it's disabled. 😉
                      No idea at this point.

                      However, you can do a workaround with NAT to translate the packets from the server:
                      Firewall > NAT > Outbound
                      Set the hybrid mode and save it, so that you can add individual rules.
                      Add a rule:
                      interface: OpenVPN
                      source: <servers IP, LAN network or any, what you want>
                      dest: <OpenVPNtunnel subnet or any>
                      translation interface: address

                      This translates packets into the the OpenVPN server virtual address. Since this is within the same subnet as the client, you should get responses.

                      1 Reply Last reply Reply Quote 1
                      • R
                        r3uben
                        last edited by r3uben Feb 19, 2020, 10:25 PM Feb 19, 2020, 10:24 PM

                        UPDATE

                        As usual, it was a PEBKAC, of course the local LAN on the VPN client was listed as a 'Private network' but the OpenVPN adapter was listed as 'Public network' so any rules/disabling firewall was only affecting traffic on the local, 'Private' LAN.

                        Apologies!
                        bc17e19d-5660-4c32-931d-d9f0514e6091-image.png

                        1 Reply Last reply Reply Quote 0
                        • V
                          viragomann @viragomann
                          last edited by Feb 19, 2020, 10:33 PM

                          As far as I remember, it's only possible to set the VPN as private network when there is an default gateway by pushing the default route:

                          @viragomann said in OpenVPN routing - Server on LAN to client - NOT the usual 'client cannot access lan' issue:

                          push "route-metric 512";push "route 0.0.0.0 0.0.0.0"

                          However, that this has to be done manually I didn't remember anymore.

                          R 1 Reply Last reply Feb 19, 2020, 10:35 PM Reply Quote 0
                          • R
                            r3uben @viragomann
                            last edited by Feb 19, 2020, 10:35 PM

                            @viragomann Thanks for the help, making sure firewall rules also apply to 'Public' has resolved my issues.

                            Reuben

                            1 Reply Last reply Reply Quote 0
                            13 out of 13
                            • First post
                              13/13
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                              This community forum collects and processes your personal information.
                              consent.not_received