IPSEC tunnel established, traffic not passing through

RouterOS General
1

Hello all,
I am trying to put in place a VPN tunnel initiated by my Mikrotik router and have the traffic from one single host forced through that tunnel. To make things more complicated my LAN clients are natted twice and I am wondering if this could cause some issues.

My config is as follows:

[LAN Site A (192.168.88.0/24)]----[(192.168.88.1) Mikrotik (192.168.1.202)}----[(192.168.1.1) ISP Router (public IP A)]--- Internet ---[(public IP B) ISP Router B (192.168.1.1)]----[LAN Site B (192.168.1.0/24)]

The tunnel is established correctly:

 id="<public IP B>" local-address=192.168.1.202 port=4500 remote-address=<public IP B> port=4500 state=established side=initiator uptime=14m31s last-seen=6s 
      ph2-total=1 spii="7c63fbe387947dea" spir="a3c132cf1a2fd729" spii="7c63fbe387947dea" spir="a3c132cf1a2fd729"




 installed-sa print                                                          
Flags: H - HW-AEAD; E - ESP
Columns: SPI, STATE, SRC-ADDRESS, DST-ADDRESS, AUTH-ALGORITHM, ENC-ALGORITHM, ENC-KEY-SIZE
#    SPI         STATE   SRC-ADDRESS         DST-ADDRESS         AUTH-ALGORITHM  ENC-ALGORITHM  ENC-KEY-SIZE
0 HE 0xE583387   mature  <public IP B>:4500    192.168.1.202:4500  sha1            aes-cbc                 128
1 HE 0xC0840D1F  mature  192.168.1.202:4500  <public IP B>:4500    sha1            aes-cbc                 128

But no traffic is going through:

[admin@MikroTik] /ip/ipsec/active-peers> print detail stats 
Columns: ID, STATE, UPTIME, PH2-TOTAL, REMOTE-ADDRESS, RX-BYTES, TX-BYTES, RX-PACKETS, TX-PACKETS
# ID           STATE        UPTIME  PH2-TOTAL  REMOTE-ADDRESS  RX-BYTES  TX-BYTES  RX-PACKETS  TX-PACKETS
0 <public IP B>  established  17m53s          1  <public IP B>            0        40           0           1




[admin@MikroTik] /ip/ipsec/statistics> print 
                  in-errors:     0
           in-buffer-errors:     0
           in-header-errors:     0
               in-no-states:     0
   in-state-protocol-errors:     0
       in-state-mode-errors:     0
   in-state-sequence-errors:     0
           in-state-expired:     0
        in-state-mismatches:     0
           in-state-invalid:     0
     in-template-mismatches:     0
             in-no-policies:     0
          in-policy-blocked:     0
           in-policy-errors:     0
                 out-errors:     0
          out-bundle-errors:     0
    out-bundle-check-errors:     0
              out-no-states: 10812
  out-state-protocol-errors:     0
      out-state-mode-errors:     0
  out-state-sequence-errors:     0
          out-state-expired:     0
         out-policy-blocked: 11056
            out-policy-dead:     0
          out-policy-errors:     0

I only want packets from the LAN host at the IP 192.168.88.212 to go through the tunnel, and for this I have the policy:

[admin@MikroTik] /ip/ipsec> policy/print 
Flags: T - TEMPLATE; A - ACTIVE; * - DEFAULT
Columns: PEER, TUNNEL, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, ACTION, LEVEL, PH2-COUNT
#     PEER    TUNNEL  SRC-ADDRESS        DST-ADDRESS  PROTOCOL  ACTION   LEVEL    PH2-COUNT
0 T *                 ::/0               ::/0         all                                  
1  A  IPSecTunnel  yes     192.168.88.212/32  0.0.0.0/0    all       encrypt  require          1

I have a NAT rule that is automatically added:

[admin@MikroTik] /ip/ipsec> ../firewall/nat/print 
Flags: X - disabled, I - invalid; D - dynamic 
 0  D ;;; ipsec mode-config
      chain=srcnat action=src-nat to-addresses=192.168.1.220 src-address-list=ipsec-addr dst-address-list=!ipsec-addr 

 1    ;;; defconf: masquerade
      chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none

