Should be like that. As the note says that the iPhone wouldn’t accept a default route via split-include, I guess they do not provide other protection against replacing the route to the IPsec “server”, so be careful not to choose a public range which includes the public IP of your Mikrotik.
[quote=“, post:7, topic:116704”]
- you assign to the iPhone an address from the split-include range which cannot work, pure IPsec doesn’t directly tunnel L2.
[/quote]
I must have a different subnet? On a bruteforce-type approach, will it still be possible to split-include smaller subnets that still cover most of this /24? But I guess the good practice should be a separated subnet like .2.0/24 ?
Well, I can imagine that you could have a LAN subnet like x.x.x.0/24, use e.g. the x.x.x.64/26 subnet of it for your road warriors, and send them x.x.x.0/26 and x.x.x.128/25 using split-include, but if the devices connected to the LAN are configured with x.x.x.n/24, they won’t attempt to send packets for x.x.x.64/26 via the gateway and will try to ARP them directly. So it should work if you activate arp proxy on the bridge in Mikrotik which hosts the LAN, but I definitely wouldn’t start from this configuration - to avoid an extra source of uncertainty.
[quote=“, post:7, topic:116704”]
- you haven’t defined exceptions from the masquerade rules and/or connection tracking as a whole for packets to be sent towards your iPhone, so the IPsec policy cannot match them.
[/quote]
Could you explain this one better? I understood your other points and they made total sense. However I thought when a device connects via IPsec that packets could still go via the normal routes given that the public destination IP is still the same. But I guess need to route-mark the packets? What kind of route should I default them to, or where can I find Mtik’s information to correctly configure this one?
It’s all a bit different than what you seem to expect, and the need to bypass the src-nat is briefly mentioned on Mikrotik’s IPsec wiki page which however doesn’t detail the concept of IPsec policy as such, assuming that the reader is familiar with IPsec general concept. Coming back to what I’ve already written:
[quote=“, post:7, topic:116704”]
“pure IPsec” works very different from other VPNs, there is no virtual interface to which you would route the traffic for the client, packets are handled by regular routing and right before sending them out through a physical interface, they get matched against an IPsec policy and if matching, they are processed by the IPsec machinery and sent using the SA established.
[/quote]
So let’s follow a packet sent by a device on Mikrotik’s LAN to the IP of your road warrior client.
- assuming that the IP of the RWC is not in the LAN subnet, the sending device will send it to Mikrotik’s own IP which is its default gateway
- the Mikrotik has no specific route for the destination IP, so it uses the default one, which resolves to a gateway IP and an interface X
- the nat table of the firewall contains a masquerade rule in postrouting chain saying “whatever leaves through interface X has to be src-nat’ed with interface X’s IP address”, so the source address of the packet is changed from the one of the sending device to the one of interface X
- only at this stage the packet is offered to the ipsec policy for matching
- depending on the src-address of the policy, it may match it or not. If it does match, the packet is encapsulated using the SA (security association) associated to the policy into a brand new packet which then enters the routing again, just like any other packet originated by the Mikrotik itself
- when the src-nat’ed original packet gets unpacked at the road warrior client, the road warrior will
- either send its response to the source IP of the packet which is the address of the interface X chosen above if the packet we track was the one establishing a connection,
- or be confused by receiving a packet coming from an unexpected address if the packet we track was already a response.
So to prevent the packet from being missed by the policy and thus not delivered to the RWC at all, or from being delivered but with an incorrect source address if the policy is wide enough, you have to
- either put an exception rule in front of the masquerade one(s) in the “/ip firewall nat” table, accepting packets for the road warrior(s) before they can hit the masquerade rule, which keeps the source address of these packets unchanged and connection-tracking functional for them
- or put a rule into “/ip firewall mangle” table with action=no-track for the packets for the road warrior(s), which will prevent them from getting connection-tracked, which also prevents them from being processed by the postrouting chain of the “/ip firewall nat” table. But if you disable connection tracking for the road warriors’ connections, you’ll likely have to add exceptions to the “/ip firewall filter” rules as normally only the initial packet of each connection has its own “accept” rule in the filter, and all the other packets of a connection are handled by the magical “accept connection-state=established,related” rule which does not work if the connection is not tracked.
(Why you have to make things difficult apple?)