OpenVPN Client - can't reach remote, but connection is up... strange log entries

[windswept321]

I am trying to set up an opnsense openvpn client to an opnsense openvpn server. The remote server works perfectly with the Viscosity client but not from the opnsense based client. The connection seems to be up, but I can't reach the remote network via ping or otherwise. The correct remote lan nets seem to be loaded as they should, going by the log.
The firewall live log shows requests to the remote network as sent via the openvpn interface. There are no NAT rules. There is a pass all firewall rule for the openvpn interface (IPv4), a pass all firewall rule for the LAN interface and an allow UDP 1194 in WAN rule.

While connection status is still 'up', I see things like this in the openvpn log file after a while:

2020-11-26T20:08:05   openvpn[35446]: MANAGEMENT: Client disconnected
2020-11-26T20:08:05   openvpn[35446]: MANAGEMENT: CMD 'status 2'
2020-11-26T20:08:05   openvpn[35446]: MANAGEMENT: CMD 'state all'

Traceroute commands never get beyond the local opnsense router.

Could someone please help me out with this? I've had this issue for months and now can't access the remote network as my usual laptop is currently out of action.

Screenshots:

[lfirewall1243]

Check if OpenVPN generated the needed routes on both sides

S2S or S2C?

[windswept321]

Thanks for responding. The server routes are certainly generated on the client - I can see them in the client's log. This is with an opnsense router configured as an OpenVPN client and the remote OpenVPN router configured as the OpenVPN server.

At the server end, I have tried enabling 'redirect gateway'  as a client specific override, which causes a lot of errors like the following to show in its logs:

...MULTI: bad source address from client,[192.168.1.94], packet dropped.

It then shows the MANAGEMENT... CMD 'status 2', CMD 'quit', Client disconnected. The client still believes it is connected, however; and I think from memory (earlier today) that the server does too.

I noticed one recent error like the above MULTI one when checking the server's logs, which led me down the google path of enabing 'redirect gateway'. Now they are everywhere. I tried adding the client network to the remote network config options but this seems to have had no effect.

Check if OpenVPN generated the needed routes on both sides

S2S or S2C?

[lfirewall1243]

Thanks for responding. The server routes are certainly generated on the client - I can see them in the client's log. This is with an opnsense router configured as an OpenVPN client and the remote OpenVPN router configured as the OpenVPN server.

At the server end, I have tried enabling 'redirect gateway'  as a client specific override, which causes a lot of errors like the following to show in its logs:

...MULTI: bad source address from client,[192.168.1.94], packet dropped.

It then shows the MANAGEMENT... CMD 'status 2', CMD 'quit', Client disconnected. The client still believes it is connected, however; and I think from memory (earlier today) that the server does too.

I noticed one recent error like the above MULTI one when checking the server's logs, which led me down the google path of enabing 'redirect gateway'. Now they are everywhere. I tried adding the client network to the remote network config options but this seems to have had no effect.

Check if OpenVPN generated the needed routes on both sides

S2S or S2C?

Can you see something in the live log on server side?

[windswept321]

I notice that I have 2 OpenVPN entries under firewall rules (opt2, openvpn interfaces) but only one interface (opt2).
No idea if this is relevant or not...

[windswept321]

I'm away from the server right now. Here is the most recent screenshot I took of the logs:

Thanks for responding. The server routes are certainly generated on the client - I can see them in the client's log. This is with an opnsense router configured as an OpenVPN client and the remote OpenVPN router configured as the OpenVPN server.

At the server end, I have tried enabling 'redirect gateway'  as a client specific override, which causes a lot of errors like the following to show in its logs:

...MULTI: bad source address from client,[192.168.1.94], packet dropped.

It then shows the MANAGEMENT... CMD 'status 2', CMD 'quit', Client disconnected. The client still believes it is connected, however; and I think from memory (earlier today) that the server does too.

I noticed one recent error like the above MULTI one when checking the server's logs, which led me down the google path of enabing 'redirect gateway'. Now they are everywhere. I tried adding the client network to the remote network config options but this seems to have had no effect.

Check if OpenVPN generated the needed routes on both sides

S2S or S2C?

Can you see something in the live log on server side?

[Gauss23]

You should not assign an interface for the OpenVPN client. Or at least call it differently. Try without assignment first.

[windswept321]

Thanks. I have removed the interface which did exist and also the one which didn't via the config xml file. The openvpn issue is still present, though. The server logs now look like this:

2020-12-01T14:12:47   openvpn[97293]: MANAGEMENT: Client disconnected
2020-12-01T14:12:47   openvpn[97293]: MANAGEMENT: CMD 'quit'
2020-12-01T14:12:47   openvpn[97293]: MANAGEMENT: CMD 'status 2'
2020-12-01T14:12:47   openvpn[97293]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
2020-12-01T14:11:45   openvpn[97293]: MANAGEMENT: Client disconnected
2020-12-01T14:11:45   openvpn[97293]: MANAGEMENT: CMD 'quit'
2020-12-01T14:11:45   openvpn[97293]: MANAGEMENT: CMD 'status 2'

The connection status now has a routing table entry and client connection showing.

[Gauss23]

What? You wiped the OpenVPN interface from the xml file? Why? You should have only removed the one you created.

The default OpenVPN section is ok and needed.

You should raise the logging level. It logs just nothing. Level at least 3, for debugging even more.

[windswept321]

I don't think I ever created an OpenVPN interface on the client. I removed 2 from the client; was I wrong to do that? It's still obviously, apparently, connecting etc.
Logging is currently set to 4. Would something higher be helpful?
Here it is at '6':

