Ultimately, the problem stemmed from a ping to an address
with the wrong subnet mask (auto-filled subnet) which turned
the address (which should have been routed) into a local broadcast.
Only the global broadcast, or a local broadcast should be accepted,
not a broadcast that should be routed.
This can be seen in Level 4, Small Subnets puzzle.
1.) fix router2 to be /31
2.) from pc1, ping pc2 (which turns into 192.168.1.3)
-autoIP filled in a subnet mask of 255.255.255.252
-therefore 1.3 is considered the broadcast IP.
-result: a local broadcast on the 192.168.2 network.
3.) from pc1, ping 192.168.1.1 or 192.168.1.4 works fine.
4.) edit firewall1, edit route to 192.168.1.1
-make no changes, just hit OK
5.) again from pc1 ping pc2
-now autoIP fills in subnet mask 255.255.255.0
-result: it works
The problem is easily seen most times when a DHCP range is canceled.
The cancel completely fails to work, and refuses to cancel until
correct values are put in start and end. (However, pressing the ESC
key sometimes helped.)
The problem is seen in the first puzzle if you ping
pc0, and then edit the 0.0.0.0 gateway. It auto-fills in
the last-used pc0 IP address, and canceling saves that change
instead of leaving the gateway at 0.0.0.0.
lastIP nicely saves some typing (although it has also confused
my student quite a bit I think), but since it updates WhatToEdit,
that becomes the "saved" value even during a cancel.
Instead, save the original value as a copy, and set back to
the original value when cancellng.
Perhaps it would be worth creating a reparse( NB_IPAddress)
function, but this was easy to just hack together.
Tested by pinging pc0, then editing the gateway and cancellng,
editing the IP address and canceling.
Next: don't add a canceled route
This was especially bad when lastIP filled in default values,
so this patch pretty much depends on the patch that cancels
the auto-filled lastIP.
This didn't cause a problem - it just cluttered up the routing
table with duplicate, undeletable routes.
ping source is firewall ? set sourceIP to vpn IP address
The problem can be seen easily in Puzzle 2, VPN Demo.
From firewall2, ping firewall0. The ping request tunnels
to firewall0 with a source address of 0.0.0.0, and so
the reply returns untunneled and drops at the default gateway.
This patch probably needs to be tweaked a bit in case it
covers too many situations, but in general something like
this is needed.
