I’ve got a wierd scenario, which calls for a wierd setup and I’m having some trouble. I’m not sure if what I’m attempting is impossible, or if it’s just the implementation.
I’ve tried to simplify this as much as possible.
In the scenario above, there is an IPSec tunnel configured between routers A1 and B1 and another IPSec tunnel between A2 and B2.
Having performed test PINGs for this environment, I’ve essentially found that I can pass traffic between the devices that are explicitly connected via an IPSec tunnel, but I cannot ping devices which are not directly connected. For example:
I’ve performed tracing and found that the ICMP request is correctly passed from router A1, over the IPSec tunnel to B1 and then over the xconnect to B2, but B2 doesn’t generate an ICMP response. I’ve used both packet captures and firewall logging on the input and output chains to come to this conclusion.
Does IPSec on RouterOS forcibly apply some kind of connection tracking/enforcement?
This PaloAlto document, describes the same issue I’m seeing, but the limitation on the PaloAlto side seems to be related to firewall config, which would suggest this configuration isn’t inherently impossible within IPSec.
The IPsec standard requires that packets which reverse-match the traffic selector of any existing IPsec policy and did not arrive via the SA associated to that policy be dropped. So RouterOS silently drops them before they reach any firewall rule.
The thing is, the input packet does hit the firewall. If I create a filter rule on the input chain with an action of “log” I can see the packet come into the router.
If I modify the rule to apply to the output chain though, I see that no response is generated.
This is why I hate working with IPSec. I wish it could just stick to transport encryption and leave everything else such as routing decisions to other services. Unfortunately, the requirement to use it comes from a vendor, so I have no choice.
There was a similar topic about a year ago, and I have investigated it quite deeply back then; it is possible that I remember the details wrong, but it is a fact that packets which arrived the “wrong” way are dropped silently. Cannot find that topic any more, though.
You’re not alone. As @tippenring suggests here, and @pe1chl suggests in almost every topic related to bare IPsec, life is much easier with IPsec-encrypted tunnels like GRE or IPIP.
@Tippenring, unfortunately not, the “A” routers are managed by the vendor who are mandating the use of IPSec. A vendor which ensured they can provide HA across the service, but don’t seem to have any idea how they’re actually going to implement this. I don’t have a lot of confidence in them coming back with a useable solution, so have been labbing up the scenario myself.
We are going to be sitting CPEs on the remote end of the vendor’s provided connectivity, and will be running GRE from there, but it’s working out how best to ensure that GRE tunnel stays up in the event of outages on the IPSec side.
Thanks both for your feedback. I’m going to go back and see if I can find a way to hack around this.
