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.
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.
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:
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/16I copied these rules and added two more for the new network:
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/16Traffic 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.