suppose we have two networks net1 = 18.104.22.168/18 and net2 = 22.214.171.124/22 and if we have a packet with destination IP as 126.96.36.199. So, according to longest prefix matching rule, we send this packet to net2. Now I have a doubt that all the packets which match with both networks are sent only to net2, instead, it might be possible that some actually belong to net1. So isn't this incorrect because we are not sending to the actual destination?
So, according to longest prefix matching rule, we send this packet to net2.
That is correct.
Now I have a doubt that all the packets which match with both networks are sent only to net2, instead, it might be possible that some actually belong to net1.
This isn't possible unless you have another, even more specific (longer) routing table entry. In any case, this problem indicates overlapping subnets which are a general design error.
So isn't this incorrect because we are not sending to the actual destination?
A router always forwards according to its routing table (or routing policy when policy-based). There is no might be.
If you do need to provice simultaneous access from overlapping networks (including the special case: two distinct but equal networks), for example to connect two RFC1918 networks, you will need policy based routing with stateful firewall. With stateful fw you mark connections originating from these networks based on interface, which received packets. With PBR you send responses to that interface (to be specific: you create a rule to direct marked packets to the appropriate routing table, as each routing table needs to be unambiguous).
According to the connectivity you require, i.e. - if you only want to provide access from the overlapping networks to the services you provide, or if you need also backward connectivity, you might need NAT as well - just map one of the networks out of the overlapping range; stateless NAT might be enough for some cases. Of course from your perspective one of the networks would be accessible under different IPs than actually assigned locally.
(my comment merits expansion)
IOS -- at least versions you'll find today -- don't allow interfaces to overlap:
rtr1841(config)#int loopback 10 rtr1841(config-if)#ip address 188.8.131.52 255.255.192.0 rtr1841(config-if)#int loopback 11 rtr1841(config-if)#ip address 184.108.40.206 255.255.252.0 % 220.127.116.11 overlaps with Loopback10
Linux -- and systems like it (*BSD, Solaris, etc.) -- will allow it:
root@r610-b8:~# ip -4 addr 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 inet 192.168.51.20/24 brd 192.168.51.255 scope global eno1 3: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 inet 192.168.51.129/28 scope global eno2
With ip-forwarding and proxy-arp enabled, this setup does actually work. The machine acts like a router (ip-forwarding) while bridging the two segments (proxy-arp). Nodes within the smaller segment use 129 as their router. Nodes within the larger segment will ARP for addresses across the entire /24, because the netmask says it's on-the-wire local; .20 will answer those requests with its own MAC and forward traffic into the /28, so long as it has a MAC for the destination.
This is a Highly Undesirable Setup™. It's a 1970's era legacy construct. It's just bad practice to divide and stack networks like this. I did it out of simplicity and address sanity for openstack development. (dev environments can be messy)