One of the client traffic seen towards 192.0.2.1

[SatishJ]

Hi all, It's been reported from our internet SIEM team that, one of the client connect to Meraki access point traffic is seen towards 192.0.2.1, I did go to clients and verified however not seen any client with 192 series IP address. Can someone suggest on this?

[ww]

Sounds like a client send traffic  going to a public address 192.0.2.1.  So you would not find a network client with that ip

[SatishJ]

What exactly 192.0.2.1 is? I see it as ISP: TEST-NET

[alemabrahao]

1.  Introduction

   This document describes three IPv4 address blocks that are provided
   for use in documentation.  The use of designated address ranges for
   documentation and examples reduces the likelihood of conflicts and
   confusion arising from the use of addresses assigned for some other
   purpose.

   [RFC1166] reserves the first of the three address blocks,
   192.0.2.0/24.  The other two address blocks have recently been
   allocated for this purpose, primarily to ease the writing of examples
   involving addresses from multiple networks.

   Other documentation ranges have been defined in the IETF, including
   the IPv6 documentation prefix [RFC3849] and example domain names
   [RFC2606].  Documentation also makes use of the ranges reserved in
   [RFC1918].

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, [RFC2119].

3.  Documentation Address Blocks

   The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),
   and 203.0.113.0/24 (TEST-NET-3) are provided for use in
   documentation.

4.  Operational Implications

   Addresses within the TEST-NET-1, TEST-NET-2, and TEST-NET-3 blocks
   SHOULD NOT appear on the public Internet and are used without any
   coordination with IANA or an Internet registry [RFC2050].  Network
   operators SHOULD add these address blocks to the list of non-
   routeable address spaces, and if packet filters are deployed, then
   this address block SHOULD be added to packet filters.

   These blocks are not for local use, and the filters may be used in
   both local and public contexts.

https://www.rfc-editor.org/rfc/rfc5737.html

[alemabrahao]

As far as I remember, IP 192.0.2.1 is the Cisco Controller's virtual interface IP for redirection to the captive portal, but I don't remember the same applying to Meraki.

Do you have a Cisco controller, either AirOS or Catalyst 9800?

https://www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/108501-webauth-...

[SatishJ]

There is no Cisco Controller, we have all our infra with Cisco Meraki SD-WAN and access points are also Meraki

[alemabrahao]

As reported, Cisco uses this address range to redirect the captive portal to the controllers.

As far as I remember, this isn't the case with Meraki. I don't know the AP model you're using, but I would perform a packet capture to confirm it's not a false positive.

[SatishJ]

This issue isn't happening all time, once in 15days like that as far as I remember, which started recently. We are using MR44 

[alemabrahao]

Well, the point is that this address is reserved for documentation or, in the case of Cisco (traditional controllers), it's used for the virtual interface IP.

I still believe that performing a packet capture on your network is the best option.