Hi guys,

I'm trying to setup an IPSEC tunnel between a Mikrotik and an ISP controlled IPSEC tunnel.

They've provided me with the public peer IP, IKE1 details, IPsec transform set, IPsec profile etc. And using this I've been able to get it to the point where the tunnel is established.

我的问题:
1)如何将子网路由添加到我的肾阳ting table? If I just add a route using their public peer IP as the gateway, the Mikrotik reports that the gateway is unreachable even though it can be pinged.
2) Do I have to create a VPN over and behave so that I have an interface which I can use in the routing table? They haven't provided me with any details for such a VPN.

/ip ipsec policy> print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes

1 A src-address=192.168.0.0/24 src-port=any dst-address=152.204.136.32/27 dst-port=any protocol=all action=encrypt level=require ipsec-protocols=esp tu
sa-dst-address=123.123.123.123 proposal=ISPproposal ph2-count=1

/ip ipsec peer> print
Flags: X - disabled, D - dynamic, R - responder
2 address=123.123.123.123/32 local-address=192.168.0.1 auth-method=pre-shared-key secret="mykey" generate-policy=port-strict policy-template
send-initial-contact=yes nat-traversal=no proposal-check=exact hash-algorithm=sha1 enc-algorithm=aes-256 dh-group=modp1024 lifetime=1d dpd-inte

With the Mikrotik, IPSec does not create a virtual interface (many people requested it, but have to use IP in IP, L2TP, PPTP, etc instead), and you don't need to add any routes.

The packets head for the default route, but the IPSec policy matches the source/dst subnets, and does what it needs to do.

Thank you carl0s, I see, so I don't have to worry if I don't see a route to that network in the routing table. I have one more thing that I can try to fix the issue. At the moments my ping to the dst-net time out.

Thank you carl0s, I see, so I don't have to worry if I don't see a route to that network in the routing table. I have one more thing that I can try to fix the issue. At the moments my ping to the dst-net time out.

If you are pinging from the Mikrotik itself, make sure you set src-address so that it matches the policy.

For example, here I am pinging the remote router over IPSec tunnel, but first attempt I do not set the src-address. On the second attempt, I set the src-address to my local router's LAN IP, so it matches the ipsec policy

You also need to exclude the IPSec subnets from the masquerade natting rule.

there's a few articles about that. in my instance here, I have just set !192.168.88.0.24 in the destination address of my standard internet-masquerade src-nat rule.
The preferred way though is to add an entry into the Firewall->Raw area that accepts the packets.. this stops them hitting the nat chain or something.

Wow carl0s, you are awesome. Thanks mate.

I am getting really close now.

With the tunnel established, if I ping the IP within the subnet using the src-ip of the ipsec tunnel I get a reply. But the reply comes back from one of my local interfaces instead of the remote IP.

Basically my router has a common IP on the LAN port, but it has a PTP IP to the actual internet router as well. The ping reply comes from the local PTP IP instead of the remote tunnel IP.

I've managed to get the tunnel working. What I had to do was to add a separate NAT rule which masqueraded traffic from my local LAN heading towards the ipsec traffic so that it uses the routers IP which the tunnel allows.

My final issue now is that it does not look like I can add multiple destination subnets to one IPSEC tunnel. It would be unfortunate if I have to create three tunnels to reach all three subnets. Any ideas?

not three tunnels but three policies, or maybe you can "summarize" your 3 remote subnets into one bigger supernet

not three tunnels but three policies, or maybe you can "summarize" your 3 remote subnets into one bigger supernet

Unfortunately one big supernet isn't really an option unless I want to risk cutting out a lot of potential Internet IPs.

so go the three policies way
Another option would be ike2 which is currently going to support multiple split-networks (see last rc changelog)