2020-12-01T14:23:08   openvpn[10450]: MANAGEMENT: Client disconnected
2020-12-01T14:23:08   openvpn[10450]: MANAGEMENT: CMD 'quit'
2020-12-01T14:23:08   openvpn[10450]: MANAGEMENT: CMD 'status 2'
2020-12-01T14:23:08   openvpn[10450]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
2020-12-01T14:22:55   openvpn[10450]: Initialization Sequence Completed
2020-12-01T14:22:55   openvpn[10450]: IFCONFIG POOL: base=10.0.8.4 size=62, ipv6=0
2020-12-01T14:22:55   openvpn[10450]: MULTI: multi_init called, r=256 v=256
2020-12-01T14:22:55   openvpn[10450]: UDPv6 link remote: [AF_UNSPEC]
2020-12-01T14:22:55   openvpn[10450]: UDPv6 link local (bound): [AF_INET6][undef]:1194
2020-12-01T14:22:55   openvpn[10450]: setsockopt(IPV6_V6ONLY=0)
2020-12-01T14:22:55   openvpn[10450]: Socket Buffers: R=[42080->42080] S=[57344->57344]
2020-12-01T14:22:55   openvpn[10450]: Could not determine IPv4/IPv6 protocol. Using AF_INET6
2020-12-01T14:22:55   openvpn[10450]: Data Channel MTU parms [ L:48122 D:1450 EF:122 EB:8156 ET:0 EL:3 ]
2020-12-01T14:22:55   openvpn[10450]: /sbin/route add -net 10.0.8.0 10.0.8.2 255.255.255.0
2020-12-01T14:22:55   openvpn[10450]: /sbin/route add -net 192.168.1.0 10.0.8.2 255.255.255.0
2020-12-01T14:22:54   openvpn[9575]: mlock = DISABLED
2020-12-01T14:22:54   openvpn[9575]: mtu_test = 0
2020-12-01T14:22:54   openvpn[9575]: shaper = 0
2020-12-01T14:22:54   openvpn[9575]: ifconfig_ipv6_remote = '[UNDEF]'
2020-12-01T14:22:54   openvpn[9575]: ifconfig_ipv6_netbits = 0

[Gauss23]

MANAGEMENT: Client disconnected

Those MANAGEMENT lines are happening when you are checking the status page. So every click on status usually shows those 3 lines. They don't say anything about the connection.

And you should not have needed to remove anything from the xml file. You should have only removed the interface from the interface-assignment page.

Do you still see the OpenVPN tab in Firewall:Rules?

[windswept321]

Doh, thanks for pointing out about the MANAGEMENT lines.
The OpenVPN tab is still present in Firewall:Rules. I can also re-add an ovpnc1 interface if necessary in the interface tab. If I do that though, there are then 2 firewall tabs for OpenVPN.
From what I can see, the connection is up but there is no access at all to IPs on the remote networks (ping, traceroute, http, https). I can connect to remote systems fine via a local openvpn client (having imported the opnsense generated export file). Could there be some rule missing? I see the routes seem to be pushed and pulled ok.

Perhaps unrelated, I notice there is an error showing in the dashboard. I think its related to exporting server settings in the client opnsense unit (server isn't set up here, only client). When I try to visit the Export Client link, I also get an 'endpoint parameter mismatch' error.
Here is the error mentioned in the dashboard:

PHP Errors:
[01-Dec-2020 23:16:33 Europe/London] ArgumentCountError: Too few arguments to function OPNsense\OpenVPN\Api\ExportController::accountsAction(), 0 passed and exactly 1 expected in /usr/local/opnsense/mvc/app/controllers/OPNsense/OpenVPN/Api/ExportController.php:204
Stack trace:
#0 [internal function]: OPNsense\OpenVPN\Api\ExportController->accountsAction()
#1 [internal function]: Phalcon\Dispatcher->callActionMethod(Object(OPNsense\OpenVPN\Api\ExportController), 'accountsAction', Array)
#2 [internal function]: Phalcon\Dispatcher->dispatch()
#3 /usr/local/opnsense/www/api.php(26): Phalcon\Mvc\Application->handle()
#4 {main}
[01-Dec-2020 23:23:40 Europe/London] ArgumentCountError: Too few arguments to function OPNsense\OpenVPN\Api\ExportController::accountsAction(), 0 passed and exactly 1 expected in /usr/local/opnsense/mvc/app/controllers/OPNsense/OpenVPN/Api/ExportController.php:204
Stack trace:
#0 [internal function]: OPNsense\OpenVPN\Api\ExportController->accountsAction()
#1 [internal function]: Phalcon\Dispatcher->callActionMethod(Object(OPNsense\OpenVPN\Api\ExportController), 'accountsAction', Array)
#2 [internal function]: Phalcon\Dispatcher->dispatch()
#3 /usr/local/opnsense/www/api.php(26): Phalcon\Mvc\Application->handle()
#4 {main}

[windswept321]

Problem solved. The below pointed me in the right direction and helped with exclusions also.

"This post is a small 2020 note of the forum post routing traffic over a private vpn

In step 6 I set IPv4 Configuration Type to none (not DHCP as shown in the above link)

In OPNsense nowadays the loopback & ISAKMP rules shown in step 8 are now Automatic rules

To get an OpenVPN client working (after the VPN was connecting successfully) - I just needed to follow mainly step 9:

Interfaces => assignments & create an interface connected to ovpnc1 (e.g myVPN)

Firewall => Aliases & create a group of ip's or subnets that will use the VPN (e.g VPN_)

Firewall => NAT => outbound :

select "Hybrid Outbound NAT rules generation"

add Manual Rule for the virtual interface you just created:

Interface = myVPN                 # the virtual interface you just created
Source address = VPN_             # the Firewall alias you just created
Translation / target = interface address
Description = OpenVPN"

From:
https://www.reddit.com/r/OPNsenseFirewall/comments/hy90gt/opnsense_openvpn_client_routing_in_2020/