I have 2 spots 1 hub and 1 spoke. I want to all route to vpn. IPsec site to site vpn its ok everything fine but cannot ping mikrotik on LAN spoke side but everythings fine on hub side. how can resolve this issue?
/system routerboard settings
set auto-upgrade=yes
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
I’m not sure I have understood properly what is your issue, but I assume wht bothers you is that if the devices in 192.168.14.0/26 ping 192.168.14.3 (the own address of the spoke Mikrotik in that subnet), they get no response.
If that’s indeed the case, the explanation is that IPsec policies override the results of regular routing, and there are no automatic exceptions from that. Since your only IPsec policy matches on dst-address=0.0.0.0/0 src-address=192.168.14.0/26, the ping response whose source address would be 192.168.14.3 and destination address would be 192.168.14.n would match this policy, the policy would intercept such a response and send it to the peer using the tunnel mode SA. However, no such response is actually ever generated, because the IPsec stack drops already the incoming request from 192.168.14.n to 192.168.14.3. The reason is that IPsec is not just a communication protocol but an overall security concept, and the concept mandates not only that if an A->B packet matches a policy, it must be sent out using an outbound SA created by that policy, but also that any incoming packet reverse-matching a policy (i.e. B->A one for an A->B policy) is only accepted if it has arrived via the inbound SA created by that policy, otherwise it must be dropped.
So what you have to do is to add a policy dst-address=192.168.14.0/26 src-address=192.168.14.0/26 action=none before (above) the dst-address=0.0.0.0/0 src-address=192.168.14.0/26 action=encrypt … one. The IPsec stack processes the policies top to bottom until the first match, like firewall rules, so the first policy will prevent the LAN traffic from getting diverted (or dropped, depending on direcion) by the second one.
No, the traffic selectors inspect the packets after they have passed through regular routing and all firewall chains and the only remaining step is to send them out via the chosen interface and gateway (and also right after they have been received from the outside on an IP interface, before any firewall handling has been applied).
If by “rules” you mean the policy with action=none, then the traffic between the Mikrotik itself and hosts in the LAN subnet will flow the same way like without IPsec and the traffic between the LAN host and any other subnet will get encrypted and flow through the IPsec tunnel to/from the hub.
No, because only policies with action=encrypt are negotiated between peers. action=none or action=discard policies are local ones.
@Sindy, I’m trying to simulate this. from site a I want to exit through ipsec of site 2. so my lan of site A (10.246.159.0/24) uses ipsec as gw.
on the site A have the following configuration:
phase two goes up on both but the traffic directed towards the internet always exits the pppoe gateway of office A instead of going through ipsec to office B. where am I wrong? Do I also need a change on the routes port?
I’d say you forgot to set tunnel to yes in the action=encrypt policies. After fixing that, export again to see whether that omission has not caused any other change and if needed, fix that manually.
I wrote it wrong but in reality it is set as I have corrected the code now. I still go to the internet using location gateway A instead of B via ipsec.
IPsec is looking for its prey as the last but one step of packet processing, i.e. just before the packet would get sent out via the chosen interface, after even src-nat has already done its job. So if you haven’t excluded the 10.246.159.0/24 → internet traffic from the effect of the action=srcnat or action=masquerade rule, e.g. by adding an ipsec-policy=out,none match condition to that rule, the packets will get src-nated to the WAN address and therefore become invisible for the traffic selector of the policy.
The order of the firewall rules matters, and you have only shown one of them. So the one you’ve posted is the first one and after (below) it is the original action=masquerade one with no extra conditions (as you say you have inserted it), the first (inserted) one does nothing so the second (original) one does the same it did before.
Anything that comes from a private address and goes to the internet via WAN has to be src-nated (masquerade is src-nat with extra handling for dynamically changing WAN addresses).