sniffer loses packages

RouterOS General
1

Hi.

This is my test environment:

ssh server - firewall - mikrotik - ssh server
172.30.1.99/24 - 172.30.1.1/24, 10.1.1.1/24 - 10.1.1.2/24, 172.30.2.1/24 - 172.30.2.99/24
firewall ipsec ↔ mikrotik ipsec

From 172.30.1.99: telnet 172.30.2.99 22
INTERFACE TIME NUM DIR SRC-MAC DST-MAC VLAN SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE CPU FP
ether1 7.875 1 ← 08:00:27:2E:6C:98 08:00:27:3A:34:7F 172.30.1.99:32890 172.30.2.99:22 (ssh) ip:tcp 74 0 no
ether2 7.875 2 → 08:00:27:F3:41:CF 08:00:27:EA:8A:10 172.30.1.99:32890 172.30.2.99:22 (ssh) ip:tcp 74 0 no
ether2 7.875 3 ← 08:00:27:EA:8A:10 08:00:27:F3:41:CF 172.30.2.99:22 (ssh) 172.30.1.99:32890 ip:tcp 74 0 no
Packet not shown outgoing by ether1 interface
ether1 7.877 4 ← 08:00:27:2E:6C:98 08:00:27:3A:34:7F 172.30.1.99:32890 172.30.2.99:22 (ssh) ip:tcp 66 0 no
ether2 7.877 5 → 08:00:27:F3:41:CF 08:00:27:EA:8A:10 172.30.1.99:32890 172.30.2.99:22 (ssh) ip:tcp 66 0 no
ether2 7.885 6 ← 08:00:27:EA:8A:10 08:00:27:F3:41:CF 172.30.2.99:22 (ssh) 172.30.1.99:32890 ip:tcp 98 0 no
Packet not shown outgoing by ether1 interface
ether1 7.886 7 ← 08:00:27:2E:6C:98 08:00:27:3A:34:7F 172.30.1.99:32890 172.30.2.99:22 (ssh) ip:tcp 66 0 no
ether2 7.886 8 → 08:00:27:F3:41:CF 08:00:27:EA:8A:10 172.30.1.99:32890 172.30.2.99:22 (ssh) ip:tcp 66 0 no

From 172.30.2.99: telnet 172.30.1.99 22
INTERFACE TIME NUM DIR SRC-MAC DST-MAC VLAN SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE CPU FP
ether2 3.714 1 ← 08:00:27:EA:8A:10 08:00:27:F3:41:CF 172.30.2.99:33292 172.30.1.99:22 (ssh) ip:tcp 74 0 no
Packet not shown outgoing by ether1 interface
ether1 3.716 2 ← 08:00:27:2E:6C:98 08:00:27:3A:34:7F 172.30.1.99:22 (ssh) 172.30.2.99:33292 ip:tcp 74 0 no
ether2 3.716 3 → 08:00:27:F3:41:CF 08:00:27:EA:8A:10 172.30.1.99:22 (ssh) 172.30.2.99:33292 ip:tcp 74 0 no
ether2 3.716 4 ← 08:00:27:EA:8A:10 08:00:27:F3:41:CF 172.30.2.99:33292 172.30.1.99:22 (ssh) ip:tcp 66 0 no
Packet not shown outgoing by ether1 interface
ether1 3.726 5 ← 08:00:27:2E:6C:98 08:00:27:3A:34:7F 172.30.1.99:22 (ssh) 172.30.2.99:33292 ip:tcp 98 0 no
ether2 3.726 6 → 08:00:27:F3:41:CF 08:00:27:EA:8A:10 172.30.1.99:22 (ssh) 172.30.2.99:33292 ip:tcp 98 0 no
ether2 3.727 7 ← 08:00:27:EA:8A:10 08:00:27:F3:41:CF 172.30.2.99:33292 172.30.1.99:22 (ssh) ip:tcp 66 0 no
Packet not shown outgoing by ether1 interface

Why mikrotik sniffer not shown this packets?
Communication is OK

2

Nobody with the same issue?

