I’m new to Mikrotik and I need to perform site-to-site VPN.
I configured pfSense as an OpenVPN server running on the matrix.
The VPN is active. In the subnet next to the Mikrotik I can access all the services of the matrix, but from the matrix, I cannot access any IP of the subnet after Mikrotik.
I believe it is some rule of Mikrotik, but I am not able to configure.
Some help?
Route
[admin@MikroTik] > ip route print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 192.168.1.1 1
1 A S 172.18.1.1 1
2 ADC 10.2.26.1 bridge 0
3 ADC 172.18.1.0/24 172.18.1.2 ovpn-out1 0
4 ADC 192.168.1.0/24 192.168.1.2 ether1 0
[admin@MikroTik] > ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 X chain=srcnat action=accept src-address=10.0.0.0/15 dst-address=10.2.26.0/24 log=no log-prefix=""
1 X chain=srcnat action=accept src-address=10.2.26.0/24 dst-address=10.0.0.0/15 log=no log-prefix=""
2 chain=srcnat action=masquerade log=no log-prefix=""
3 ;;; defconf: masquerade
chain=srcnat action=masquerade out-interface-list=WAN log=yes log-prefix="masquerade " ipsec-policy=out,none
4 X chain=srcnat action=accept log=yes log-prefix="nat "
Follow the hint in my automatic signature right below. The few bits of information you’ve posted are insufficient for any analysis. Also, does “the subnet next to the Mikrotik” mean the same as “the subnet after Mikrotik”?
But with some qualified guess: a common mistake is that people forget to tell the OpenVPN server through which client to route traffic to which subnets. See this post for details. As you have disabled the rules excluding the inter-site traffic from getting masqueraded, whatever is sent from 10.2.26.0/24 via the OpenVPN tunnel gets src-nated to 172.18.1.2, which is the address assigned by the OpenVPN server to the Mikrotik, so the server sends the responses to this address and Mikrotik un-src-nats them and forwards them to the actual destination. For connections initiated in the opposite direction (client/initiator in matrix and server/responder in Mikrotik’s LAN), this does not work and the initial packets of these connections never reach the Mikrotik for the reason explained above.
a listing of subnets is not a configuration export. Some of the NAT rules you’ve listed seemed to be random shots so without the complete picture it is impossible to suggest anything.
any prerouting rule in Mikrotik cannot help if the issue eventually is at the pfSense side (as I suspect). Can you post your openvpn client configuration file for the Mikrotik client as set at the pfSense side?
please have a look what connection tracking in ipfilter (iptables) is and how is it related to NAT.
OK, so it seems that like Mikrotik, pfSense has some user-friendly front-end to the actual OpenVPN configuration files which obfuscates what is actually set up under the hood.
If LAN_COMPANY translates to 10.0.0.0/15 somewhere, and LAN_BRANCH translates to 10.2.26.0/24, the settings are correct at pfSense side.
If you say there are no rules whatsoever in Mikrotik’s firewall, there is also no reason why the incoming connections from LAN_COMPANY to LAN_BRANCH should be blocked at Mikrotik side.
As pfSense is a blackbox, I can only recommend to start pinging from LAN_COMPANY to LAN_BRANCH with some 500 byte packets (to be distinguishable from normal TCP packets with payload which will be larger and from just ACK packets which will be smaller) and sniff on the WAN of the Mikrotik for the OpenVPN transport packets carrying these 500-byte pings, to see whether the issue is already at the pfSense end (not sending them) or at the Mikrotik end (not forwarding the received ones).
If you restrict the “masquerade everything” rule only to what exits via WAN, can you still reach addresses in LAN_COMPANY from LAN_BRANCH or not any more?
If I put NAT only for the WAN, I won’t drop the company.
I put a Packet Sniffer on the Mikrotik on all ports and fired a ping from pfSense, and nothing reaches Mikrotik.
The strange thing is that if I change the Mikrotik to another router with OpenWRT and the connection happens on both sides.
So I thought that the problem could be Mikrotik.
However, as nothing arrives in Mikrotik, I think it’s pfSense. But the strange thing is that with OpenWRT it works.
If you say that even without masquerading the traffic from the Mikrotik’s LAN through the OpenVPN tunnel, the sessions initiated by clients in Mikrotik’s LAN towards servers in company LAN succeed, it cannot be a routing problem, because without the masquerade rule, the requests arrive to the company side with the actual addresses of the clients in the Mikrotik LAN, so the responses are sent towards these real addresses. So if you can sniff at some server in company LAN and double check that it really can see packets coming with source addresses from 10.2.26.0/24, we can move further, but this is the very first step to do, to know what we’re actually looking for.
Is this intentional or just a secondary effect of something?
No, as if it was, the connections from clients in Mikrotik’s LAN to servers in pfSense’s LAN would fail was well. As they don’t, routing must be OK in both directions. But I am still not sure whether it’s not thanks to the masquerade at Mikrotik end, which would hide the existence of 10.2.26.0/24 from the pfSense end as everything from there would be masqueraded behind 172.18.1.2 for connections initiated from Mikrotik side. For connections initiated from pfSense side, the masquerade rule at Mikrotik side does nothing, and wouldn’t do anything even if those packets reached the Mikrotik (well, it would masquerade the packets as they would leave Mikrotik towards the device in its LAN if it wouldn’t care about the out-interface).
As you say that pings to something in 10.2.26.0/24 from pfSense side do not spawn OpenVPN transport packets from pfSense to Mikrotik, either the pfSense’s firewall blocks these requests, or the OpenVPN at pfSense doesn’t know that 10.22.26.0/24 is accessible via 172.18.1.2.
So to check whether the masquerade acts or not on the tunnel interface, open a command line window on the Mikrotik, make it as wide as your screen allows, and run /tool sniffer quick interface=ovpn-out1 ip-protocol=icmp in it. Then start pinging from something in 10.22.26.0/24 to something in 10.0.0.0/15, and see what the sniffer shows, maybe post the result here.
I don’t know why you keep ignoring the information that from the random bits of the configuration you choose to post about the problem, no one is able to find out enough information to help you. Until you post the complete anonymized configuration of at least the Mikrotik (see my automatic signature below on how to do that), you won’t get any useful advice.
Next, as you mix and match products of two distinct vendors (nothing bad about that), the Mikrotik-speaking crowd can only help you with the Mikrotik side. However, it seems that the issue you experience with the IPsec setup could be easier to handle as in this case, the root cause is more likely at Mikrotik end.
In this configuration, change the action in the action=masquerade chain=srcnat dst-address=10.0.0.0/15 log=yes log-prefix=teste src-address=10.2.26.0/24 rule in /ip firewall mangle to accept and you should be fine. Even if it is not sufficient, doing this is still necessary.
The point is that the IPsec traffic selection (matching of an outgoing packet to policies’ traffic selectors) is done as the very last step, after all the other packet processing including NAT has been done.
The NAT handling is chosen per connection, and the choice is done as the very first packet of the connection is handled. So
if the initial packet of the connection comes from the pfSense side, no NAT handling is chosen for that connection, and thus the source address of the response packets in this connection is not modified, and they match to the policy’s traffic selector. As connection initiated from the pfSense side work, the policy matching must be working fine.
if the initial packet of the connection towards an address in 10.0.0.0/15 comes from Mikrotik’s LAN, the “normal” routing finds a route through ether2 (which is the LAN again), so in the better case, the masquerade rule assigns Mikrotik’s own address at this interface as a source one to all downstream packets of this connections, in a worse case I have no idea which address it uses, but you can see that by running a ping and then having a look using /ip firewall connection print detail where protocol~“icmp” and look at the reply-dst-address. If the new address is 10.2.26.1, the IPsec policy does match, and it must be the firewall at pfSense side what blocks these connections; if some other address is eventually assigned, the IPsec policy doesn’t match.
OK, in that case, changing that rules’ action from masquerade to accept should resolve the issue. You have to stop the ping and let the connection time out (10 seconds are enough) before trying again after changing the rule - the s which stands for src-nat should not be shown, and the reply-dst-address should be the same like the src-address.
