@viragomann said in How to route LAN traffic thru OVPN:

@ispasoiumircea
In the outbound NAT rule the source has to be your LAN, so 192.168.15.0/24 presumably.

Consider that the policy routing rule on LAN directs all matching packets to the OpenVPN server. Hence it doesn't allow access to any internal destinations like DNS from this device.
This can be done, but you need to use a DNS server on the concerned machine, which is accessible over the VPN. If there is any, you can simply forward DNS requests with a port forwarding rule on pfSense and need nothing to change on the device itself.
Otherwise add an additional rule to pass internal traffic above of the policy routing rule.

The rule on the OpenVPN is only needed for inbound traffic. But I guess, you don't want any, so you can remove it.

Hello,

Thank you. Its worked just adding outbound NAT rule from LAN to VPN.

Good day,

@adrianp918 192.168.1.1/24 is not a network.
192.168.1.0/24 is.

@dimskraft said in What is a correct content setup routing from client to a server?:

server can't know which client is connected to it, so this information should be set on client side;

You can let him know by configure a CSO, however.

If you said it is impossible to push routes from client to server, then why does a client config has the following field

This sets a route on the client, but doesn't push anything to the server.

@guardian said in Can someone please tell me what these messages are about?:

That's really strange as I don't see why there would be that many accesses.

Euh lol.

On my dashboard :

bf998ff4-31e3-4a74-9ae5-6398acb0ab1f-image.png

People like dashboard with most accurate, thus frequent updated info.

Where does the "dashboard page" gets this information from ?
It (PHP + web server) questions (very) frequently the "openvpn" process.
These requests are the ones that are logged.

To stop the logs you are seeing : stop looking at the dashboard, close it 😊

I made a mistake, I can't connect backwards by any means. But I can see ping traffic with packet capture on a client when pining it from server.

@jeffreyn said in No Clients Can Connect To OpenVPN Due to CRL Expiry:

@jimp I applied the patch when it was released. I'm reading the release notes for 23.01 and see Issue #13424 has been addressed in the new version. Do I need to do anything like remove the patch before or after I upgrade? Or does everything take care of itself?

You do not need to do anything with the patch after upgrading. You can delete the entry from the system patches package.

@4632215
If you have a /30 tunnel there can only be two IPs inside, one is the server, the other one is the client. So all is clear.

If the tunnel network is bigger, there can be one server and multiple clients inside. So you have to tell the server, behind which client IP he can find the desired network, you want to send packets to. This can be done by the iroute directive in OpenVPN.
In pfSense you have to create a client specific override to set this, where you have to state the client sides remote network.
But if you only have one client anyway, you can spare this and easily set the tunnel mask to /30.

OMG ... shame on me! Thank you very much @viragomann

@viragomann said in triple site to site working, but 2 pfsenses can only ping the oVPN server site.:

Normally you don't need a route for the tunnel network, because you can as well access the remote firewall by using its LAN address.

No, I couldn't....

The 2 pfsense configured as client were unable to ping anything on the other pfsense.
They can now.

Your OpenVPN should be listing on a WAN type interface.

So it is ... but after a few hours I discovered that pfsense had lost this setting. Set it to "Any", set it back to "WAN" and the problem was solved.

Why would you want do that ?

Virtual Private Networks — OpenVPN — Assigning OpenVPN Interfaces | pfSense Documentation

@travelmore said in OpenVPN not connecting:

to other, whereas in that link the person mentioned changing it to Interface IP address instead of other.

Be careful with this :

cba53f1e-fee1-42d5-8f76-215842ebfc49-image.png

as that a hostname like (RFC1918 like 192.168.0.b) this will be wrong in 99,x % of all cases.

When you are out, somewhere in the wild, surround by the hostile Internet, and you want to connect to 'home' over VPN, you have to connect to your ISP WAN IPv4. Certainly not to your RFC1918 like 192.168.0.x as shown in the image above, which can't be routed over the net.
So : second best choice : the ISP WAN as a host name.
Host name is your tunnel end point, and as the comment says : it could be an IP or a host name. If you shose the latter, it should be resolvable there where you are now. Said differently : it should be resolvable anywhere on the internet.
So : best : set up a DYNDNS so that a known 'hostname' always points to your ISP WAN. This is valid and useful if you have a dynamic IP and/or a static WAN IP.

@huydra I should had TL;DRed the thread... 😆 Got bumped up.