I successfully created an IPSec tunnel between an IPCop and a Mikrotik (4.11) but it does not work right.
The tunnel came right up, and I can ping or pass any kind of traffic from behind the IPCop to the network behind the Mikrotik. However, when I ping from behind the Mikrtotik I get ‘destination unreachable’ errors and nothing TCP works.
I’m not an expert at this stuff, but one thing strikes me as really weird is a tracert from behind the Mikrotik:
Here is the tracert coming from behind the IPCop, which looks like I would expect:
C:>tracert 10.0.4.11
Tracing route to 110.0.4.11 over a maximum of 30 hops
1 15 ms <1 ms <1 ms 192.168.15.1
2 * * * Request timed out
3 32 ms 32 ms 31 ms SVR-DC-1 [10.0.4.11]
I have tried messing with as many things as I dare on a firewall in production, but nothing effects the basics above. Does anyone have any idea what could cause the issue described above?
I know this is a shot in the dark, but any help is greatly appreciated!
The short answer to your question is likely ‘No’ as I do not really understand how to do that. I am not very familiar with Mikrotik at all. I’ll see if I can find a way to do that from documentation.
When I was in the interface, I generated a supout.rif but wasn’t sure where that got placed. Is that the config file you are referring to?
Please generate the following output, and just copy/paste it here and place it within code tags: “/interface print detail”, “/ip address print detail”, “/ip route print detail”, “/ip firewall export”, “/ip ipsec export”, “/ip ipsec installed-sa print detail”, and “/ip ipsec remote-peers print detail”. Please also generate a network diagram (can be crude, but should feature all involved devices, links, names, and IP addresses). It would also help if you could post the settings from the IPcop box, though I’m not familiar with those so I’m not sure how you’d go about that.
That’s a lot of work. You can initially try the NAT exemption. The basic idea is that as per http://wiki.mikrotik.com/wiki/Manual:Packet_Flow#IPsec_encryption IPsec encryption happens after postrouting, which is also where source NAT takes place. Your IPsec connection is somewhat established since you can ping one way. Your policies include a source and destination network to encrypt. If you NAT out to the WAN, that happens before IPsec, so now the source address doesn’t match anymore. The other way around works because NAT is only evaluated on the first packet of the connection - therefore only it only fails due to NAT being applied when the RB initates the connection. Assuming that the network behind the IPcop is 1.1.1.1/24 and the network behind the RB is 2.2.2.2/24 (that’s the two networks mentioned in the IPsec policy, add an NAT exempt rule like so on the RB:
