MikroTik

I have a mikrotik 493 that establishes a site-to-site tunnel with another appliance.

The mikrotik 493:
Remote Appliance: This is what my mikrotik ipsec config looks like: This effectively establishes my site-to-site tunnel, and forces anyone behind my mikrotik router to connect over the VPN tunnel.

My problem is this: I need to be able to control what traffic is allowed to go out the tunnel, and what traffic goes out to the internet without going through the tunnel.

Ex based on source IP: If the source IP is 192.168.1.50, send its traffic through the VPN tunnel - otherwise, send it directly to the internet.
Ex based on dst IP: If the destination IP is 172.16.16.1, send the traffic through the VPN tunnel - otherwise, send it directly to the internet.

Either method should work for me.

I tried replacing 0.0.0.0/0 in my ipsec policy with 172.16.16.1/32, but when I do, the ipsec tunnel can no longer get established.

What am I missing?

It seems that if the ipsec connection is already established, changing the ipsec policy from 0.0.0.0/0 to 172.16.16.1/32 works great. If I reset the connection with that in place however, it fails to establish the tunnel. The logs on the remote end say "System did not accept any proposal received." Shouldn't changing the policy not change the proposal?

Adding a policy to send igmp through the tunnel seems to help, but does not fix the problem entirely.

Fixed with a workaround.

In case anyone else comes across the same problem:

Basically I have 3 scripts on the 493:

vpn_enable
vpn_disable
vpn_watcher

vpn_enable sets a flag on the 493 that indicates that the admin wants the vpn configured.
vpn_disable sets a flag on the 493 that indicates that the admin does NOT want the vpn configured.
vpn_watcher gets run every 30 seconds by the scheduler, checks to see if a vpn can be successfully established, and if it can, configures the vpn.

The trick was this: if vpn was disabled, and someone ran vpn_enable to enable it, then the next time vpn_watcher ran, it needed to figure out whether a vpn tunnel could successfully be established without distributing the flow of traffic. It needed to create temporary vpn policies that would allow it to ping across the vpn tunnel to see if the tunnel could be successfully established, and if this test passed, it would remove the temporary vpn policies and add permanent vpn policies that would route everyone behind the router through the tunnel. This would mean that if the VPN gateway happened to be offline, vpn_watcher would check every 30 seconds if it came back online without disturbing traffic. As soon as the VPN gateway was back online, it could then route everyone through the tunnel again.

While the permanent policies were fairly easy, the temporary policies that allowed the 493 to ping across the tunnel while not actually routing anyone behind the 493 through the tunnel was more challenging. My first thought was to create a policy that would only allow the ICMP traffic destined to 172.16.16.1 (the local IP of the remote VPN gateway) through the tunnel. Making such a policy made the VPN tunnel fail to establish however. It turned out that when you create an ipsec policy on a 493 and set the protocol to ICMP, you are actually changing the proposal being sent to the remote VPN gateway. If the VPN gateway is configured to allow ALL protocols through the tunnel, and the policy on the 493 is set to only allow ICMP traffic through, this results in a proposal mismatch. I also tried setting an ipsec policy that would route all protocols to 172.16.16.1 through the tunnel, and nothing else, but that didn't work either.

In the end, this is what I did:

I created an ipsec policy that routed traffic destined to 0.0.0.0/0 (any destination), with any protocol to 172.16.16.1. I set this policy with priority 0. I then created 2 more policies: one that took the action of "none" on any traffic destined to 0.0.0.0/0 with protocol UDP, and one that did the same with protocol TCP. I set both these policies with a priority of 1 (higher than the initial policy). This resulted in ICMP traffic destined to 172.16.16.1 going through the tunnel, while most of the normal traffic (like web browsing) not going through the tunnel. This allowed me to ping 172.16.16.1 without disturbing the normal flow of traffic.

I hope that makes sense, and helps someone at some point. If anyone figures out a better solution, I'd love to hear it.