OpenVPN client connecting - but is useless

TangoOversway

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?

viragomann

@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.

TangoOversway

@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.

viragomann

@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?

TangoOversway

@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

TangoOversway

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.")

viragomann

@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.

TangoOversway

@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

Pippin

@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

viragomann

@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

TangoOversway

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.

TangoOversway

@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?

Pippin

@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

TangoOversway

@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?