The "instability" would only exists if both ends of the VPN tunnel are using different values for the subnets on either side (aka, the "Encryption Domain"). Let me explain...
There are three main symptoms of instability you would encounter if the subnets don't match perfectly. I'll start by describing a "fully working" tunnel, then list out the possible scenarios for a misconfigured tunnel where the subnets are not the same.
Fully Working Example
For this example, let's assume two sites are connecting to each other via VPN:
Site A Site B
Both sites have two /24 networks. If SiteA is configured to list out each /24 individually, SiteA would have something like this in its Encryption Domain:
10.1.0.0/24 --> 10.2.2.0/24
10.1.0.0/24 --> 10.2.2.0/24
10.1.1.0/24 --> 10.2.3.0/24
10.1.1.0/24 --> 10.2.3.0/24
Each of these pairs of /24 networks would each receive its own set of IPsec tunnels (one for outgoing traffic, one for incoming traffic), identified by a specific SPI (Security Parameter Index -- fancy term, its just a 8-hex digit label for a set of security algorithms and keys -- also known as a Security Association).
So for example, SiteA might have something labeled like so:
SiteA Pairs Outbound SPI Inbound SPI
10.1.0.0/24 --> 10.2.2.0/24 0xBBBB1022 0xAAAA1022
10.1.0.0/24 --> 10.2.3.0/24 0xBBBB1023 0xAAAA1023
10.1.1.0/24 --> 10.2.2.0/24 0xBBBB1122 0xAAAA1122
10.1.1.0/24 --> 10.2.3.0/24 0xBBBB1123 0xAAAA1123
If SiteB wanted to be completely correctly configured, must have the exact mirror configuration for its Encryption Domain. So in a perfect world, it would look like this:
SiteB Pairs Outbound SPI Inbound SPI
10.2.2.0/24 --> 10.1.0.0/24 0xAAAA1022 0xBBBB1022
10.2.3.0/24 --> 10.1.0.0/24 0xAAAA1023 0xBBBB1023
10.2.2.0/24 --> 10.1.1.0/24 0xAAAA1122 0xBBBB1122
10.2.3.0/24 --> 10.1.1.0/24 0xAAAA1123 0xBBBB1123
Notice, the SPIs and the networks are perfectly flipped. The Outbound SPI that SiteA uses for 10.1.0.0/24 to speak to 10.2.2.0/24 is the Inbound SPI that SiteB uses for 10.2.2.0/24 to speak to 10.1.0.0/24. This is by design.
Now, lets assume SiteB is misconfigured, and decides to use 10.1.0.0/23 to summarize SiteA. From a purely subneting perspective, that should be perfectly acceptable, right? I mean, two /24's definitely add up to a single /23. However, because of how IPsec negotiates its tunnels, it will cause some issues.
If SiteB initiates by proposing a
10.2.2.0/24 --> 10.1.0.0/23, SiteA will reject the request, because SiteB is trying to create a tunnel for something that is "outside" what SiteA intended to protect (remember, SiteA is still using the four, individually listed out /24 pairs).
If SiteA initiates by proposing a
10.1.0.0/24 --> 10.2.2.0/24, SiteB will accept the request, because 10.1.0.0/24 is within what SiteB is configured to protect (10.1.0.0/23).
(1) So initially, the first set of symptoms will look like the tunnels can only build in one direction (if SiteA initiates).
If SiteB is configured with the /23, and SiteA initiates... the tunnel will build. And when 10.1.0.0/24 and 10.2.2.0/24 try to communicate.... everything will work just fine. BUT, remember, SiteB isn't considering 10.1.0.0/24 as a /24, it considers it as a /23. So if at some point in the future, SiteB tries to send some traffic to 10.1.1.0/24, it will use the pre-existing SPI/tunnel. Which means SiteA will receive something from SiteB with a source of 10.2.2.0/24 (expected) and a destination of 10.1.1.0/24 (unexpected). Which in the Cisco world, will cause a syslog message like this to be generated:
%PIX|ASA-4-402116: IPSEC: Received an protocol packet (SPI=spi, sequence
number= seq_num) from remote_IP (username) to local_IP. The decapsulated inner packet
doesn't match the negotiated policy in the SA. The packet specifies its destination
as pkt_daddr, its source as pkt_saddr, and its protocol as pkt_prot. The SA specifies
its local proxy as id_daddr /id_dmask /id_dprot /id_dport and its remote proxy as
id_saddr /id_smask /id_sprot /id_sport.
(2) The second set of symptoms would look like certain subnets can not communicate through the VPN, and your syslog is full of messages like the above.
Same scenario as the last time, except this time SiteA decides it wants to send some traffic from 10.1.1.0/24 to 10.2.2.0/24. Remember, the already existing SPI from SiteA's perspective is 10.1.0.0/24 to 10.2.2.0/24. So this new traffic will require a completely new tunnel. SiteB will receive the request for a new tunnel/SPI and can either reject it, since it considers the original SPI for 10.1.0.0/23 (although, this is rare). More often, SiteB will accept the request to build a new tunnel from 10.1.0.0/23 to 10.2.2.0/24, which will cause SiteB to tear down the old tunnel. And now you have the same set of symtoms in reverse, 10.1.1.0/24 speaking to 10.2.2.0/24 works, but 10.1.0.0/24 speaking to 10.2.2.0/24 doesn't.
(3) The third possible set of symptoms here would look like tunnels rebuilding "randomly", and certain subnets keep loosing connectivity to the other side.
NOTE: A lot of the reactions of how the Firewall/Router will work will different depending on the vendor you are using. Most of the examples above are from my years of working with Cisco ASA and PIX products. YMMV, but even still, the concepts are still relevant and apply
So there you have it. What it should look like is a perfect mirror reflection of each other. If you want to summarize the /24's into one /23, that is perfectly fine, as long as BOTH SIDES DO IT THE SAME WAY. If one side decides to do something the other side isn't, you will run into some of the issues described above.