OpenVPN client connecting - but is useless
-
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:
- Ping the pfSense client so I can check that it's online (nothing happens when I ping it).
- 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.)
- 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?
-
@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.
-
@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.
-
@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? -
@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 ENDAnd this is from pfSense:
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 1And 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.0And, 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:
-
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.")
-
@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.
-
@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 seenOpenVPN 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 -
@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.0That'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
-
@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 -
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.
-
@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 lo0From 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
compressNo problem. I take it I should add them in the client configs for my mobile devices, as well?
-
@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.0Make 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 -
T TangoOversway referenced this topic on
-
@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.0I 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?
