About IPsec and routing

RouterOS General
1

Hi
Currently setting up a site to site VPN and I’m having an issue which seems to be related to routing.
The tunnel comes up and I can ping from site A to site B. However I can not reach site A from site B.
If I do a traceroute from site B the packets to site A are egressing on the WAN - ie the router does not “know” to route them via the existing and established tunnel.
From what I understand IPsec (as opposed to SSTP for instance) does not require nor support defining static routes - they just “come” built-in.
But dumping my current routes:

 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          *.*.210.225            1
 1 ADC  *.*.210.224/27      *.*.210.228  wan                       0
 2 ADo  172.16.23.0/24                     172.16.255.98           110
 3 A S  172.16.50.0/24                     172.16.255.104            1
 4 A S  172.16.55.0/24                     172.16.255.104            1
 5   S  172.16.60.0/24                     172.16.255.69             1
 6 X S  ;;; xxx subnet hosted at xxx
        172.16.66.0/24                     172.16.109.150            1
 7 ADC  172.16.100.0/24    172.16.100.254  Host A                    0
 8 A S  ;;; Subnet G 
        172.16.103.0/24                    172.16.255.100            1
 9 A S  ;;; Subnet O 
        172.16.105.0/24                    172.16.255.100            1
10 A S  ;;; Subnet Q 
        172.16.107.0/24                    172.16.255.100            1
11 ADC  172.16.109.150/32  172.16.109.254  <sstp-remoteuser>         0
12 ADC  172.16.110.0/24    172.16.110.254  Host C                    0
13 ADC  172.16.110.200/32  172.16.110.254  <sstp-mailgate>           0
14 A S  ;;; Subnet D 
        172.16.111.0/24                    192.168.199.107           1
15 A S  ;;; Subnet B 
        172.16.200.0/24                    192.168.199.107           1
16 A S  ;;; Subnet I 
        172.16.210.0/24                    192.168.199.104           1
17 A S  ;;; Subnet J 
        172.16.211.0/24                    192.168.199.104           1
18 A S  172.16.231.0/24                    172.16.255.97             1
19   S  ;;; AWS
        172.16.252.12/32                   172.16.255.96             1
20 A S  ;;; Subnet for remote routers connected to ...
        172.16.253.0/24                    192.168.199.104           1
21 ADo  172.16.255.1/32                    172.16.255.98           110
22 ADC  172.16.255.97/32   172.16.255.1    <sstp-0>                  0
23 ADC  172.16.255.98/32   172.16.255.1    <sstp-1>                  0
24 ADC  172.16.255.99/32   172.16.255.1    <sstp-2>                  0
25 ADC  172.16.255.100/32  172.16.255.105  <pptp-3-usg>              0
26 ADC  172.16.255.104/32  172.16.255.1    <sstp-ffggCCR>            0
27 A S  192.168.0.0/24                     172.16.255.104            1
28 A S  ;;; Subnet K 
        192.168.28.0/24                    192.168.199.104           1
29 A S  ;;; Subnet N 
        192.168.66.0/24                    192.168.199.104           1
30 A S  192.168.100.0/24                   Host A                    1
31   S  192.168.168.0/24                   *F0002E                   1
32 ADC  192.168.199.0/24   192.168.199.106 interrouter               0

I don’t see any route to 172.16.10.0/24, which is the subnet I want to reach (nor, for that matter, to other IPsec connected subnets that are working as expected, say 172016.170.0/24 as an example).
Where can I see the IPsec implied routes ?
How would you diagnose my issue ?

2

IPSec uses “Policies” to route, check in IPSec->Policies if the correct src / dst ranges are specified

3

well I have this

the Azure policy works (site to site to Azure)
the IM office does not (site to site Mk)

4

Well, you use “site A and site B” in one post, and different references in another, so it is hard to correlate.

Basically, IPsec policies supersede the regular routes, but the regular routes affect IPsec policy matching for packets sent by the router itself. So there is a difference between pinging between other hosts than the routers themselves in 172.16.10.0/24 and 172.16.100.0/24 and pinging from or between the routers themselves (or tracerouting for that matter). Packets from other hosts always have the address of the host as a source one; the source address of packets sent by the router itself depends on the regular route chosen to deliver these packets. So if the router has a regular route to 172.16.10.0/24 via a gateway in another subnet than 172.16.100.0/24, the own address of the router in the subnet of the gateway is chosen as source address of the packets for 172.16.10.0/24, hence the IPsec policy’s traffic selector will not match it. I cannot see any route to 172.16.10.0/24 (or a larger subnet which includes it) in your route list, so the default one via a public subnet is likely used, which means that the packets generated by locally running traceroute are ignored by the IPsec policy. But neither can I see a route to 172.16.175.0/24, so either you have a src-nat rule somewhere, or you don’t send anything from the Mikrotik itself to the 172.16.175.0/24.

So to fix this, either add a dedicated route to 172.16.10.0/24 and set its pref-src to 172.16.100.254, or use a src-nat rule with the same effect (chain=srcnat src-address-type=local dst-address=172.16.10.0/24 action=src-nat to-addresses=172.16.100.254).

The other place where packets sent from the router itself and packets transiting from one interface of the router to another are handled differently is the firewall. Packets to/from the router itself are handled by chains input and output, respectively; transiting packets are handled by chain forward. As you say that you can ping from site A to site B but not vice versa, it seems that routing/policy matching works OK as otherwise you wouldn’t be receiving ping responses in any of the two directions. Hence firewall rules at site A preventing the incoming pings from site B from reaching the LAN host are a more likely reason why the pings fail in one direction than a routing/policy matching issue. The key here is the stateful firewall - site A’s rules let through responses to ping requests previously sent in A => B direction, but do not let through ping requests arriving in B => A direction.

5

Thanks for this detailed explanation ! Sorry for my somewhat unclear initial description - I wanted to keep it generic. In the case at hand subnet A is 172.16.10.0/24 and subnet B is 172.16.100.0/24. A to B works, B to A does not. Will review my settings per your suggestion and revert.