3

As your examples show systematically no out packets on ether1 and no configuration and overall network topology is available, it is hard to say whether it is an issue of packet sniffing, or of some sniffer filter setting, or of the network topology (where the packets in one direction may come in via ether1 and the packets in mirror direction leave through another interface).

I only had issues with different delays on the path from interfaces to the sniffing buffer, where e.g. the packets extracted from IPsec were shown ahead of the transport packets inside which they have arrived, but I have never spotted packets merely missing so far. But it may also depend on hardware platform, release, …

4

Hi.
Sorry for the lack of information.

I detected this issue on Mikrotik RB3011UiAS v6.39.2
I created a virtual environment to test the issue with virtual mikrotik v6.42.2. This is net diagram:
https://photos.google.com/share/AF1QipP5SYyjFA_iUk6fO5vNhLaxt4tYoJb8BbPX8e54ShMjAmNxEI-A-T50CfxlLd4zSw/photo/AF1QipNUr7CgUmXnPjvmX6X6XGnSBddAvVXGsTQPCzFa?key=bVBJYzg1aTIyUjBBNlNDY0t2ZjhoMGx1cW16UXN3

Filter sniffer:
tool sniffer quick ip-protocol=icmp

Mikrotik only has 2 interfaces:

  • eth1 is wan interface
  • eth2 is lan interface

There is a ipsec tunnel between 172.30.1.0/24 and 172.30.2.0/24 networks.
Test to port 22 in two directions.

It’s a very simple environment.

Thanks for your help!

5

So I’m guessing that the Mikrotik on the left without inscription is the 3011.

The sniffer filter you’ve provided would only show icmp packets while your previous post shows ssh and telnet (TCP/22 and TCP/23) ones so that’s a mismatch.

With IPsec, the problem is that it works in a very specific way. When an IPsec transport packet arrives from the wire (or the air), it is seen by the sniffer and firewall on the interface. After the IPsec decapsulates and decrypts the original packet from the received transport one, it is again seen by the firewall and the sniffer on the same interface, which is already surprising but logical.

In the sending direction, the packet to be encrypted into IPsec transport is first processed completely, including finding the route and thus output interface for it. But just before any packet reaches the output interface, the IPsec policies are matched against the packet and if the packet matches one of them, it is encrypted, encapsulated into a transport one and that transport one is then handled as a brand new packet, sent to the sa-dst-address of the SA (security association) created by the policy.

So if the packets in your sniff went physically via ether1 but encapsulated into an IPsec transport packet, no wonder that you cannot see them there in plaintext form.

Depending on your setup, the IPsec transport may be plain AH or ESP directly in IP, or ESP in UDP in IP. So I cannot tell you what else than TCP to look/filter for.

6

Hi.

No, mikrotik is right router. Left router is a Stormshield model.

Yes, it’s a mismatch:
tool sniffer quick port=22

Witch icmp I have found same issue.

I think you’re right. Packet is encrypted by mikrotik and it doesn’t match sniffer filter.

IPSec: ipsec-protocols=esp tunnel=yes
Communication is on 500/udp port.

In other routers, like Stormshield model, I have a virtual interface for ipsec communication. On this interface I can analyze tunnel unencrypted traffic. Does it exit something like this in mikrotik world?

7

I’ve misunderstood the explanation you wrote and was looking for the 3011.

There definitely is no virtual interface as such (does the Stormshield have one per each policy?), but I admit I’ve never even expected to be able to sniff the data before encryption on the outgoing interface so I didn’t try whether at some circumstances the plaintext packets could be visible there. If you use some tunnel (L2TP, GRE, or even EoIP, IPIP if you have a 'Tik at both ends) over IPsec, you can sniff the plaintext data at the virtual interface representing the local end of the tunnel, but I guess you are specifically interested in policy-based IPsec, and there the answer is 99% No.

8

Hi.
I found problem in RB23011, but I have reproduced issue in virtual environment. My question was about this virtual environment.

Stormshield has one interface for all policies.

Thanks! You have helped me a lot.