192.168.1.220 is the IP at the other end of the tunnel in the lan of Site B.

The address list contain only one IP:

[admin@MikroTik] /ip/firewall> address-list/print 
Columns: LIST, ADDRESS, CREATION-TIME
# LIST        ADDRESS         CREATION-TIME      
0 ipsec-addr  192.168.88.212  2025-03-15 22:04:34

It looks like my traffic is not matched by the policy.

Any help would be greatly appreciated.

2

This is my firewall configuration:

/ip firewall address-list
add address=192.168.88.212 list=ipsec-addr
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
3

Complete exports from both routers would have been much better because configuration issues are typically in those parts of the configuration you do not deem related, which is why you don’t post them.

In your case, you have set up a “cat-dog”, in terms that you use a mode-config row on the initiator on Site A to request an IP address from the responder and dynamically create a policy from that address to whatever the responder (router on Site B) offers and a corresponding src-nat rule that matches on an address list, and at the same time you have created a static policy from the actual LAN address (192.168.88.212) to 0.0.0.0/0.

Something apparently failed in that, so you’ve ended up with only the static policy that matches on 192.168.88.212 and with the action=src-nat rule that also matches on 192.168.88.212 (via address list ipsec-addr) and changes that address to the one assigned by the responder (192.168.1.220), so the static policy cannot match, but the dynamic policy from 192.168.1.220 doesn’t get created so the packet most likely gets sent via the regular WAN gateway on site A (192.168.1.1).

So remove the reference to the mode-config from the /ip/ipsec/identity row on Site A and see whether it helps; if it’s still not enough, post the complete configuration exports from both routers, after obfuscating public addresses, usernames to external services etc. that might help the bad guys to barge in.

4

Thank you for your response.

If I remove the mode-config then the tunnel is established (I can see the active peer) but the policy status says “no phase2”.

I do not have the config of the responding router. It is a dumb ISP (Swisscom) router where the only configuration is to enable or disable the IPSec service, and create identities (login & password).

5

If so, go the other way round, enable (recreate) the mode-config and disable the manually configured policy.

6

I’m curious as to the purpose of the tunnel to this swiss device.
Is the requirement to reach a subnet behind that ISP router?
Is the requirement to simply use internet at that router?
Is the requirement for some entity behind the swiss router to reach the single LANIP on your MT?

7

The requirement is to use the Internet behind that router at site B.

8

Then I think it’s even worse, I can’t see any “installed SAs” once the tunnel is established with this configuration. I have also tried to enable the “generate policy strict” but then I lost access to the router.

9

If so, have you set generate-policy on the identity row to something else than no?

10

Yes, I’ve tried it but if I set “generate policy” to strict then I completely loose access to the router and to the Internet.

(Thanks to the Safe Mode after a few minutes the change is reverted automatically).

11

After doing quite a lot of unsuccessful tests today here what the stats show:

[admin@MikroTik] /ip/ipsec/statistics> print
                  in-errors:     0
           in-buffer-errors:     0
           in-header-errors:     0
               in-no-states:     0
   in-state-protocol-errors:     0
       in-state-mode-errors:     0
   in-state-sequence-errors:     0
           in-state-expired:     0
        in-state-mismatches:     0
           in-state-invalid:     0
     in-template-mismatches:  6548
             in-no-policies:     0
          in-policy-blocked:   451
           in-policy-errors:     0
                 out-errors:     0
          out-bundle-errors:     0
    out-bundle-check-errors:     0
              out-no-states: 14685
  out-state-protocol-errors:     0
      out-state-mode-errors:    18
  out-state-sequence-errors:     0
          out-state-expired:     0
         out-policy-blocked: 41987
            out-policy-dead:     0
          out-policy-errors:     0

I see many abnormal readings: “out-policy=errors”, “in-policy-blocked” and “in-template-mismatches”. Unfortunately I have no clue and do not know how to use that information to help the troubleshooting.

12

What normally happens is that the initiator asks for Mode Config information (which is a name used in the IKE (v1) vernacular, so strictly speaking not correct for IKEv2, but let’s ignore that), gets an address, and asks the responder to create a policy with only that single address on its side. So it looks as if the responder was actively asking for a policy with a wider selector on the initiator side and the initiator accepted that.

