<p>I have VPC A with CIDR <code>10.A.0.0/16</code> and VPC B with CIDR <code>10.B.0.0/16</code>.  I have VPC A and B peered and updated the route tables and from a server in <code>10.B.0.0/16</code> can ping a server in <code>10.A.0.0/16</code> and vice versa.</p>
<p>The applications on VPC A also use some IPs in the <code>192.168.0.0/16</code> range.  Not something I can easily change, but I need to be able to reach <code>192.168.0.0/16</code> on VPC A from VPC B.</p>
<p>I've tried adding <code>192.168.0.0/16</code> to the route table used for VPC B and setting the target of the peered connection. That does not work, I believe because <code>192.168.0.0/16</code> is not in the CIDR block for VPC A.</p>
<p>I'm unable to add <code>192.168.0.0/16</code> as a secondary CIDR in VPC A because it is restricted. See <a href="https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#add-cidr-block-restrictions" rel="nofollow noreferrer">CIDR block association restrictions</a> and <a href="https://stackoverflow.com/questions/66381126/how-do-we-allot-the-secondary-cidr-to-vpc-in-aws">related question</a>.  I understand it is restricted, but why is it restricted?  RFC1918 doesn't seem to say anything against using more than one of the private address spaces.</p>
<p>I've also tried making a Transit Gateway, attaching both VPCs, and adding a static route to the Transit Gateway Route Table for <code>192.168.0.0/16</code> that targets the VPC A attachment.  But still cannot reach that range from within VPC B.</p>
<p><strong>Is there another way to peer to both <code>10.0.0.0/8</code> and <code>192.168.0.0/16</code> CIDR blocks on the same VPC?</strong></p>
<h4>Updated, background info</h4>
<p>The VPCs are used by two different kubernetes clusters.  The older one uses project-calico that uses the default cluster CIDR <code>192.168.0.0/16</code> and pod IPs get assigned in that range.  The newer one is an EKS cluster and pod IPs are assigned from the VPC's CIDR range.  During the transition period I've got the two clusters' VPCs peered together.</p>
<h4>Route Table</h4>
<p>The route table for the private subnet for VPC A</p>
<pre><code>10.A.0.0/16    local
10.B.0.0/16    pcx-[VPC A - VPC B peering connection]
0.0.0.0/0      nat-[gateway for cluster A]
</code></pre>
<p>Route table for the private subnet for VPC B</p>
<pre><code>10.B.0.0/16    local
10.A.0.0/16    pcx-[VPC A - VPC B peering connection]
192.168.0.0/16 pcx-[VPC A - VPC B peering connection]
0.0.0.0/0      nat-[gateway for cluster B]
</code></pre>
<p>This does not work, of course, because <code>192.168.0.0/16</code> is not in VPC A's CIDR block, nor can it be added.</p>

Gangstead
<p>Calico creates an overlay network using the specified cluster CIDR (192.168.x.x) on top of VPC (A) CIDR, so pods/services in this k8s cluster can communicate. The overlay network routing information is neither expose nor usable for AWS route table. This is different from k8s cluster running in VPC (B) which uses VPC CNI that leverage on the VPC CIDR as the cluster CIDR.</p>
<p>Calico <a href="https://docs.projectcalico.org/networking/bgp" rel="nofollow noreferrer">BGP Peering</a> offers a way here but it is not going to be an easy route for this case.</p>
<blockquote>
<p>Calico nodes can exchange routing information over BGP to enable
reachability for Calico networked workloads (Kubernetes pods or
OpenStack VMs).</p>
</blockquote>
<p>If you must achieve pod to pod communication in different k8s clusters and networks but not via Ingress/LB, migrate one of the k8s cluster CNI to be the same as the other so you can fully leverage on their unique peering capabilities.</p>
