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

    Client can connect but access LAN resources

    OpenVPN
    6
    22
    3.2k
    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.
    • DerelictD
      Derelict LAYER 8 Netgate
      last edited by

      That's not a test, it's guessy-guessy-clicky-clicky lord knows what else you've clicked.

      I suggest you delete everything and start over using this:

      https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server

      Chattanooga, Tennessee, USA
      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
      Do Not Chat For Help! NO_WAN_EGRESS(TM)

      1 Reply Last reply Reply Quote 0
      • E
        ega
        last edited by

        I think that the Lan rule is wrong

        Modify it and put this to try
        Action pass
        Protocol tcp/udp (after you can change for one or the other, just for tests)
        Destination port  range 1194
        Destination lan address ( here you have the tunnel address)

        And try again

        Si compartes dinero queda la mitad, si compartes conocimiento queda el doble.-

        1 Reply Last reply Reply Quote 0
        • E
          ega
          last edited by

          Or… do the tutorial as derelict says ;D

          Btw derelict, I could run ovpn on udp behind nat, dont know what happened before that I couldnt.

          Si compartes dinero queda la mitad, si compartes conocimiento queda el doble.-

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            I think that the Lan rule is wrong

            That LAN rule is completely unnecessary because the same traffic will be passed by the following any any any rule. Looks like it's being used for policy logging, which is fine.

            @OP You are issuing a new client config every time you make a server change (like tap to tun, tcp to udp, etc)

            @OP What's the local IP network at the client site that's having trouble?

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • E
              ega
              last edited by

              @Derelict:

              That LAN rule is completely unnecessary because the same traffic will be passed by the following any any any rule. Looks like it's being used for policy logging, which is fine.

              I think that the following any any rule doesnt cover ovpn traffic, because ovpn traffic doesnt has lan net as source.

              Si compartes dinero queda la mitad, si compartes conocimiento queda el doble.-

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

                @Derelict:

                That's not a test, it's guessy-guessy-clicky-clicky lord knows what else you've clicked.

                I suggest you delete everything and start over using this:

                https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server

                Last I checked that is what testing was: make a change…. TEST.... Works? Leave setting. Doesn't work? Put it back to recommended default.

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

                  @Derelict:

                  I think that the Lan rule is wrong

                  That LAN rule is completely unnecessary because the same traffic will be passed by the following any any any rule. Looks like it's being used for policy logging, which is fine.

                  @OP You are issuing a new client config every time you make a server change (like tap to tun, tcp to udp, etc)

                  @OP What's the local IP network at the client site that's having trouble?

                  Yes, new config every time.

                  Client gets 172.16.17.2 and pfsense gets 172.16.17.1.  From LAN server I can ping 172.16.17.1

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

                    Well, I'm not sure what changed but I rebooted earlier this morning and now traffic is passing.

                    Thanks all for the input.  It is appreciated.

                    1 Reply Last reply Reply Quote 0
                    • DerelictD
                      Derelict LAYER 8 Netgate
                      last edited by

                      @ega:

                      @Derelict:

                      That LAN rule is completely unnecessary because the same traffic will be passed by the following any any any rule. Looks like it's being used for policy logging, which is fine.

                      I think that the following any any rule doesnt cover ovpn traffic, because ovpn traffic doesnt has lan net as source.

                      Then you have a fundamental misunderstanding about firewall rules and how they work in pfSense.

                      Chattanooga, Tennessee, USA
                      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                      Do Not Chat For Help! NO_WAN_EGRESS(TM)

                      1 Reply Last reply Reply Quote 0
                      • DerelictD
                        Derelict LAYER 8 Netgate
                        last edited by

                        @gollo:

                        @Derelict:

                        I think that the Lan rule is wrong

                        That LAN rule is completely unnecessary because the same traffic will be passed by the following any any any rule. Looks like it's being used for policy logging, which is fine.

                        @OP You are issuing a new client config every time you make a server change (like tap to tun, tcp to udp, etc)

                        @OP What's the local IP network at the client site that's having trouble?

                        Yes, new config every time.

                        Client gets 172.16.17.2 and pfsense gets 172.16.17.1.  From LAN server I can ping 172.16.17.1

                        No.  What is the LAN IP scheme on the network where the client is connecting from?  Is it also 192.168.0.0/24?

                        Chattanooga, Tennessee, USA
                        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

                        1 Reply Last reply Reply Quote 0
                        • E
                          ega
                          last edited by

                          @Derelict:

                          Then you have a fundamental misunderstanding about firewall rules and how they work in pfSense.

                          I'm agree with you, I'm thinking that, because that rule on lan interface, was generated by the wizard

                          I've disabled it and still had VPN access.

                          Si compartes dinero queda la mitad, si compartes conocimiento queda el doble.-

                          1 Reply Last reply Reply Quote 0
                          • S
                            smithjoe1
                            last edited by

                            If this is a windows client, I've had the same problem when the OpenVPN tunnel is opened without administrator permissions and it doesn't normally ask to elevate its permissions and it looks like it connects without any issues, but the new routes fail to work correctly in the manner you had described. Setting the client to always require administrator privileges to run fixed it for me.

                            1 Reply Last reply Reply Quote 0
                            • C
                              Clouseau
                              last edited by

                              When pfSense moved to StrongSwan from Racoon, our mobile ipsec went dead for ever. Site to Site works. After that I moved out from pfSense ipsec and took closen look to OpenVPN. I had problems with udp protocol - it did just not work, but after I changed to use TCP - no problems and it works like charm.

                              So do everything with TCP protocol. With udp I could establish conection and even saw trafic coming from client to LAN, but all trafic from LAN back to client did not work. I had automatic rules done allowing any to all…. => change to TCP and all went right!

                              –--------------------------------------------------------------
                              Multible Alix 2D13, APU1,APU2,APU3 - pfSense 2.4.x 64bit
                              Multible Vmware vSphere - pfSense 2.4.x 64bit

                              pfSense - FreeNAS - OwnCloud

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