@Sateetje I think I have found it. I had an allow all rule at the bottom of the rules on the LAN interface. In the rule I set the default gateway to a gateway group, look like this was the issue.

@leptdre
What do you mean with "outbound traffic"? The upstream traffic from connected clients?
If this you can simply policy route it like traffic on any other interface.

@jhg said in OpenVPN pfSense to pfSense (peer-to-peer) connected but not routing:

It seems you need all of the following non-default settings
Client

System/General Setup/DNS Server Override ON

As mentioned multiple times, I think, this setting affects pfSense itself only, as long as you have not enabled DNS forwarding in the Resolver.
You still didn't mention if you have this.

Anyway, it has no affect on a domains, which you have configured an override for.

VPN Client/Tunnel Settings/"Pull DNS"

This also has no affect on a domains, which you have configured an override for. So you don't need to set this for your purposes and I never suggested to enable this option.

Custom firewall rule on OpenVPN interface to allow incoming traffic

That's pretty plausible. pfSense is a firewall, all intended traffic needs a rule.

Server

DNS Resolver: add an ACL permitting the remote LAN to query the server's DNS resolver

That's by design of Unbound (DNS Resolver). You need ACLs for all unknown source IPs.

Some comments:

If you use the wizard to create multiple VPNs you'll get duplicate firewall rules for incoming VPN traffic

Also note, that the rule tab "OpenVPN" is in fact an interface group including all OpenVPN instances your are running, can be servers or clients. Hence rules, you add there are applied to all.
For better separation you can assign interfaces to the OpenVPN instances. However, remember that rules on the interface group have priority over ones on a member interface.

@Gertjan

Thank you for your response.

I solved the issue by creating certificates by setting the digest algorithm as SHA245.

Yes, that was it.

What I have settled on
LAN = 192.168.0.1/24
VPN = 192.168.1.0/24
CIDR 192.168.0.0/23 "covers" them both perfectly

I'm not quite sure what to do if I want another VPN.

If I made it 192.168.2.0/24

I'd have to use 192.168.0.0/22 to cover both VPNs and the LAN, but now the Maximum Address is 192.168.3.254 -- so it "wastes" 255 IP addresses.

But I'm not there yet and there's probably a better way to do it.

Thanks for all your help.

@Enso_
I was talking about the firewall on the destination machine.

To investigate the issue, sniff the traffic with packet capture on pfSense on the LAN interface and see if you get both, request and response packets.

@viragomann Here is the mikrotik config:

2ca5f715-8cd8-400a-8c3e-c29d9f1f833d-image.png

a9ba1797-f786-47d3-bba6-639dffdbc4c8-image.png

586386f7-6801-4f64-a484-159b42b242c0-image.png

I am just not sure regarding the IP's

Hey, In here I've decribed my work on this topic :)
https://forum.netgate.com/topic/189447/openvpn-ssl-tls-user-auth-over-ldap/3

@alanbaker
Retaining the serial doesn't make sense here. But anyway, it would not have any affect to the clients.

As well the private key is only used by the server for encryption and doesn't affect the clients.

After reissuing ensure that the new certificate is assigned properly to the server.

@viragomann Thanks for the pointer. I've installed it now.

@jhg
Is there in interface assigned to the concerned OpenVPN instance by any chance?
If so you have to remove it before.

@viragomann Thanks. Changing the server settings to Decompress + Disable Compression does remove the compression mismatch messages. But my strange connectivity issue still persists even with this change, which tells me that the compression mismatch was probably a redherring to my connectivity/routing issue.

Thanks for your help on the compression part!

Replying to my own topic - I've missed something like I've thought :

I was re-using an old List of revoked certificates. IT appears that the CRL ( Certificate Revocation List ) has an expiry date. Which is in no way visible in the GUI to be honest. When I've created a new list and applied it to the VPN, everything works as expected. The thing is that this becomes clear only when you go to create another CRL, to be honest GPT4 Solved it for me.
7e545c7e-0e44-40ee-af81-4ca4cf9d714a-image.png

Please close the topic.

Problem has been solved by using a secondary pfSense instance on a VPS, thanks

@Jung-Fernmelder said in How to distribute IPv6 adresses to OpenVPN clients with changing prefixes via SLAAC:

How to add the network by name?

As I said, this would have to go to someone who's more familiar with OpenVPN. However, the global address is only necessary if you are going through the VPN & pfSense to the Internet. If you're accessing only your local network ULA is fine.

I wish ISPs wouldn't do things like this that break IPv6.

Did you manage to connect to Purepvn?