Can you exempt access to the LAN address of the Mikrotik from the reach of the dynamically created policy by placing a policy src-address=192.168.88.0/24 dst-address=192.168.88.0/24 action=none before (above) the template policy and if that helps, show the actual traffic selector of the dynamically created one?

Other than that, instead of Safe Mode, disconnection of the WAN cable should help, as that would break the IPsec connection too.

13

Thank you, I’ll give it a try and report here.

14

Hello all,


I have a similat situation, I have multiple ipsec tunnels from a main router to offices, and my issue is that from the main router I can ping for example

 SEQ HOST                                     SIZE TTL TIME  STATUS
    0 10.16.0.1                                  56  64 32ms
    sent=1 received=1 packet-loss=0% min-rtt=32ms avg-rtt=32ms max-rtt=32ms

But from my desktop , connected via openvpn to a separate VPN server in my LAN I cannot ping 10.16.0.1

        10.11.0.0      255.255.0.0  192.168.220.161  192.168.220.162    257
        10.15.0.0      255.255.0.0  192.168.220.161  192.168.220.162    257
        10.16.0.0      255.255.0.0  192.168.220.161  192.168.220.162    257
        10.20.0.0      255.255.0.0  192.168.220.161  192.168.220.162    257
        10.21.0.0      255.255.0.0  192.168.220.161  192.168.220.162    257
        10.22.0.0      255.255.0.0  192.168.220.161  192.168.220.162    257
        10.25.0.0      255.255.0.0  192.168.220.161  192.168.220.162    257
        PS C:\Users\user> ping 10.16.0.1

Pinging 10.16.0.1 with 32 bytes of data:
Request timed out.

Ping statistics for 10.16.0.1:
    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

the policy

/ip ipsec policy print
Flags: T - template, B - backup, X - disabled, D - dynamic, I - invalid, A - active, * - default
 #      PEER        TUNNEL SRC-ADDRESS                                       DST-ADDRESS                                       PROTOCOL   ACTION  LEVEL    PH2-COUNT
 0 T  *                    ::/0                                              ::/0                                              all
20  peer2       yes    192.168.220.0/24                                  10.16.0.0/16                                      all        encrypt unique           0

A MTR from my desktop

|------------------------------------------------------------------------------------------|
| WinMTR statistics |

Host - % Sent Recv Best Avrg Wrst Last
192.168.220.1 - 0 27 27 42 62 87 42
10.0.0.1 - 5 24 23 41 65 88 50
No response from host - 100 6 0 0 0 0 0
\
\
\
/ip ipsec policy export 
add dst-address=10.16.0.0/16 level=unique peer=peer2 proposal="proposal_peer2" src-address=192.168.220.0/24 tunnel=yes

There is a source-nat policy configured:

 3    chain=srcnat action=accept src-address=192.168.220.0/23 dst-address=10.16.0.0/16 log=no log-prefix=""

Also on FORWARD there is a rule to permit all traffic.

Can you please help me solve this issue.


Thank you in advance,

15

Actually, the whole similarity is just “I also have some issue with IPsec”. So please re-post the above in a new dedicated topic instead of piggybacking a loosely related one that is still unresolved. And once at it, post also the complete exports of the two IPsec peers in that new topic.

16

So I tried that and it did not help. I did not quite understand what you meant by “show the actual traffic selector” could you clarify?

The fact that I see TX traffic but no RX makes me think this is something related to NAT that is creating the issue. I am tempted to switch to IPV6 to get NAT out of the way.

I tried to completely remove the policies and let mode-config generate the dynamic one and in the statistics I saw this:

in-template-mismatches: 640

Any idea?

Also, if I disable mode-config then the tunnel failed to reach the stage “established” and show a status of “no phase 2”. What does this mean exactly as you seemed to indicate that mode-config should not be required…

Thanks again.

17

It could work without mode-config if the responder (“server”) was a device that allows you to configure all the aspects of the IPsec connection. Since it is a blackbox, you have to adjust the configuration of the Mikrotik acting as initiator to its expectations.

