I've got to the stage where the more I read the more I get confused on this one!
I have 2 sites linked via IPsec and working fine. I can access LAN sites on network 2 from network 1 and visaversa. However I want to be able to forward to the 2nd site traffic that is destined for a public address, for simplicity sake lets say 8.8.8.8. Other than add a new policy which encrypts traffic from network 1 lan range to 8.8.8.8 and a matching firewall accept rule what would I need to do? I've tried adding a static route and setting the gateway to that of the router on network 2 but it shows unreachable. (Ping works fine)
Re: Another IPsec Tunnel question [SOLVED]
You should only use bare IPsec for simple cases, as you need a dedicated policy for each combination of local and remote subnet.
So for more complicated scenarios, it is always better to use IPsec only to encrypt the transport packets of some tunneling protocol like IPIP, GRE, or L2TP, and use the "normal" routing instead of IPsec policies. Many vendors have implemented a virtual tunnel interface (VTI) for IPsec directly, but doing so voids a significant part of the overall security model of IPsec. Mikrotik does not offer VTIs as of now.
If you insist on the bare IPsec solution, indeed the extra policy for 8.8.8.8/32 is required, one per each source subnet on Site 1. Matching of packets to the traffic selectors of the policies takes place as the last step of packet handling, after the "normal" routing and even after the src-nat processing. So on site 1, some route to 8.8.8.8 must exist; if this route goes via some interface (typically, a WAN one) for which a src-nat or masquerade rule is configured, you have to exempt the traffic to 8.8.8.8 from the effect of that src-nat rule as changing the source address would cause the packet not to match the traffic selector.
At both Site 1 and Site 2 the firewall filter rules must permit the downstream (Site 1 -> 8.8.8.8) and upstream (8.8.8.8 -> Site 1) traffic, but that isn't specific for IPsec. What is specific for IPsec is that the in-interface of a packet that has arrived encapsulated in an IPsec transport one is the in-interface of the transport packet, but you can use a special match condition, ipsec-policy=in,ipsec or ipsec-policy=in,none, to distinguish between incoming packets that have been decapsulated from IPsec transport ones and those that haven't. In fact the process is more complicated - this match condition matches on packets whose source and destination addresses and ports match the traffic selector of any active policy (in case of received packets, the match must be a mirror one, the source address of the packet must match the dst-address of the policy etc.), and it is the IPsec stack itself that silently drops incoming packets that reverse-match any active policy but did not arrive encapsulated in an IPsec transport packet.
So for more complicated scenarios, it is always better to use IPsec only to encrypt the transport packets of some tunneling protocol like IPIP, GRE, or L2TP, and use the "normal" routing instead of IPsec policies. Many vendors have implemented a virtual tunnel interface (VTI) for IPsec directly, but doing so voids a significant part of the overall security model of IPsec. Mikrotik does not offer VTIs as of now.
If you insist on the bare IPsec solution, indeed the extra policy for 8.8.8.8/32 is required, one per each source subnet on Site 1. Matching of packets to the traffic selectors of the policies takes place as the last step of packet handling, after the "normal" routing and even after the src-nat processing. So on site 1, some route to 8.8.8.8 must exist; if this route goes via some interface (typically, a WAN one) for which a src-nat or masquerade rule is configured, you have to exempt the traffic to 8.8.8.8 from the effect of that src-nat rule as changing the source address would cause the packet not to match the traffic selector.
At both Site 1 and Site 2 the firewall filter rules must permit the downstream (Site 1 -> 8.8.8.8) and upstream (8.8.8.8 -> Site 1) traffic, but that isn't specific for IPsec. What is specific for IPsec is that the in-interface of a packet that has arrived encapsulated in an IPsec transport one is the in-interface of the transport packet, but you can use a special match condition, ipsec-policy=in,ipsec or ipsec-policy=in,none, to distinguish between incoming packets that have been decapsulated from IPsec transport ones and those that haven't. In fact the process is more complicated - this match condition matches on packets whose source and destination addresses and ports match the traffic selector of any active policy (in case of received packets, the match must be a mirror one, the source address of the packet must match the dst-address of the policy etc.), and it is the IPsec stack itself that silently drops incoming packets that reverse-match any active policy but did not arrive encapsulated in an IPsec transport packet.
Re: Another IPsec Tunnel question
Mikrotik really needs to support Route-based IPsec. This in-kernel policies are a nightmare to debug. Let the kernel do its job, give us XFRMi.