@Tom777 As a test, disable gateway monitoring. [image: 1727427724285-2ef89efc-c44e-41f8-9a5d-11c50119273f-image.png]

@Bambos said in Upgrade existing Site to Site Open VPN Tunnels Shared Key to TLS: Sep 25 18:54:08 openvpn 4548 plant30/publicIP:44210 MULTI: Learn: 192.168.30.0/24 -> plant30/publicIP:44210 BTW: this is the line showing, that the route was set inside OpenVPN.

@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: [image: 1726580334812-2ca5f715-8cd8-400a-8c3e-c29d9f1f833d-image.png] [image: 1726580361664-a9ba1797-f786-47d3-bba6-639dffdbc4c8-image.png] [image: 1726580393098-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. [image: 1726137708188-7e545c7e-0e44-40ee-af81-4ca4cf9d714a-image.png] Please close the topic.