I have created two IPsec tunnels from Site A and C to a router at Site B. How do I achieve so traffic from Site A can reach Site C and vice versa? Do I need to create a IPsec tunnel between the Site A and C directly?
I also found two earlier topics related to what i trying to achieve.
You can build a tunnel between A and C or you can permit their traffic to go over both tunnels and include routes on A and C so they know where to send the traffic.
In other words:
Router ‘A’ will need a route pointing to the tunnel between ‘A’ and ‘B’ to reach 192.168.30.0/24
Router ‘C’ will need a route pointing to the tunnel between ‘C’ and ‘B’ to reach 192.168.10.0/24
On Routers ‘A’, ‘B’, ‘C’ - you have to ensure that the traffic is allowed over the tunnel
You can enable OSPF to handle the routing over the tunnels and simply the process further.
IPSec tunnels can be a little confusing. It’s not normal routing as with simple tunnels. It just “steals” and encrypts selected packets according to defined policies. The natural thing that everyone does (at first) is that they create IPSec tunnel between A and B (.10.0/24 ↔ .20.0/24) and another tunnel between B and C (.20.0/24 ↔ .30.0/24). They work great individually. But when you try to reach .30.0/24 from .10.0/24, it doesn’t work, because tunnel between A and B does not take .30.0/24.
You can do two things:
a) Add more policies to cover all possible traffic (in this case .10.0/24 ↔ .30.0/24 for both tunnels) and set level=unique.
b) Switch IPSec to transport mode, create IPIP/EoIP/GRE tunnels between routers and only encrypt those using IPSec. It will give you normal network interfaces you can work with the same way you’re used to.
a) I did so at every site (found another thread http://forum.mikrotik.com/t/ipsec-between-3-sites/62636/1), but I cannot get the sites to talk to each other. I also created the same setup for the firewall and NAT at each site. But the funny thing is that I can see traffic flows by looking at the counters.
The basic setup is ok, just make sure that you didn’t accidentally swap src/dst-address in those .88 ↔ .0 policies. NAT and firewall is different matter, they can surely both break things. But you know what should and shouldn’t happen, so it should be easy to check (logging rules put in different chains should work nicely for that).
Clearly I have done something wrong in the configuration (I believe somewhere in filter rules or NAT) as I cannot figure out why the traffic will not pass over via Site B. On the other hand, this type of setup is rather confusing, maybe it’s better to approach a setup that are decentralized (where the routers connects to each other instead).
No, the best is not to use IPsec tunnel mode but to use a tunnel interface over IPsec transport, as already suggested above.
But you don’t want it, so…
I am using BGP, but OSPF would be possible too.
Just make as many point-to-point tunnel interfaces as you need or like (star, partial mesh, full mesh) and put a /30 network on each of them.
(e.g. 192.168.255.1/30 at one end and 192.168.255.2/30 at the other end, next one is .5/.6)
Then define Peer and Network in BGP or whatever is required in OSPF (I don’t know) and all routing is automatic.
But it really shouldn’t be hard to find it. If you try to ping between A and C (in both directions), you’ll see immediatelly if those new A<->C policies between A and B and B and C work. If so, then it’s either firewall filter or NAT. So either log rejected packets in forward (if you have default drop/reject rule) or add accept rules between A and C subnets before all others and see it it starts to work. If not, then it should be NAT and with clearly defined source and destination, finding the offending rule should be easy, unless you have tons of them.
In case of just three sites, I’d add direct link between A and C and let traffic between them take shorter way. But if you’d have more sites, then this does not scale well.
The advantage of tunnels secured using IPSec transport mode is that all the following stuff is simple, it’s just like if you had ethernet links.
