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

OpenVPN client connecting - but is useless

Scheduled Pinned Locked Moved OpenVPN
14 Posts 3 Posters 1.7k 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.
  • T
    TangoOversway
    last edited by Apr 27, 2023, 8:50 AM

    My pfSense version info:

    2.4.4-RELEASE-p3 (arm64)
    built on Thu May 16 06:01:19 EDT 2019
    FreeBSD 11.2-RELEASE-p10
    The system is on the latest version.

    I understand with OpenVPN, there are significant issues from one version to the next and that there are setup differences from version to version in pfSense. I know I've made multiple posts on this. I'm trying to work through setting up OpenVPN one step at a time and I've spent a lot of time on it over the last few weeks - so much so that I find I'm forgetting things I read at the start of the process and each step has been a struggle. Even with bookmarks, I can't keep straight what I need to do in what I hope is this last stage of setup from the different pages I've read about it.

    At this point I have my OpenVPN server running on Debian 11 on a VPS on the "outside," on the internet. I can connect to it with my phone and tablet, using the OpenVPN app. My firewall is connecting to my VPN, but I can't ping the client on pfSense and, at this point, can't access my LAN from the outside, which is the whole point of this.

    I know pfSense is on my VPN as a client because it shows in the status log on the server and the OpenVPN status page on pfSense shows it. I am finding various different pages on how to set up pfSense with OpenVPN and I am pretty sure I have the OpenVPN part done. I've added the routing info in the config files on the server to advertise the route to my LAN to VPN clients and, as I said, I know the pfSense client is connecting. But from there I can't do anything with it.

    I have tried other options, like CloudConnexa, but that includes the directions to get as far with a pfSense client as I've gotten. It doesn't go farther. I've also found variations in the different web pages I've seen, so I'm not sure just exactly what to do next.

    At this point, now that I have pfSense connecting as a client, I want to:

    1. Ping the pfSense client so I can check that it's online (nothing happens when I ping it).
    2. Ping my systems on my LAN from my clients (and the server) on the VPN. (I figure if I can ping them, I not only can verify that they're working, that I'll be able to connect to them in other ways, such as connecting to my OctoPrint server.)
    3. Have DNS requests on the VPN forwarded to the LAN (which uses pfSense as a DHCP server) so I can connect to my LAN systems by name instead of just IP address.

    I have seen that tutorials talk about setting up firewall rules and NAT rules, but some of them look (to my untrained eye) like they involve making big changes to the system and I'm reluctant to do that unless I know I'm not about to ruin things. (The pages I've found with instructions are usually from a commercial VPN service, so I don't want to make changes that are tailored to their service that might create problems otherwise.)

    So I'm asking not just what to do now that my firewall is functioning as a VPN client, but where can I find specific instructions that work with my current version of pfSense to handle routing traffic properly between my VPN and my LAN?

    V 1 Reply Last reply Apr 27, 2023, 9:42 AM Reply Quote 0
    • V
      viragomann @TangoOversway
      last edited by Apr 27, 2023, 9:42 AM

      @tangooversway said in OpenVPN client connecting - but is useless:

      At this point I have my OpenVPN server running on Debian 11 on a VPS on the "outside," on the internet. I can connect to it with my phone and tablet, using the OpenVPN app. My firewall is connecting to my VPN, but I can't ping the client on pfSense and, at this point, can't access my LAN from the outside, which is the whole point of this.

      Do you have only a single OpenVPN server for both clients, pfSense and phone or other?

      If it's a single server you have to enable inter-client-communication in OpenVPN and you would need client specific overrides for proper routing of the LAN behind the pfSense client.
      So I'd rather suggest to setup a separate server for the site-to-site and one for road warrior clients.

      Do you have a rule in place on the VPN interface to allow access?

      With this settings you should at least be able to ping the VPN IP of pfSense from another connected client.

      T 1 Reply Last reply Apr 27, 2023, 10:47 AM Reply Quote 1
      • T
        TangoOversway @viragomann
        last edited by Apr 27, 2023, 10:47 AM

        @viragomann

        @viragomann said in OpenVPN client connecting - but is useless:

        Do you have only a single OpenVPN server for both clients, pfSense and phone or other?

        The entire VPN is the server on a VPS, two mobile clients (iPhone and iPad) and my pfSense firewall.

        @viragomann said in OpenVPN client connecting - but is useless:

        If it's a single server you have to enable inter-client-communication in OpenVPN

        I have client-to-client set in the server config.

        @viragomann said in OpenVPN client connecting - but is useless:

        you would need client specific overrides for proper routing of the LAN behind the pfSense client.

        I have the client-config-dir set and in there I have a file with the common name of the pfSense client and it has the iroute command. Then I have the route and push commands in the server config. Do I need something in the client OpenVPN setup on pfSense to say that it can pass communication to the LAN, or is that all in the server config and the file in the client-config-dir on the server?

        @viragomann said in OpenVPN client connecting - but is useless:

        So I'd rather suggest to setup a separate server for the site-to-site and one for road warrior clients.

        The only purpose of the entire VPN is so I can use my phone or tablet to reach the LAN, so I must not have been clear about that. I've seen the term "road warrior" used before and I just thought that meant the clients I'm using while out and which I'm using to connect to inside my LAN. The only traffic on the VPN at all is supposed to be from my phone or tablet to the pfSense firewall so I can reach my systems on the LAN behind the firewall.

        (My ISP uses CGNAT, so unless I can find a VPN/proxy service that allows port forwarding from the outside and split-tunneling on a macOS client on the inside, a VPN like this is the only thing I understand will let me reach the computers in my LAN from outside.)

        @viragomann said in OpenVPN client connecting - but is useless:

        With this settings you should at least be able to ping the VPN IP of pfSense from another connected client.

        I had not yet tried to ping my phone client and I just did. While my phone app is reporting it's connected to my server and the pfSense client reports a connection, and the server says both are connected, I can't ping either one from my server.

        V 1 Reply Last reply Apr 27, 2023, 11:04 AM Reply Quote 0
        • V
          viragomann @TangoOversway
          last edited by Apr 27, 2023, 11:04 AM

          @tangooversway said in OpenVPN client connecting - but is useless:

          I have the client-config-dir set and in there I have a file with the common name of the pfSense client and it has the iroute command.

          Check the servers OpenVPN log for entries that the client connection is determined correctly and that the client specific settings are applied properly.

          Then I have the route and push commands in the server config.

          Both for the LAN behind pfSense?

          Do I need something in the client OpenVPN setup on pfSense to say that it can pass communication to the LAN, or is that all in the server config and the file in the client-config-dir on the server?

          All you need are proper firewall rules.

          I had not yet tried to ping my phone client and I just did. While my phone app is reporting it's connected to my server and the pfSense client reports a connection, and the server says both are connected, I can't ping either one from my server.

          I don't expect that the phone is responding. It probably blocks access.
          But pfSense should respond if you have a rule on the OpenVPN tab which allow it. It doesn't neither respond to ping from the server?
          Did you try its VPN client IP?

          T 1 Reply Last reply Apr 27, 2023, 6:24 PM Reply Quote 0
          • T
            TangoOversway @viragomann
            last edited by Apr 27, 2023, 6:24 PM

            @viragomann

            @viragomann said in OpenVPN client connecting - but is useless:

            Check the servers OpenVPN log for entries that the client connection is determined correctly and that the client specific settings are applied properly.

            Doesn't this pretty much say that it's connected properly?

            This is on the server:

            [23-04-27 14:07:12 root@shadowyseas ~] $ cat /var/log/openvpn/openvpn-status.log
            OpenVPN CLIENT LIST
            Updated,2023-04-27 14:07:15
            Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
            Gondolin,aaa.bbb.ccc.ddd:52939,3445,6041,2023-04-27 14:06:45
            ROUTING TABLE
            Virtual Address,Common Name,Real Address,Last Ref
            172.16.8.4,Gondolin,aaa.bbb.ccc.ddd:52939,2023-04-27 14:07:12
            GLOBAL STATS
            Max bcast/mcast queue length,1
            END
            

            And this is from pfSense:Screenshot 2023-04-27 at 2.10.13 PM.png

            Or do I need more specific information that's not provided here?

            @viragomann said in OpenVPN client connecting - but is useless:

            Then I have the route and push commands in the server config.

            Both for the LAN behind pfSense?

            That's part of the problem. I know there's stuff I need to set up on pfSense, but I'm not sure how to do it. I've seen several pages showing this, but they differ since they're generally for commercial services and they're giving instructions that match what they're doing, so I don't know just what variations in the process I need to make. Plus, as I mentioned, to my untrained eye, some of the changes look like they might be a big deal and I'd like to be sure I'm doing the right thing rather than screwing up my firewall.

            @viragomann said in OpenVPN client connecting - but is useless:

            All you need are proper firewall rules.

            And this is what I mean and what I was saying - I don't know what to do with firewall rules and NAT settings.

            @viragomann said in OpenVPN client connecting - but is useless:

            Did you try its VPN client IP?

            Yes.

            @viragomann said in OpenVPN client connecting - but is useless:

            But pfSense should respond if you have a rule on the OpenVPN tab which allow it.

            Okay. I'll review the pfSense settings and see if I can figure out what to do with that.

            When I replied earlier, the pets woke me up and I was rather groggy, so I didn't feel like I could go through and remove all the unneeded comments in my config files and post them at the time. Here's my server config file (actual IP addresses or domains are changed, of course, for safety):

            port 1194
            proto udp
            dev tun
            
            #Cert and key files with specific locations on system:
            ca /etc/openvpn/server/ca.crt
            cert /etc/openvpn/server/TolEressea.crt
            key /etc/openvpn/server/TolEressea.key  # This file should be kept secret
            dh /etc/openvpn/server/dh2048.pem
            tls-crypt /etc/openvpn/server/ta.key 0 # This file is secret
            
            
            data-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:BF-CBC
            data-ciphers-fallback AES-256-CBC
            
            #Networking
            topology subnet
            ifconfig-pool-persist ipp.txt
            server 172.16.8.000 255.255.255.0
            client-to-client
            push "route 172.16.7.00 255.255.255.0"
            route 172.16.7.00 255.255.255.0
            client-config-dir /etc/openvpn/server/
            
            keepalive 10 120
            
            persist-key
            persist-tun
            
            status /var/log/openvpn/openvpn-status.log
            log-append  /var/log/openvpn/openvpn.log
            verb 5
            mute 20
            
            explicit-exit-notify 1
            

            And here's the file "Gondolin," in /etc/openvpn/server/ :

            #Not a normal conf file, so don't add ".ovpn" or ".conf" to the end fo the name.
            #
            #This is to direct traffic through Gondolin and to the LAN within my firewall
            
            iroute 172.16.7.0 255.255.255.0
            

            And, of course, no client.conf or client.ovpn file for the pfSense client, since that's all set in the interface. Here's screenshots of it. I've seen a few references to ping settings for the VPN, but the word "ping" doesn't even occur on this page:
            Screenshot 2023-04-27 at 2.20.12 PM.png

            Screenshot 2023-04-27 at 2.20.26 PM.png

            Screenshot 2023-04-27 at 2.20.41 PM.png

            Screenshot 2023-04-27 at 2.20.59 PM.png

            V PippinP 2 Replies Last reply Apr 27, 2023, 9:09 PM Reply Quote 0
            • T
              TangoOversway
              last edited by Apr 27, 2023, 7:20 PM

              This page, by ProtonVPN, has instructions, but since it includes Ping Settings and indicates (by not specifying a menu path to find them) that they're under OpenVPN settings. That makes me think it might be for another version of pfSense. Since I have limited experience, that discrepancy (and me not knowing why it's a discrepancy) mean I'd rather not proceed with the instructions on that page without someone telling me if I can use them in the latest pfSense version.

              Two other issues on it are that it specifies pfSense 2.6 and my pfSense on my Netgate appliance indicates it's the latest version and it's 2.4.4 and, under Tunnel Settings, it has the function "Pull DNS" that is supposed to be enabled and that option is not available in my pfSense version. (Is it possible my system can only update to 2.4.4, which is about a year old, because the hardware can't handle a newer version?)

              If this page is applicable in my situation, can I use the Custom Options in Advanced Configuration? Or do I need them? (I don't think I can use the remote IP addresses, since those could change for my devices.) Also, I have configured an OpenVPN interface, but this also goes beyond that and specifies what to do with firewall and NAT rules. Those are under steps Four and Five. Will the procedures in those sections work for me? Or are they only for version 2.6? (And how do I get 2.6 if my device thinks 2.4 is the latest? I tried checking the package manager, but it says it can't find any packages, so I'm wondering if there's some issue with "phoning home.")

              1 Reply Last reply Reply Quote 0
              • V
                viragomann @TangoOversway
                last edited by Apr 27, 2023, 9:09 PM

                @tangooversway said in OpenVPN client connecting - but is useless:

                Doesn't this pretty much say that it's connected properly?

                Yes, seems all to be right so far and configured correctly.
                However, it doesn't show if the client file is applied properly.
                Also maybe there went something wrong with the routes on the client.

                So please post section which shows the connection establishment of both, the servers OpenVPN log (/var/log/openvpn/openvpn.log) and also of the clients OpenVPN log.

                Did you try its VPN client IP? 
                

                Yes.

                Strange. Can you also post the OpenVPN firewall rules of the client?
                And also the IPv4 routing table of both.

                You should also be possible to ping the server by its virtual IP 172.16.8.1, I think.

                1 Reply Last reply Reply Quote 0
                • T
                  TangoOversway
                  last edited by Apr 28, 2023, 6:58 AM

                  @viragomann

                  @viragomann said in OpenVPN client connecting - but is useless:

                  Also maybe there went something wrong with the routes on the client.

                  If you mean on the routes in any rules in pfSense, remember, I have no idea what to do there and have figured out that even though my pfSense install says it's the latest version, I'm sure it isn't (it's 2.4.4, not 2.6.x), which is one reason I'm not trying to edit anything in the firewall or NAT rules, so I'm pretty sure those all need to still be dealt with - but I realize there could also be an area of concern in OpenVPN.

                  When I'm on the server (logged in with ssh), pinging the server is no problem - I get a return result without issue.

                  When you ask for the IPv4 routing tables, do you mean something in the OpenVPN config, or a config on the machine?

                  Logs - going to just paste in what I got from restarting both the server and pfSense client, even though it might be long. (I deleted both logs so they'd start from scratch.)

                  I tried to include both logs and got an error when posting them. So I'm going to try to post them by splitting them up. We'll see what works...

                  OpenVPN server log:

                  2023-04-28 02:39:35 event_wait : Interrupted system call (code=4)
                  2023-04-28 02:39:37 event_wait : Interrupted system call (code=4)
                  2023-04-28 02:39:37 net_route_v4_del: 172.16.7.0/24 via 172.16.8.2 dev [NULL] table 0 metric -1
                  2023-04-28 02:39:37 Closing TUN/TAP interface
                  2023-04-28 02:39:37 net_addr_v4_del: 172.16.8.1 dev tun0
                  2023-04-28 02:39:37 SIGINT[hard,] received, process exiting
                  2023-04-28 02:39:47 OpenVPN 2.5.1 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2021
                  2023-04-28 02:39:47 library versions: OpenSSL 1.1.1n  15 Mar 2022, LZO 2.10
                  2023-04-28 02:39:47 net_route_v4_best_gw query: dst 0.0.0.0
                  2023-04-28 02:39:47 net_route_v4_best_gw result: via 10.255.255.1 dev ens192
                  2023-04-28 02:39:47 Diffie-Hellman initialized with 2048 bit key
                  2023-04-28 02:39:52 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
                  2023-04-28 02:39:52 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
                  2023-04-28 02:39:52 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
                  2023-04-28 02:39:52 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
                  2023-04-28 02:39:52 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
                  2023-04-28 02:39:52 net_route_v4_best_gw query: dst 0.0.0.0
                  2023-04-28 02:39:52 net_route_v4_best_gw result: via 10.255.255.1 dev ens192
                  2023-04-28 02:39:52 ROUTE_GATEWAY 10.255.255.1
                  2023-04-28 02:39:52 TUN/TAP device tun0 opened
                  2023-04-28 02:39:52 net_iface_mtu_set: mtu 1500 for tun0
                  2023-04-28 02:39:52 net_iface_up: set tun0 up
                  2023-04-28 02:39:52 net_addr_v4_add: 172.16.8.1/24 dev tun0
                  2023-04-28 02:39:52 net_route_v4_add: 172.16.7.0/24 via 172.16.8.2 dev [NULL] table 0 metric -1
                  2023-04-28 02:39:52 Could not determine IPv4/IPv6 protocol. Using AF_INET
                  2023-04-28 02:39:52 Socket Buffers: R=[212992->212992] S=[212992->212992]
                  2023-04-28 02:39:52 UDPv4 link local (bound): [AF_INET][undef]:1194
                  2023-04-28 02:39:52 UDPv4 link remote: [AF_UNSPEC]
                  2023-04-28 02:39:52 MULTI: multi_init called, r=256 v=256
                  2023-04-28 02:39:52 IFCONFIG POOL IPv4: base=172.16.8.2 size=252
                  2023-04-28 02:39:52 ifconfig_pool_read(), in='Earendil,172.16.8.2,'
                  2023-04-28 02:39:52 succeeded -> ifconfig_pool_set(hand=0)
                  2023-04-28 02:39:52 ifconfig_pool_read(), in='Vingilot,172.16.8.3,'
                  2023-04-28 02:39:52 succeeded -> ifconfig_pool_set(hand=1)
                  2023-04-28 02:39:52 ifconfig_pool_read(), in='Gondolin,172.16.8.4,'
                  2023-04-28 02:39:52 succeeded -> ifconfig_pool_set(hand=2)
                  2023-04-28 02:39:52 IFCONFIG POOL LIST
                  2023-04-28 02:39:52 Earendil,172.16.8.2,
                  2023-04-28 02:39:52 Vingilot,172.16.8.3,
                  2023-04-28 02:39:52 Gondolin,172.16.8.4,
                  2023-04-28 02:39:52 Initialization Sequence Completed
                  2023-04-28 02:45:36 98.97.16.41:16973 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
                  2023-04-28 02:45:36 98.97.16.41:16973 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
                  2023-04-28 02:45:36 98.97.16.41:16973 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
                  2023-04-28 02:45:36 98.97.16.41:16973 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
                  2023-04-28 02:45:36 98.97.16.41:16973 TLS: Initial packet from [AF_INET]98.97.16.41:16973, sid=7ff4a25c 0d1b0d0b
                  2023-04-28 02:45:36 98.97.16.41:16973 VERIFY OK: depth=1, CN=Arda
                  2023-04-28 02:45:36 98.97.16.41:16973 VERIFY OK: depth=0, CN=Gondolin
                  2023-04-28 02:45:36 98.97.16.41:16973 peer info: IV_VER=2.4.6
                  2023-04-28 02:45:36 98.97.16.41:16973 peer info: IV_PLAT=freebsd
                  2023-04-28 02:45:36 98.97.16.41:16973 peer info: IV_PROTO=2
                  2023-04-28 02:45:36 98.97.16.41:16973 peer info: IV_NCP=2
                  2023-04-28 02:45:36 98.97.16.41:16973 peer info: IV_LZ4=1
                  2023-04-28 02:45:36 98.97.16.41:16973 peer info: IV_LZ4v2=1
                  2023-04-28 02:45:36 98.97.16.41:16973 peer info: IV_LZO=1
                  2023-04-28 02:45:36 98.97.16.41:16973 peer info: IV_COMP_STUB=1
                  2023-04-28 02:45:36 98.97.16.41:16973 peer info: IV_COMP_STUBv2=1
                  2023-04-28 02:45:36 98.97.16.41:16973 peer info: IV_TCPNL=1
                  2023-04-28 02:45:36 98.97.16.41:16973 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1570'
                  2023-04-28 02:45:36 98.97.16.41:16973 WARNING: 'auth' is used inconsistently, local='auth SHA1', remote='auth SHA256'
                  2023-04-28 02:45:36 98.97.16.41:16973 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
                  2023-04-28 02:45:36 98.97.16.41:16973 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
                  2023-04-28 02:45:36 98.97.16.41:16973 [Gondolin] Peer Connection Initiated with [AF_INET]98.97.16.41:16973
                  2023-04-28 02:45:36 Gondolin/98.97.16.41:16973 MULTI_sva: pool returned IPv4=172.16.8.4, IPv6=(Not enabled)
                  2023-04-28 02:45:36 Gondolin/98.97.16.41:16973 MULTI: Learn: 172.16.8.4 -> Gondolin/98.97.16.41:16973
                  2023-04-28 02:45:36 Gondolin/98.97.16.41:16973 MULTI: primary virtual IP for Gondolin/98.97.16.41:16973: 172.16.8.4
                  2023-04-28 02:45:36 Gondolin/98.97.16.41:16973 Data Channel: using negotiated cipher 'AES-256-GCM'
                  2023-04-28 02:45:36 Gondolin/98.97.16.41:16973 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
                  2023-04-28 02:45:36 Gondolin/98.97.16.41:16973 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
                  2023-04-28 02:45:37 Gondolin/98.97.16.41:16973 PUSH: Received control message: 'PUSH_REQUEST'
                  2023-04-28 02:45:37 Gondolin/98.97.16.41:16973 SENT CONTROL [Gondolin]: 'PUSH_REPLY,route 172.16.7.00 255.255.255.0,route-gateway 172.16.8.1,topology subnet,ping 10,ping-restart 120,ifconfig 172.16.8.4 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
                  2023-04-28 02:45:37 Gondolin/98.97.16.41:16973 IP packet with unknown IP version=15 seen
                  2023-04-28 02:45:37 Gondolin/98.97.16.41:16973 IP packet with unknown IP version=15 seen
                  2023-04-28 02:45:38 Gondolin/98.97.16.41:16973 IP packet with unknown IP version=15 seen
                  

                  OpenVPN on pfSense log:

                  Apr 28 02:45:35	openvpn	18947	OpenVPN 2.4.6 aarch64-portbld-freebsd11.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 3 2018
                  Apr 28 02:45:35	openvpn	18947	library versions: OpenSSL 1.0.2o-freebsd 27 Mar 2018, LZO 2.10
                  Apr 28 02:45:35	openvpn	18968	MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
                  Apr 28 02:45:35	openvpn	18968	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
                  Apr 28 02:45:35	openvpn	18968	Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
                  Apr 28 02:45:35	openvpn	18968	Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
                  Apr 28 02:45:35	openvpn	18968	Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
                  Apr 28 02:45:35	openvpn	18968	Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
                  Apr 28 02:45:36	openvpn	18968	TCP/UDP: Preserving recently used remote address: [AF_INET]104.192.5.150:1194
                  Apr 28 02:45:36	openvpn	18968	Socket Buffers: R=[42080->42080] S=[57344->57344]
                  Apr 28 02:45:36	openvpn	18968	UDPv4 link local (bound): [AF_INET]192.168.1.48:0
                  Apr 28 02:45:36	openvpn	18968	UDPv4 link remote: [AF_INET]104.192.5.150:1194
                  Apr 28 02:45:36	openvpn	18968	TLS: Initial packet from [AF_INET]104.192.5.150:1194, sid=ee297774 5b3a0928
                  Apr 28 02:45:36	openvpn	18968	VERIFY OK: depth=1, CN=Arda
                  Apr 28 02:45:36	openvpn	18968	VERIFY KU OK
                  Apr 28 02:45:36	openvpn	18968	Validating certificate extended key usage
                  Apr 28 02:45:36	openvpn	18968	++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
                  Apr 28 02:45:36	openvpn	18968	VERIFY EKU OK
                  Apr 28 02:45:36	openvpn	18968	VERIFY OK: depth=0, CN=TolEressea
                  Apr 28 02:45:36	openvpn	18968	WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1570', remote='link-mtu 1557'
                  Apr 28 02:45:36	openvpn	18968	WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'
                  Apr 28 02:45:36	openvpn	18968	WARNING: 'auth' is used inconsistently, local='auth SHA256', remote='auth SHA1'
                  Apr 28 02:45:36	openvpn	18968	Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
                  Apr 28 02:45:36	openvpn	18968	[TolEressea] Peer Connection Initiated with [AF_INET]104.192.5.150:1194
                  Apr 28 02:45:37	openvpn	18968	SENT CONTROL [TolEressea]: 'PUSH_REQUEST' (status=1)
                  Apr 28 02:45:37	openvpn	18968	PUSH: Received control message: 'PUSH_REPLY,route 172.16.7.00 255.255.255.0,route-gateway 172.16.8.1,topology subnet,ping 10,ping-restart 120,ifconfig 172.16.8.4 255.255.255.0,peer-id 0,cipher AES-256-GCM'
                  Apr 28 02:45:37	openvpn	18968	Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS])
                  Apr 28 02:45:37	openvpn	18968	OPTIONS IMPORT: timers and/or timeouts modified
                  Apr 28 02:45:37	openvpn	18968	OPTIONS IMPORT: --ifconfig/up options modified
                  Apr 28 02:45:37	openvpn	18968	OPTIONS IMPORT: route-related options modified
                  Apr 28 02:45:37	openvpn	18968	OPTIONS IMPORT: peer-id set
                  Apr 28 02:45:37	openvpn	18968	OPTIONS IMPORT: adjusting link_mtu to 1625
                  Apr 28 02:45:37	openvpn	18968	OPTIONS IMPORT: data channel crypto options modified
                  Apr 28 02:45:37	openvpn	18968	Data Channel: using negotiated cipher 'AES-256-GCM'
                  Apr 28 02:45:37	openvpn	18968	Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
                  Apr 28 02:45:37	openvpn	18968	Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
                  Apr 28 02:45:37	openvpn	18968	TUN/TAP device ovpnc1 exists previously, keep at program end
                  Apr 28 02:45:37	openvpn	18968	TUN/TAP device /dev/tun1 opened
                  Apr 28 02:45:37	openvpn	18968	do_ifconfig, tt->did_ifconfig_ipv6_setup=0
                  Apr 28 02:45:37	openvpn	18968	/sbin/ifconfig ovpnc1 172.16.8.4 172.16.8.1 mtu 1500 netmask 255.255.255.0 up
                  Apr 28 02:45:37	openvpn	18968	/sbin/route add -net 172.16.8.0 172.16.8.1 255.255.255.0
                  Apr 28 02:45:37	openvpn	18968	/usr/local/sbin/ovpn-linkup ovpnc1 1500 1553 172.16.8.4 255.255.255.0 init
                  Apr 28 02:45:37	openvpn	18968	WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
                  Apr 28 02:45:37	openvpn	18968	Initialization Sequence Completed
                  Apr 28 02:45:39	openvpn	18968	MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
                  Apr 28 02:45:39	openvpn	18968	MANAGEMENT: CMD 'state 1'
                  Apr 28 02:45:39	openvpn	18968	MANAGEMENT: CMD 'status 2'
                  Apr 28 02:45:39	openvpn	18968	MANAGEMENT: Client disconnected
                  Apr 28 02:45:47	openvpn	18968	Bad compression stub (swap) decompression header byte: 42
                  Apr 28 02:45:57	openvpn	18968	Bad compression stub (swap) decompression header byte: 42
                  Apr 28 02:45:58	openvpn	18968	MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
                  Apr 28 02:45:58	openvpn	18968	MANAGEMENT: CMD 'state 1'
                  Apr 28 02:45:58	openvpn	18968	MANAGEMENT: CMD 'status 2'
                  Apr 28 02:45:58	openvpn	18968	MANAGEMENT: Client disconnected
                  
                  PippinP V 2 Replies Last reply Apr 28, 2023, 9:42 AM Reply Quote 0
                  • PippinP
                    Pippin @TangoOversway
                    last edited by Apr 28, 2023, 9:42 AM

                    @tangooversway said in OpenVPN client connecting - but is useless:

                    server 172.16.8.000 255.255.255.0
                    push "route 172.16.7.00 255.255.255.0"
                    route 172.16.7.00 255.255.255.0

                    That's not right ^^^ ....

                    .
                    @tangooversway said in OpenVPN client connecting - but is useless:

                    SENT CONTROL [Gondolin]: 'PUSH_REPLY,route 172.16.7.00 255.255.255.0

                    @tangooversway said in OpenVPN client connecting - but is useless:

                    PUSH: Received control message: 'PUSH_REPLY,route 172.16.7.00 255.255.255.0

                    I gloomily came to the ironic conclusion that if you take a highly intelligent person and give them the best possible, elite education, then you will most likely wind up with an academic who is completely impervious to reality.
                    Halton Arp

                    1 Reply Last reply Reply Quote 1
                    • V
                      viragomann @TangoOversway
                      last edited by Apr 28, 2023, 11:43 AM

                      @tangooversway said in OpenVPN client connecting - but is useless:

                      even though my pfSense install says it's the latest version, I'm sure it isn't (it's 2.4.4, not 2.6.x)

                      So if you go to System > Update don't you find any newer version in the branch drop-down?

                      When you ask for the IPv4 routing tables, do you mean something in the OpenVPN config, or a config on the machine?

                      Yes this are machines settings. OpenVPN adds necessary routes there.
                      In pfSense you can find this in Diagnostic > Routes,
                      on Debian, not sure, but I guess it might be "ip r".

                      In the OpneVPN server config, you should add these lines:

                      auth SHA256
                      compress
                      
                      1 Reply Last reply Reply Quote 1
                      • T
                        TangoOversway
                        last edited by Apr 28, 2023, 6:52 PM

                        Just a quick note, since I'm still looking over everything. I've learned to always hide information that can pinpoint where your systems are, but when I posted the logs last night, it was late and I was exhausted and forgot to do a quick find and replace to deal with that issue. So if numbers are different for subnets and so on in the logs than in earlier posts - well, that's why.

                        1 Reply Last reply Reply Quote 0
                        • T
                          TangoOversway
                          last edited by Apr 28, 2023, 7:33 PM

                          @pippin said in OpenVPN client connecting - but is useless:

                          That's not right ^^^ ....

                          172.16.8.xxx is the VPN LAN and 172.16.7.xxx is my LAN. My understanding is I need to push the route to the LAN and I have a client config file in /etc/openvpn/client that supposedly works with that as well, so OpenVPN knows where the access point to the LAN is.

                          But I have no idea why this is wrong. The lines you quote from my logs indicate that info is being used by OpenVPN, but, as I've mentioned before, to my untrained eye, I don't see what's wrong with it.

                          @viragomann said in OpenVPN client connecting - but is useless:

                          So if you go to System > Update don't you find any newer version in the branch drop-down?

                          No, I don't. In the Update Manager I pick to stick with the latest stable version and all it sees is the current one in my system. The package manager doesn't see any packages, either. I've searched for info on these and see it's not a new issue - it's happened to other people. I'm still wondering if I should address this, then come back to the OpenVPN issue. The problem is, so often, tackling one issue leads to a rabbit hole of multiple issues. OpenVPN is an example. People told me it was easy, but without experience, it's taken me a lot of time to get it going. I don't want to start fixing the update issue, then find it has all sorts of steps that will lead to other issues to fix.

                          (Is it possible to make that issue easier to fix by saving my configuration, resetting pfSense to defaults, restoring my config, then updating pfSense?)

                          @viragomann said in OpenVPN client connecting - but is useless:

                          Yes this are machines settings. OpenVPN adds necessary routes there.
                          In pfSense you can find this in Diagnostic > Routes,
                          on Debian, not sure, but I guess it might be "ip r".

                          Believe it or not, there was a time, over 15 years ago, when I knew how to deal with routing like this - but I haven't done anything with this subject in all that time.

                          From pfSense

                          IPv4 Routes
                          Destination	Gateway	Flags	Use	Mtu	Netif	Expire
                          default	192.168.1.1	UGS	4118965	1500	mvneta0.4090	
                          127.0.0.1	link#7	UH	1121120	16384	lo0	
                          172.16.7.0/24	link#11	U	4274543490	1500	mvneta0.4091	
                          172.16.7.1	link#11	UHS	0	16384	lo0	
                          172.16.8.0/24	172.16.8.1	UGS	0	1500	ovpnc1	
                          172.16.8.1	link#13	UH	0	1500	ovpnc1	
                          172.16.8.4	link#13	UHS	178486	16384	lo0	
                          192.168.1.0/24	link#10	U	1772201	1500	mvneta0.4090	
                          192.168.1.48	link#10	UHS	0	16384	lo0	
                          IPv6 Routes
                          Destination	Gateway	Flags	Use	Mtu	Netif	Expire
                          default	fe80::7624:9fff:fea7:e2f5%mvneta0.4090	UGS	37864072	1500	mvneta0.4090	
                          ::1	link#7	UH	0	16384	lo0	
                          2605:59c8:253f:6c10::/64	link#10	U	0	1500	mvneta0.4090	
                          2605:59c8:253f:6c10::14b	link#10	UHS	0	16384	lo0	
                          2605:59c8:253f:6c10:f2ad:4eff:fe0d:25f5	link#10	UHS	0	16384	lo0	
                          2605:59c8:253f:6c14::/62	link#11	U	0	1500	mvneta0.4091	
                          2605:59c8:253f:6c14:f2ad:4eff:fe0d:25f5	link#11	UHS	0	16384	lo0	
                          fd5e:9a9e:c5bd:10::/64	link#10	U	0	1500	mvneta0.4090	
                          fd5e:9a9e:c5bd:10::14b	link#10	UHS	0	16384	lo0	
                          fd5e:9a9e:c5bd:10:f2ad:4eff:fe0d:25f5	link#10	UHS	118	16384	lo0	
                          fd5e:9a9e:c5bd:14::/62	link#11	U	1864633	1500	mvneta0.4091	
                          fd5e:9a9e:c5bd:14:f2ad:4eff:fe0d:25f5	link#11	UHS	116	16384	lo0	
                          fe80::7624:9fff:fea7:e2f5	fe80::7624:9fff:fea7:e2f5%mvneta0.4090	UGHS	0	1500	mvneta0.4090	
                          fe80::%mvneta0/64	link#1	U	0	1500	mvneta0	
                          fe80::f2ad:4eff:fe0d:25f5%mvneta0	link#1	UHS	0	16384	lo0	
                          fe80::%lo0/64	link#7	U	0	16384	lo0	
                          fe80::1%lo0	link#7	UHS	0	16384	lo0	
                          fe80::%mvneta0.4090/64	link#10	U	38341364	1500	mvneta0.4090	
                          fe80::f2ad:4eff:fe0d:25f5%mvneta0.4090	link#10	UHS	4850	16384	lo0	
                          fe80::%mvneta0.4091/64	link#11	U	166242	1500	mvneta0.4091	
                          fe80::1:1%mvneta0.4091	link#11	UHS	2	16384	lo0	
                          fe80::%mvneta0.4092/64	link#12	U	0	1500	mvneta0.4092	
                          fe80::f2ad:4eff:fe0d:25f5%mvneta0.4092	link#12	UHS	0	16384	lo0	
                          fe80::f2ad:4eff:fe0d:25f5%ovpnc1	link#13	UHS	0	16384	lo0	
                          

                          From the Debian based server:

                          [23-04-28 15:30:49 root@shadowyseas ~] $ ip r
                          default via 10.255.255.1 dev ens192
                          10.255.255.1 dev ens192 scope link
                          172.16.7.0/24 via 172.16.8.2 dev tun0
                          172.16.8.0/24 dev tun0 proto kernel scope link src 172.16.8.1
                          

                          @viragomann said in OpenVPN client connecting - but is useless:

                          In the OpneVPN server config, you should add these lines:
                          auth SHA256
                          compress

                          No problem. I take it I should add them in the client configs for my mobile devices, as well?

                          1 Reply Last reply Reply Quote 0
                          • PippinP
                            Pippin @TangoOversway
                            last edited by Apr 28, 2023, 8:01 PM

                            @tangooversway said in OpenVPN client connecting - but is useless:

                            Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS])

                            @tangooversway said in OpenVPN client connecting - but is useless:

                            server 172.16.8.000 255.255.255.0
                            push "route 172.16.7.00 255.255.255.0"
                            route 172.16.7.00 255.255.255.0

                            Make it so:

                            server 172.16.8.0 255.255.255.0
                            push "route 172.16.7.0 255.255.255.0"
                            route 172.16.7.0 255.255.255.0

                            I gloomily came to the ironic conclusion that if you take a highly intelligent person and give them the best possible, elite education, then you will most likely wind up with an academic who is completely impervious to reality.
                            Halton Arp

                            1 Reply Last reply Reply Quote 1
                            • T TangoOversway referenced this topic on Apr 28, 2023, 8:47 PM
                            • T
                              TangoOversway
                              last edited by Apr 28, 2023, 11:04 PM

                              @pippin said in OpenVPN client connecting - but is useless:

                              server 172.16.8.0 255.255.255.0
                              push "route 172.16.7.0 255.255.255.0"
                              route 172.16.7.0 255.255.255.0

                              I may have missed something (reading disability), but is the only change removing where I typed 2 or 3 zeroes instead of just one? If so, what do the extra 0s do for the system? Won't they still be evaluated as integers?

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