I am having a hell of a time with the ASA rules.
Don't rely on getting help with a Cisco product on a 'Tik forum
Sometimes miracles happen, but better go search in the domestic woods of that beast.
I can get to the MT on 10.0.90.1 from the "inside" (ASA) subnet of 172.24.94.0/23. but cannot go other way.
At Mikrotik side, network debug is facilitated by means of /tool sniffer
. So open the terminal window, make it as wide as your screen allows, and run /tool sniffer quick ip-address=172.24.94.0/23
there, then try pinging from that subnet to one of the clients' addresses, and (separately) try pinging from one of the clients to one of the machines in the 172.24.94.0/23 subnet. You'll see whether the ASA or the Tik are blocking your traffic.
If the packets from 172.24.94.0/23 do reach the ASA-facing interface of the Tik, the ASA doesn't block them at least in this direction. This way, you won't see them leaving the Tik even if they do as they get encrypted so they transmutate into IPsec transport packets with both IP addresses different, but there are more complex ways available to visualize (or at least count) them anyway - /ip firewall mangle add chain=postrouting action=xyz src-address=172.24.94.0/23
will just count them if you use passthrough
instead of xyz
, or log their IP header and other information if you use log
instead of xyz
. Just make sure first that this rule is the topmost one in its chain (mangle -> postrouting) - it should be given the firewall export you've posted.
If the sniff shows you the packets from the IPsec clients towards 172.24.94.0/23 at the ASA-facing interface, it is the ASA that blocks them, otherwise it's the Mikrotik rules.
If you plan that the IPsec clients would not only initiate connections to servers in 172.24.94.0/23, but also vice versa (i.e. if you want to be able to even ping the clients from 172.24.94.0/23), you have to add one rule to the top of the nat -> srcnat chain: action=accept ipsec-policy=out,ipsec
. The actual IPsec processing (matching of packets to the traffic selectors of the policies, encryption of the matching ones and new routing of the resulting transport packets) is done after all the firewall handling; this rule ensures that the initial packet of each new connection will not reach the "masquerade all that goes out via WAN" rule, which otherwise changes its source address to the public one so it won't fit to the IPsec traffic selectors any more. All the subsequent packets of each connection inherit the NAT behaviour of the first one (as appropriate with regard to their direction), so the connections initiated by the IPsec clients are not affected by the absence of said rule.
The clients with a 10.0.88.0/23 ip addresses assigned from the pool
Also, I believe the Ipsec ->"mode configs" -> "split include" has a bug. The entire 10.0.0.0/8 route gets added to the routing table on the client even when I don't have it in the split include. See attached "route print". Notice when I am connected and not connected with ipsecroute.jpg client. It doesn't do that for other subnets I add. split.jpgroute2.jpg
There is a catch in Windows' VPN client. On W10, right-click the network icon in the status area, and choose network and internet settings
rather than just open
. In the "new GUI" window that opens, left-click change adapter settings
- this will open the "old GUI" window with the physical and virtual network cards. Right-click the WAN miniport (IKEv2)
one representing your connection and choose Properties
from the menu. In the window that opens, choose the Networks
tab. Double-click the "IP version 4 protocol" line (not
the checkbox on it). Keep the IP address and DNS server on "auto" and press the only button there (probably called Details
). Now you should see three tickboxes - use as a default gateway
, forbid adding a class-based route
, and automatic metric
. I suppose use of a default gateway
is unticked (correct), but forbid adding a class-based route
is unticked as well, which causes that Windows finds the A, B or C class subnet to which the IP address assigned by the remote server belongs and adds a route to that subnet regardless what the routing table in Option 249 of the DHCPINFORM response (which Mikrotik populates with the subnet prefixes from the split-include
I have no clue whether Windows negotiate that class-based route using the IKEv2 traffic selector negotiation; if they do, /ip ipsec policy print where src-address~"10.0.0.0"
should show you something. If this is the case, you can create a non-default /ipsec policy group
item, and create a new /ip ipsec policy
item with group
referring to that group, template=yes
, and src-address=172.24.94.0/23 dst-address=0.0.0.0/0
, and set the policy-template-group
of the corresponding /ip ipsec identity
item to that group. This will make IPsec reject the traffic selector for 10.0.0.0/8 proposed by the Windows VPN client.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.