I just bought my first MikroTik RB952UI-5AC2 running 6.45.7, and I almost got everything to work, but I am having a bit of trouble with an openvpn tunnel. The layout is as follows:
What works!
The tunnel is up, and the routers can ping each other.
Clients from the pfsense side in (172.17.0.0/24) can ping the openvpn interface on the mikrotik (10.30.30.2).
On the mikrotik router, one can ping clients in 172.17.0.0/24, as long as it it is done from the ovpn-out interface.
What does not work
Clients in 192.168.88.0/24 can ping 10.30.30.2 but not 10.30.30.1 (pfsense ovpn if)
Clients from 192.168.88.0/24 cannot ping clients in 172.17.0.0/24
On the mikrotik router from LAN if (192.168.88.1), one cannot ping 10.30.30.1 or 10.30.30.2
You are missing routes at pfsense towards the 192.168.88.0/24. Be aware that it’s not enough to set them in the kernel routing table (indicating the openvpn TUN interface as a gateway), but the openvpn configuration must contain routes too - the kernel routing table sends the packets to the openvpn process, but the openvpn process must route them to the proper client (assuming that the pfsense acts as a server and Mikrotik acts as a client, I haven’t found this information in your post).
Mikrotik’s implementation of openvpn deals with this automatically (which is unfortunately more than compensated by its drawbacks).
I didn’t get the difference between the two cases below:
Did you mean, by the second one, that you ping from the Mikrotik itself but with interface=LAN? If so, that’s no surprise
Thank you for the reply.
I have double checked on the pfsense box, the routes towards 192.168.88.0/24 is there both in the kernel routing table and in the openvpn config.
On the Mikrotik everything is in the same common block of configuration data, so /export hide-sensitive (see my automatic signature below for further anonymisation hints) is what to post if needed.
However, what I was actually interested in was the client configuration file for the Mikrotik client which is located in the /var/etc/openvpn-csc/server2 directory on the pfsense, because that’s the place where the route to 192.168.88.0/24 must be placed, in addition to the kernel routing table. And the keyword for this (telling the OpenVPN server’s internal routing tables that some subnet is reachable via a particular client connection) is iroute.
I did some further debugging on the pfsensebox using package capture.
In this test I have a client (172.17.0.20) connected to the LAN interface of the pfsensebox pinging the mikrotiks lan if 192.168.88.1, interestingly enough I can see packages leaving on the pfsenses openvpn interface, but there is no answer back from the microtik router.
21:34:03.075111 IP 172.17.0.20 > 192.168.88.1: ICMP echo request, id 31070, seq 0, length 64
21:34:04.076204 IP 172.17.0.20 > 192.168.88.1: ICMP echo request, id 31070, seq 1, length 64
21:34:05.080231 IP 172.17.0.20 > 192.168.88.1: ICMP echo request, id 31070, seq 2, length 64
That must mean, that routing is indeed working and is configured properly on the pfsense end.
There is no specific client configuration file in that directory ( /var/etc/openvpn-csc/server2 ) on the pfsensebox.
That’s a wrong conclusion. The packets carrying the ICMP requests towards the Mikrotik are encrypted ones, so even if you would see them on their way to the Tik, you would not see the actual destination address, only the public one of the Tik, and you would see them as TCP packets, not ICMP ones.
What you actually see are the plaintext packets on their way from the kernel to the OpenVPN process, on the single common TUN (or TAP, it’s not relevant for this) virtual interface, which the OpenVPN process uses for traffic to/from all clients, rather than creating an individual one per each client. Hence it must itself know which traffic received through this single common virtual interface to send through which tunnel. And this is what the iroute directive in a client configuration file is required for. Without this piece of its internal configuration, the OpenVPN process only knows the addresses of the clients which it has assigned to them (in your case, the 10.30.30.2), but not addresses of subnets of those clients.
Sure, because you haven’t created one. Find out how it should look like, put the iroute 192.168.88.0/24 into it, reconnect the Tik and you should be good.
