adimcev
Posts: 380
Joined: 19.Oct.2008
Status: offline
|
Till' Tom wrotes that article, may I help ? (if Tom does not mind, or if he minds, I hope he does not remember where he left his baseball bat... ) Say: (HostC/HostD)Internal Network---ISABranch----VPN Tunnel----ISAMain---Internal Network(HostA/HostB) Where is your library service located, behind ISAMain, on ISAMain's Internal Network ? If so, we can pretend that this service is hosted on HostA. Create the site-to-site on both ISAs without access and network rules(if you use IPsec tunnel mode, leave on both ISA the remote VPN gateway address added by default by the wizard to the remote network address range). On ISA Branch, create a network rule with a route relationship between remote site(let's call it Main) and Internal Network. For our fun, let's create an access rule allowing all traffic from Internal Network to Main and vice-versa. On ISA Main, create a network rule with a NAT relationship between the remote site(let's call it Branch) and the Internal Network. Keep this order, because it matters since this is a NAT relationship. What this NAT relationship means: For example when HostC pings HostA, the ping packet from HostC will be sourced on ISAMain with the IP address from ISA's internal interface(the first IP address in case for some reasons there are multiple IP addresses on this NIC). So HostA will see these ping packets as "coming" from ISAMain's internal interface IP address, it will have no clue that this packet was sent by HostC. In order to allow these packets on ISAMain, we can create an access rule allowing all traffic from Branch to Internal Network(just for test). Note that the HTTP packets coming from HostC to HostA will originally come from ISABranch sourced with ISABranch's IP address(by default due to the web proxy: for IPsec tunnel mode-this IP address will be ISABranch's external IP address-, for PPTP and L2TP-this IP address will be ISABranch's IP address from its internal PPP adapter - my bad - ||| actually is the IP address of the DDI interface(Main) created for the s2s on ISABranch(no strikethrough on this forum ?), an IP address obtained through IPCP from ISAMain, it depends how IP addresses are assigned for VPN connections on ISAMain, either by DHCP or static range) and not with HostC's IP address. If that represents a problem, you can use a web server publishing rule on ISABranch, and publish the HTTP server on HostA(remember to check the allow HTTP authentication checkbox on listener if that web server requires auth, since you're not using SSL so your connections to not be dropped), check on this rule the request appears to come from the original client option, select the Internal Network as the network on which ISABranch listens for requests, and from HostC access HostA by ISABranch's published internal IP address. Now in reverse, if HostA wants to reach HostC, you need a server publishing rule. Say you want to RDP into HostD from hostB. Create a server publishing rule for RDP server, the published server is HostD, and the network on which ISAMain listens is Internal Network. From HostB you will connect to HostD using ISAMain's published internal IP address. If you leave the default settings in place on this server publishing rule, the packets from HostB will appear to HostD with HostB's original IP address. Note that you do not need to create such a "general" network rule on ISAMain. For example, you can create a network rule with a NAT relationship between HostC and HostA, a network rule with a route relationship between HostD and HostA+HostB. So only requests from HostC to HostA will be NAT-ed, and requests from HostD to HostA and from HostD to HostB will be routed(the original source IP addresses will be preserved). And you can use access rule to allow traffic from HostA to HostD or from HostB to HostD, which can help with certain traffic, say Ping which cannot be "published". As you can see from above, with NAT rules, with access rules we cannot specify which IP address on ISA's adapter to be used for NAT when the translation takes place, the first one on the NIC will be used. I don't know if IPbinder (http://www.collectivesoftware.com/Products/IPbinder) may help in your situation(I did not try that). Adrian
< Message edited by adimcev -- 12.Nov.2008 12:01:57 PM >
_____________________________
Blog: http://www.carbonwind.net/blog Get Our ISA 2006 Book!: http://tinyurl.com/2gpoo8
|