A while ago, Jim Harrison from Microsoft started a thread in the ISAserver.org Discussion List called Think outside the GUI challenge #1. Because he discussed a scenario that might be useful for some folks, I summarized this thread here.
Scenario:
– ISA is connected directly to the Internet via a “manageable” DSL bridge
– ISA uses 123.123.123.123/24 static external IP; DG = 123.123.123.1
– Internal LAN uses 10.9.8.x/24
– DSL bridge has unchangeable 10.0.0.2/24 internal IP
– DSL bridge offers web-based management on that internal IP
Note:
– The DSL bridge internal IP is irrelevant to normal Internet access.
Because it’s operating in “bridge” (as opposed to NAT) mode, it’s effectively transparent to the ISA for Internet traffic.
Challenges:
1. Allow either ISA-local or ISA-internal to access the DSL bridge web interface.
2. Explain why the correct solution is impossible to implement if the ISP provides a dynamic IP.
Hint:
– The core of the solution has nothing whatsoever to do with ISA itself.
Challenge #1: Allow either ISA-local or ISA-internal to access the DSL bridge web interface.
For simplicity’s sake, we’ll use ISA-local traffic for this demo.
The original packet headers are built as (simplified):
Because Windows has no clear instructions on how to handle this destination IP, internal logic sends it as:
It should be obvious that this won’t work. Neither the destination MAC nor the source IP is correct.
So, we have to make sure that the packets are sent to the bridge instead of to the default gateway (layer-2). To accomplish that we need to bind a 10.0.0.0/24 IP address to the ISA interface. You can use the following command:
- netsh int ip add addr north 10.0.0.1 255.255.255.0
Adding the new IP address only instructs Windows that this is now a local subnet, creating the following headers:
At this stage the destination MAC is correct but not the source IP address.
Unless instructed otherwise, Windows always sends originating traffic using the default Primary IP (123.123.123.123) as the source address in the IP header. Since the bridge doesn’t understand how to respond to what it sees as non-local traffic, it simply drops it.
So, we have to make sure that the packets are sent with a source IP address belonging to 10.0.0.0/24 (layer-3). To accomplish that we need to create an extra persistent route. You can use one of the following commands:
– without RRAS
- route -p add 10.0.0.0 mask 255.255.255.0 10.0.0.1
– with RRAS
- netsh routing ip add persistentroute dest=10.0.0.0 mask=255.255.255.0 name=”North” nhop=10.0.0.1 proto=NONDOD preference=0 metric=1 view=both
- netsh routing ip set persistentroute dest=10.0.0.0 mask=255.255.255.0 name=”North” nhop=10.0.0.1 proto=NONDOD preference=0 metric=1 view=both
The part of the routing command that makes it work is specifying the new IP (10.0.0.1) as the gateway for this route. This causes Windows to “route internally” and results in the bridge seeing the 10.0.0.1 IP as the source IP.
When we add the new route definition, Windows now understands that some internal routing is required and forwards the packet this way:
Note that you can’t see these internal routing changes happening via NetMon or any other packet sniffer because it’s occuring in what’s known as “memory mapped networking”.
Challenges #2: Explain why the correct solution is impossible to implement if the ISP provides a dynamic IP.
In case of dynamic IP, a static IP can’t be assigned and that is necessary to get it working (cfr challenge #1).
HTH,
Stefaan