An IPsec “policy” is a combination of a “traffic selector” (matching rules for traffic to be chosen for delivery via the tunnel) and either a peer to deliver the matching traffic to/expect the matching traffic from and a phase 2 proposal used to establish a pair of SAs for that traffic with that peer, or an instruction to drop that traffic or leave it alone. So when I ask what the “traffic selector” is, I mean the src-address, dst-address, src-port, dst-port, and protocol items of the policy.

A policy may be configured manually or generated from a template. A manually configured policy that requires to deliver the matching traffic to a peer drops the matching traffic if the SA needed to deliver it is not available. A dynamically generated policy only gets generated once the IKE/IKEv2 SA with the peer has been established, so before and after that, the policy does not exist and IPsec ignores any traffic that would match it unless other policies match it too.

As I wrote above - normally, the responder would assign a single address to the responder and give it a list of subnets on the remote side to access (split-include in Mikrotik configuration); the responder would then dynamically create one policy per item on the list with the item on the list as dst-address and the assigned address as a src-address. In your case, it seems to work differently, so we need to know what the responder suggests as src-address to the Mikrotik using the mode-config mechanism, and adjust the policy template on Mikrotik side to limit that to what we need - IKEv2 allows to negotiate the actual traffic selector as an intersection of the ones proposed by both peers. So if the responder suggests I:0.0.0.0/0<->R:10.100.100/22 and the policy template at initiator side says I:192.168.88.0/24<->R:0.0.0.0/0, the resulting traffic selector will be I:192.168.88.0/24<->R:10.100.100.0/22.

As for IPv6, I don’t think it would help. The responder assigns an additional address or subnet/prefix to the initiator, and the initiator creates a policy to send traffic from that address/subnet via the responder by means of the IPsec SAs. If the address is an IPv4 one, you can use a src-nat rule to make a packet from any address match the traffic selector of that policy (policy matching takes place after srcnat). That’s what setting src-address-list and/or connection-mark in the initiator’s mode-config causes - for each such item and remote subnet, a src-nat rule is dynamically generated as soon as the IKE/IKEv2 session gets established. If the address is an IPv6 one, you either have to use a src-nat rule too, or it has to be a whole subnet and you must advertise that subnet to the LAN hosts and the LAN hosts must use an address from that subnet to talk via the responder, which normally boils down to having no other IPv6 address except the one from that subnet. And I even don’t know whether mode-config allows to assign a whole /64 to the initiator.



In what sense it “did not help”? It should not have helped to make it all work; it should have helped to maintain local access to the router even after the IPsec IKE/IKEv2 session got established, by preventing traffic within 192.168.88.0/24 (so between the configuration PC and the router itself) from getting hijacked by the dynamically created policy, and subsequently allowing to see what policy has been dynamically generated using mode-config, so that we could understand what the responder suggests and how to modify the template.

18

Thanks a lot, it’s much clearer now.

Despite all my efforts the result is still the same: I can see the traffic going out back nothing received from the tunnel.

[admin@MikroTik] /ip/ipsec> statistics/ print
in-errors: 0
in-buffer-errors: 0
in-header-errors: 0
in-no-states: 0
in-state-protocol-errors: 0
in-state-mode-errors: 0
in-state-sequence-errors: 0
in-state-expired: 0
in-state-mismatches: 0
in-state-invalid: 0
in-template-mismatches: 3915
in-no-policies: 0
in-policy-blocked: 0
in-policy-errors: 0
out-errors: 0
out-bundle-errors: 0
out-bundle-check-errors: 0
out-no-states: 2822
out-state-protocol-errors: 0
out-state-mode-errors: 0
out-state-sequence-errors: 0
out-state-expired: 0
out-policy-blocked: 550
out-policy-dead: 0
out-policy-errors: 0

19

That does not answer what the policy looks like when the tunnel is “up”. You don’t know what the responder is actually doing, so if it assigns the initiator an address but the initiator is sending from another one using your manually configured policy, the firewall on the responder may drop that traffic. But the errors in the IPsec counters suggest that something else is wrong.

Did you follow my suggestion to add the action=none policy to retain access to the router, disable any manually configured action=encrypt policy, enable the mode-config, and look what policy gets created dynamically in such a setup?

20

Hello,
Sorry for not responding…

The policy installed by mode-config is src.address 0.0.0.0/0 and dst.address 0.0.0.0/0

And yes the policy you advised me to add helped me avoid being kick-out of the router.