There a quite a few posts on this topic, but I have not been able to flush out a solution. I have a working IPSEC Tunnel. I can successfully communicate between LAN1 and LAN2. What I’m attempting to accomplish is to route traffic from LAN 1 over the tunnel and out WAN 2. One suggestion that made sense was to add a default route of 0.0.0.0/0 with gateway of LAN2, but it shows unreachable. One further not is LAN1 is behind another router I don’t have control of, but I was able to get that tunnel up.
The topic is actually simple. There are two possible ways how to use IPsec for site-to-site traffic:
the “bare” one, where the traffic selectors of policies are used to choose packets to be sent via the tunnel, which overrides the results of the “normal” routing (but there must be some result of the normal routing, otherwise the packet does not reach the stage where traffic matching is applied)
the “encrypted tunnel” one, where IPsec is only used to encrypt transport packets of some point-to-point tunnel (IPIP, GRE, L2TP, …); in this case, the tunnels have virtual interfaces and can be used by the “normal” routing
Depending on your choice from the two methods above, you either have to change the dst-address in your policy from 172.25.17.0/24 to 0.0.0.0/0 in order that all the traffic from your LAN subnet was sent to the remote site, or you have to change the setup and create an IPsec-encrypted IPIP tunnel between the sites (so the policy will only match on a single IP at local side and a single IP on the remote side, which will be used as endpoint addresses of the tunnel) and use the normal routing to make the IPIP tunnel the default gateway for all traffic (but then you need a dedicated route towards the public IP of site 2, otherwise the traffic would loop into itself).
If you want to stay with traffic matching, you have to place a policy with action=none src-address=192.168.89.0/24 dst-address=192.168.89.0/24 before the one with action=encrypt src-address=192.168.89.0/24 dst-address=0.0.0.0/0, to prevent packets from the LAN hosts to the router and vice versa from being matched by the traffic selector and sent to the remote site. On site 2, this is not necessary as the policy with src-address=0.0.0.0/0 dst-address=192.168.89.0/24 will not match to any local traffic (except the one towards LAN1 which is desired to be matched).
@Sindy, I tried your suggestion to route All the LAN1 traffic out of WAN2 (staying with traffic matching method). It works ! But when looking into the link, https://wiki.mikrotik.com/wiki/Routing_through_remote_network_over_IPsec
it seems the application is one specific device (10.10.10.23) in LAN1 (10.10.10.0/24) route its traffic out of WAN2 , the rest IP still route through WAN1. If this is the case, is there anyway to achieve it (without the help of other PtP tunnel) ?
Currently, I use L2TP/IPsec to achieve it , but just curious to know if we can do it without other PtP tunnel.
It wasn’t clear from your previous post whether the fact that the default route via remote site (WAN2) applies only for a single IP in your LAN subnet is something you want or something which is described on the wiki you refer to and you want something else.
So looking at the drawing, I assume that you want the tunnel to work only between site 1 LAN and site 2 LAN for most devices, but that single device in site 1 LAN should use it also to access internet via site 2’s WAN.
If so, you need an individual policy for that single device, example: src-address=10.20.30.40 dst-address=0.0.0.0/0 …
src-address=10.20.30.0/24 dst-address=10.11.12.0/24 …
The policies are matched the same way like firewall rules or routing rules, top to bottom until first match. In this case, the order is not relevant, because it doesn’t matter whether packets from 10.20.30.40 to 10.11.23.0/24 will be sent using one or the other SA.
Hi Sindy, thank you for your reply ! I tried to add this policy for a specific IP in the subnet , but seems doesn’t work.
My setup is :
Router G: wanip-10.10.10.66, subnet-192.168.3.0/24
Router N: wanip-192.168.99.149 subnet-192.168.4.0/24, PC in the subnet: 192.168.4.254
After I config the ipsec tunnel between Router G and Router N, it is up and running. But if I add the extra policy, it doesn’t work. Did I miss something in the config ?
[brg3466@N] > ip ipsec export
# nov/23/2020 17:25:46 by RouterOS 6.47.4
# model = 951-2n
/ip ipsec peer
add address=10.10.10.66/32 exchange-mode=ike2 local-address=192.168.99.149 name=ike2-G
/ip ipsec identity
# Suggestion to use stronger pre-shared key or different authentication method
add peer=ike2-G secret=test
/ip ipsec policy
add dst-address=0.0.0.0/0 peer=ike2-G sa-dst-address=10.10.10.66 sa-src-address=192.168.99.149 src-address=192.168.4.254/32 tunnel=yes
add dst-address=192.168.3.0/24 peer=ike2-G sa-dst-address=10.10.10.66 sa-src-address=192.168.99.149 src-address=192.168.4.0/24 tunnel=yes
[brg3466@N] > ip ipsec policy pr
Flags: T - template, B - backup, X - disabled, D - dynamic, I - invalid, A - active, * - default
# PEER TUNNEL SRC-ADDRESS DST-ADDRESS PROTOCOL ACTION LEVEL PH2-COUNT
0 T * ::/0 ::/0 all
1 I ike2-G yes 192.168.4.254/32 0.0.0.0/0 all encrypt require 0
2 A ike2-G yes 192.168.4.0/24 192.168.3.0/24 all encrypt require 1
So try to disable and re-enable the peer, there are sometimes surprises if policies are added after phase 1 has already started (but in my case, I’ve added both policies this way and got no issues). The mutual order of these two policies also plays no role in my case.
If the disabling and re-enabling the peer doesn’t help, try with 6.46.8 (which is the latest long-term release as of writing this, on which it works for me).
I assume you do have matching policies at the remote peer. Even if you didn’t, the policy should still be just inactive, not invalid.
@Sindy, thank you so much and really appreciate your time !
The disable/enable played the trick. Finally it is up ! In order to let the PC go out of Router-G WAN, have to add one NAT rule.
while I route all the traffic of 192.168.4.0/24 through router G’ WAN, it is suggested to add one " action=none…" policy before the “action=encrypt …” policy. But in 192.168.4.254 case, any traffic from 4.254 will go through the tunnel and I didn’t add this ‘action=none …’ policy but 4.254 still can winbox the router-N. (192.168.4.1). why it doesn’t lose the access to router-N ?
before your solution, I tried another approach but failed. I used mangle rule for 192.168.4.254, and then add one static route but it doesn’t work. why the remote router G gateway doesn’t work ?
Because this recommendation is only relevant for cases where the dst-address of the action=encrypt policy includes the LAN subnet and the src-address includes the router’s own address in the LAN subnet. But the dst-address of the policy for site1 LAN - site 2 LAN doesn’t include site 1 LAN subnet, and the src-address of the policy for 192.168.4.254 to the whole internet doesn’t include router’s own IP address, so none of the two policies redirects packets sent by the router to the 192.168.4.254 host.
\
Would it be possible that you incorrectly understand how routing works? When a route with an IP address as a gateway is chosen, it does not mean that the destination address of that packet is changed to the address of the gateway. It just indirectly tells the router which interface to use and if that interface is a point-to-multipoint one, to what remote host accessible through that interface to hand over the packet for delivery.
As the destination address of the packet doesn’t change to 192.168.3.1, the policy matching on 192.168.3.1 ignores that packet.
