MikroTik

Hello all,

I have several RB2011 devices connected to a central office using IPSec in tunnel mode.

Each remote site has a 192.168.x.0/24 network. The existing IPSec policy has src-address=192.168.x.0/24 and dst-address=192.168.0.0/16. Using this setup each remote site can communicate through the central office. This is all working fine.

Now I want to add a new subnet (172.16.0.0/12) at the central office. I want the local (at the remote site) network 192.168.x.0/24 to send traffic to 172.16.0.0/12 over the IPSec tunnel.

So far, I have added a new IPSec policy with src-address=192.168.x.0/24 and dst-address=172.16.0.0/12. It uses the same sa-src-address/sa-dst-address as the working tunnel. I also added the new network into the central office tunnel configuration.

If I try to ping through the tunnel (from remote to central office), I get a response from the remote location ISP of "admin prohibited." This is expected if the packet is not being encapsulated in the tunnel.

I tried adding a static route for the 172.16.0.0/12 network with the gateway of the central office public IP. This did not seem to change anything.

The remote end is RouterOS 5.x device. The central office is a WatchGuard device.

Can someone show me what I am missing?

Thank you,
James

Did you add the new policy to both ends of the tunnel?

Yes. Both ends of the tunnel have been updated. The central office is a WatchGuard so the terminology is not the same as MikroTIk devices, but the settings match.

I am familiar with Watchguard as well and think they are a real pain in the ass. Why not switch it out for a MikroTik?

Anyway, post /export compact of the MikroTik and we can make sure that side is correct.

I made a little progress.

I am actually using the 172.20.0.0/16 subnet of the 172.16.0.0/12 network. Just on a whim I tried to change my tunnel config to be 172.20.0.0/16.

After changing both ends, I can ping from the WatchGuard end to the RB end.

Thank you,
James

After getting traffic from the WatchGuard (central office) through the tunnel to the RB, I started thinking over my RB setup.

In the RB, I have two rules that prevent traffic that should go over the IPSec tunnels from getting NATed. Here are the rules:

ros code

add action=accept chain=srcnat comment=\
    "Do not NAT packets headed for IPSec tunnels" disabled=no dst-address=\
    192.168.0.0/16 src-address=192.168.101.0/24
add action=accept chain=dstnat disabled=no dst-address=192.168.101.0/24 \
    src-address=192.168.0.0/16

I copied these rules and added two more for the new network:

ros code

add action=accept chain=srcnat comment=\
    "Do not NAT packets headed for IPSec tunnels" disabled=no dst-address=\
    172.20.0.0/16 src-address=192.168.101.0/24
add action=accept chain=dstnat disabled=no dst-address=192.168.101.0/24 \
    src-address=172.20.0.0/16

Traffic is now flowing in both directions over the tunnel.

There may be a better way to keep IPSec packets from getting NATed than my rules, but they seem to be working well.

Thank you,
James