I have 3 sites, all of them using their own WAN (2 ISPs involved). Let’s say one of them is “more equal” than the other two and let’s call it “central” site.
So I created IPIP links between central site and both remote sites. The following shows config on the central site:
(I’m using the same ipsec-secret for both ipip interfaces).
Traffic between each remote site and central site works just fine. I can’t get traffic flowing between both remote sites though.
My attempt to debug things: on one of remote sites I’m running /tool traceroute . At the same time I’m running /tool torch dst-address= on the central router. If I select the IPIP interface which connects to the first remote site, I can see IP traffic coming from first remote site. If I select the other IPIP interface, I don’t see any traffic.
In the firewall list I don’t have any rule which would drop traffic from one IPIP to the other IPIP interface. Just for testing purposes, I added
/interface list
add comment="IPIP interfaces" name=IPIP
/interface list member
add interface=ipip-ces-nadolih list=IPIP
add interface=ipip-ces-savlje list=IPIP
/ip firewall filter
add action=accept chain=forward comment="IPIP to IPIP" in-interface-list=IPIP out-interface-list=IPIP
and pushed the firewall filter rule to the top (it’s right after the “special dummy rule to show fasttrack counters” rule). And the stats does show some traffic handled by this rule …
Don’t just accept those packets, log them, to be sure what exactly they are. In theory, there could be dstnat rule catching packets from first site, sending them back to first site and it would behave exactly as you describe it. Incoming packets in first tunnel, no outgoing in second, counter for forward rule increasing, everything. And since you timit torch only to one remote address, you wouldn’t see those packets forwarded back to first site either. I don’t know if it’s this, it sounds unlikely, but you need to be sure about every step taken by packet.
The problem I’ve had was combination of IPIP interface address and routes on each remote site. Consider this:
#
# remote site A
#
/ip address
add address=192.168.37.1/23 interface=bridge network=192.168.36.0
add address=192.168.255.253 interface=ipip-savlje-ces network=192.168.255.254
#
# remote site B
#
/ip address
add address=192.168.13.1/24 comment=defconf interface=bridge network=192.168.13.0
add address=192.168.255.255 interface=ipip-nadolih-ces network=192.168.255.254
/ip route
add distance=1 dst-address=192.168.36.0/23 gateway=ipip-nadolih-ces
So when I ran /tool traceroute 192.168.13.2 count=1 on RB site A, it actually used 192.168.255.253 as src-address … and router at remote site B doesn’t have a route matching it.
If I run /tool traceroute src-address=192.168.37.1 192.168.13.1 count=5 on RB site A (or traceroute on any other machine on site A), traceroute shows route just fine.
[user@routerA] > /tool traceroute src-address=192.168.37.1 192.168.13.2 count=5
# ADDRESS LOSS SENT LAST AVG BEST WORST
1 192.168.255.254 0% 5 9.3ms 10.5 9.3 14.3
2 192.168.255.255 0% 5 18.9ms 19.1 18.4 21.1
3 192.168.13.2 0% 5 21.3ms 22.7 18.9 34.9
user@hostA:~$ traceroute 192.168.13.2
traceroute to 192.168.13.2 (192.168.13.2), 30 hops max, 60 byte packets
1 192.168.37.1 (192.168.37.1) 0.363 ms 0.295 ms 0.228 ms
2 192.168.255.254 (192.168.255.254) 9.926 ms 10.194 ms 10.299 ms
3 192.168.13.1 (192.168.13.1) 19.966 ms 20.612 ms 21.521 ms
4 192.168.13.2 (192.168.13.2) 39.577 ms 40.849 ms 41.213 ms