Every second a new firewall LAN message
-
Seems like multiple devices are using that 100.64 space – which is special address space. So your lan rules list lan net as your source then - this would also block that traffic.
well cisco catalyst switches will clearly let you track down where the devices are once you get the mac address from the sniff.
"192.1.1.0"
Typo? and you meant 192.168? Or you are using public space internally?
CIDR: 192.1.1.0/24
Customer: Bolt Beranek and Newman Inc. (C00012638) -
ok the packet capture, says this:
09:57:55.704554 a4:93:4c:fd:ce:41 > 00:50:56:88:78:f9, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 252, id 40057, offset 0, flags [none], proto ICMP (1), length 64)
100.64.1.187 > 1.2.3.4: ICMP echo request, id 40129, seq 1, length 44
09:57:56.663002 a4:93:4c:fd:ce:41 > 00:50:56:88:78:f9, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 252, id 22395, offset 0, flags [none], proto ICMP (1), length 64)
100.64.1.183 > 1.2.3.4: ICMP echo request, id 22481, seq 1, length 44
09:57:56.690039 a4:93:4c:fd:ce:41 > 00:50:56:88:78:f9, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 252, id 41378, offset 0, flags [none], proto ICMP (1), length 64)
100.64.1.190 > 1.2.3.4: ICMP echo request, id 41498, seq 1, length 44
09:57:57.471316 a4:93:4c:fd:ce:41 > 00:50:56:88:78:f9, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 252, id 13664, offset 0, flags [none], proto ICMP (1), length 64)
100.64.1.186 > 1.2.3.4: ICMP echo request, id 13671, seq 1, length 44
09:57:58.674457 a4:93:4c:fd:ce:41 > 00:50:56:88:78:f9, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 252, id 40058, offset 0, flags [none], proto ICMP (1), length 64Online Mac Checker:
A4-93-4C-FD-CE-04 CISCO SYSTEMS, INC., USA
00-50-56-88-78-0F VMware, Inc., USABut i checked now all Cisco Switches and our Virtual Machines and this two MAC adresses are not there to find? Any ideas to find the components?
-
Dude, what's 1.2.3.4 now?!?! Put your local networks on a RFC1918 range. Hell almighty!
-
we have no component with this ip 1.2.3.4?
-
Have have no clue what you have configured where since you managed to first hijack CGN space, then public space for your LAN. So we don't even know whether that 1.2.3.4 is some censored output or you yet again moved your LAN where they don't belong. Also, when you don't know what's on your network, you have a bit of a problem I'd say ::)
-
Online Mac Checker:
A4-93-4C-FD-CE-04 CISCO SYSTEMS, INC., USA
00-50-56-88-78-0F VMware, Inc., USABut i checked now all Cisco Switches and our Virtual Machines and this two MAC adresses are not there to find?
Those two MAC addresses aren't in your packet capture. That may explain why you can't find them…
Any ideas to find the components?
You may be more lucky if you look for the correct MACs instead…
Maybe 00:50:56:88:78:f9 is your firewall interface?
-
Yes, that is true but it is unfortunately an established structure which has been introduced 15 years ago by someone. Meanwhile, with servers, clients, printers and other electronic devices there nearly 200 homes, sometimes change is just as difficult. Will there but to worry me.
P3R, you thank 're right . ":f9" is the virtual pfsense as a target.
The trigger but I have not yet found and all Cisco devices searched. -
ICMP Hole punching is what you're seeing…
http://en.wikipedia.org/wiki/ICMP_hole_punchingThe traffic may or may not be nefarious in nature. I'd start checking devices to make sure they're not participating in a botnet.
-
this is a device
a4:93:4c:fd:ce:41
Yes I show a4:93:4c as cisco.. so you need it track down that device sending the pings to this 1.2.3.4 so you can figure out why its sending them
where exactly did you do the sniff? Is there another router between the sender and pfsense?
-
this is a device
a4:93:4c:fd:ce:41
Yes I show a4:93:4c as cisco.. so you need it track down that device sending the pings to this 1.2.3.4 so you can figure out why its sending them
where exactly did you do the sniff? Is there another router between the sender and pfsense?
It's the VMWare device that's sending the ICMP Packets out. You may have a compromised VM.
-
where do you see vm sending anything?
09:57:55.704554 a4:93:4c:fd:ce:41 > 00:50:56:88:78:f9
that is sending to a vm, but the sending mac is cisco
-
I must have read the packet trace wrong. Oops.
-
Dok - the OP stated their network is
"no our Lan is 192.1.1.0/24"
so I don't believe they are trying to actually use 100.64 space.. Or configured anything with an IP of 1.2.3.4
Seems odd seeing multiple source IPs from the same mac, so I would guess a router or AP downstream of where pfsense is seeing the traffic.
OP you need to track down what specific device that a4:93:4c:fd:ce:41 is, is traffic coming from something behind it? What is this device exactly?
-
Does pfSense have anything in its ARP cache for any of those CGN IPs?
Have you tried loading a box with nmap, putting it's interface IP in the CGN range and doing a scan? -
ok thanks for the help I have identified the cause. Gradually, the patch cord was removed and re- inserted until the duration inquiries have disappeared on the Main Switch. The result was that this is a Cisco device is our provider which is responsible for a private MPLS VPN tunnel. I now have the Provider sent the logs and note there to clarify that this is stopped.
Is it worth the private network in an RFC compliant convert? So we all Devices by
192.1.1.x / 24
in
192.168.1.x / 24
bring ?Does it then 192.1.2.x create sense due to broadcast and Performance for the server space? And if so, how and where this route I then in the PFSense. Is there a FAQ about?
I know VLANs are there also but the first are not a solution .
Many thanks for your help! :)
-
192.1 is not rfc19181 address space..
Why would they have been pinging 1.2.3.4?
-
192.1 is not rfc19181 address space..
Why would they have been pinging 1.2.3.4?
A lot of programmers wrote code that would attempt to ping the 1.0.0.0 /8 because the "knew it was not in use". Not any more. I forget the reasoning behind this. I think some of it is they wanted to use a public IP range internally and they figured it was safe, but now all /8s are in use. I remember reading a lot of these stories shortly after the 1.x block got handed out and some of the IPs like 1.1.1.1 were suddenly getting flooded with traffic from around thew world because of idiot programmers doing this sort of crap.
-
Does pfSense have anything in its ARP cache for any of those CGN IPs?
It wouldn't, they're sourced from the Cisco layer 3 switch's MAC address, so it's routing it from somewhere behind it. Checking the Cisco is the next place to track it down.
