Follow Up on "A simple routing table trick"
Recently I reviewed my article A simple routing table trick and decided to finally check it out in my lab. I must admit that I didn't test out that scenario at the time of writing that article, mainly because I could rely on a trusted source ... 😉
In my lab http://users.skynet.be/spouseele/VPC-SPLAB.pdf I added the IP address 10.10.10.10/24 to the Local ISA external interface (192.168.1.10/24) and the IP address 10.10.10.30/24 to the Local ROUTER interface (192.168.1.30/24). The device ROUTER, a Windows 2003 SP2 RRAS server, was used to fulfil the role of the DSL Bridge shown in the original article.
The resulting IP configuration on the Local ISA server was:
The resulting routing tabel on the Local ISA server was:
The funny part was now that I did *not* need to define a static route to make sure that the source IP address '10.10.10.10' was used for the traffic destined for '10.10.10.30'. It happened automatically as well when testing from the Local ISA server itself as from behind it (Local Internal Network 192.168.22.0/24). Take note that I tested this scenario with ISA 2006 on Windows 2003 SP2. Obviously, I was a little bit surprised and contacted Jim Harrison to check out if he could confirm my findings. Here is his answer:
When I was working through that discussion (my own DSL bridge is what prompted the investigation), I noted that the routing table was built using the default gateway, rather than the local-net IPs. That's what prompted my inclusion of the manual route.
Since then, I noted (as did you) that the manual route shouldn't be necessary, and in fact, when I built a replacement ISA (moving to 2006), this was not required. I think it may have been because I had so many routes defined in RRAS that this was required, but I can't say for certain now because it's gone...
Thus, assuming no route is defined for a "super-net" of the subnet used between the ISA server and the DSL Bridge, it shouldn't be necessary to configure a persistent static route to make it work. Also, it might be a good idea to minimize the mask of that subnet in order to avoid a possible IP conflict. In the above example, the smallest subnet we could create is 10.10.10.0/30 (mask 255.255.255.252). This gives us only two valid IP's: 10.10.10.1 & 10.10.10.2. Of course, if such a "micro-net" can be used depends on the IP configuration capabilities of the LAN interface of the DSL Bridge, at least when playing by the book.