Internet Protocol Version 4, Src: 10.1.73.73 (10.1.73.73), Dst: 10.1.10.71 (10.1.10.71) This is what I'm seeing. The problem is that these are 2 diffrent networks and i don't have any rules set up for them to see each other on my firewall, so i'm wondering how i can find that out. Thanks asked 13 Jan '16, 07:29  kobe 310 |
One Answer:
Too little information given, but if you look just at a single packet, you can merely see that the src machine has sent such packet and sent it to the dst. This does not imply that this packet has ever made it to the destination machine. Can you be more specific about what really bothers you and why? answered 13 Jan '16, 08:11  sindy |
i guess what i'm asking is, since wireshark showed it, it must be, and how would 73.73 even know that 10.71 was a destination , they are on 2 separate networks, and shouldn't be able to see each other at all.
this is going through a cisco asa firewall, with these 2 on seperate interfaces within the asa,which i just learned how to set up, so i guess i would just like to know how they know about each other, when i would think it would be impossible.
It doesn't bother me, just trying to figure out how to use wireshark, new to this, but not good at reading and understanding, hands on is best for me.
Thanks
It seems to me that Wireshark is not the main subject here :-)
An application which sends a packet to some destination IP may have learned about the very existence of that IP by several means:
it could have been manually (statically) configured to use it
it could have received it as an answer to a DNS query, like "which IP address represents hostname my.forged-domain.org?"
it could have received that IP inside a message of some other protocol (e.g., a Voice over IP control protocol like SIP may indicate a destination for an audio or video stream which may be a totally different machine than the one sending the SIP message)
In all the above cases (and maybe some others too, these are typical representatives):
the machine sending the packet didn't need to be in contact with the destination of the packet previously,
the source of the information about existence of the dst IP has no knowledge that there is some packet filtering device between the src IP and the dst IP.
Or, from the perspective of verification of your ASA configuration: if you can see, at the machine at which you capture, that packets have arrived to it from an IP for which it should not be accessible, then your ASA (or a firewall in general) is not configured properly. If you only can see packets with src IP of the machine at which you capture, and only their dst IPs belong to machines which should not be accessible to it, it is not an indication of an issue of ASA configuration.
Awesome, thanks alot for going into detail!!!! ASA definitely configured right, cisco tech support helped me set up.
would it be possible to trace and track what is causing that, i love challenges.
Sure, that is what Wireshark has been made for. But it is much easier if you have a look at some network protocols' theory first, or, if tutorials make you sick, at least get acquainted with the network traffic by observing regular behaviour, like e.g. opening a not-yet-visited web page, which should first cause a DNS query to the site name, and then a http GET request to (one of) the IP address(es) which the response to that DNS query has indicated (or about a hundred occurrences of that scenario if by chance that site is full of advertisements from different sources).
OK, Thanks for your help!!!