Great article! I have been planning to do something very similar myself.
I just have one question. You made these comments: "There is an important configuration setting that we must enforce on all of our Web and Server Publishing Rules. For each publishing rule, you need to make sure the ISA firewall replaces the source IP address of the external client with its own address. The reason for this is that the ISA firewall is not the default gateway for the corporate network servers. If we allowed the original external client IP address to remain as it is, the responses from the published servers would be sent to the internal interface of the Netscreen device, and then forwarded from the Netscreen’s external interface IP address to the external client. Since the external client made the request to the external IP address of the ISA firewall, and not the external IP address of the Netscreen firewall, the response will be dropped by the external client as an unsolicited inbound connection."
Is this really necessary? I know the servers and all the workstations on the internal network need to have the netscreen device as the default gateway, but the netscreen can have a default gateway as well. Can you make the ISA server the default gateway of the netscreen box? You can have static routes for the remote branches but have everything else go through the ISA server. The requirements would infer that only the vpn traffice to the remote sites go through the external interface of the netscreen box. Is that a correct assumption?
You bet! In fact, I thought I would mention that option in the article, but then thought that might confuse things for some people. But you're absolutely right, if you configure a static route to the remote VPN gateway on the Netscreen device, and make the ISA firewall's internal interface the default gateway of the Netscreen, then everything outbound except for that to the remote site network will go through the ISA firewall.
I do have another question. The design I put together was very similar (I had a generic firewall instead of Netscreen). The one difference was that I had the external nic of the ISA server connected back into the hardware firewall. Therefore the hardware firewall would have 4 Interfaces. 1 external interface connecting to the Internet. 1 interface connecting to perimiter 1 (external Interface of ISA), 1 interface connecting to perimeter 2 (Internal interface of ISA) and 1 interface connecting to the Internal Network. I guess in the end, I'm not sure exactly why I did that. I guess I was thinking having only one path to the Internet was a best practice. I also thought I would have more control over the traffic as well, since I could control the routing among al the interfaces better. Is this design overly cumbersome or does it have some merit?
In the scenario discussed in the article, there is really only one path to the Internet, since the Netscreen is only allowing connections to the remote site network, and forwards Internet bound connections to the ISA firewall.
I think your design might be a little more complex than required
Thank you very much for your article! Following Rice's questions, I am considering a setup where it might make sense.
I have a NetScreen 5GT Extended with two DMZ ports, besides the two Trust and one Untrust.
Unfortunately, for now, I have only one public IP available. In that case, I will need the NetScreen's Untrust interface for all outbound traffic to keep the current VPN setup. In order to avoid the Unihomed 'Hork Mode' I would like to deploy ISA with two cards and benefit from the advanced security features. The NetScreen supports Dual DMZ, so it must be possible to attach the ISA's internal NIC to DMZ1 and the external to DMZ2. This will allow me to route any outbound traffic as Rice suggested.
It seems to me that by doing so, I create some sort of perimeter network using the two DMZ zones on the Netscreen and thus avoiding the need for a direct connection to the internet for the ISA server.
Do I miss something? C.q. do you think it will work using only 1 public IP and using the Dual DMZ on the Netscreen?
Thank you very much for your support.
< Message edited by Arcesilaus -- 21.Dec.2006 10:07:02 AM >
You could do that. The external interface can be connected to one DMZ and the Internal interface can be connected to the other DMZ. Just make sure the definition of the default Internal Network on the ISA Firewall includes the internal DMZ and all internal addresses behind the Netscreen.
Thanks to your encouraging answer, I've worked recently on testing ISA in the DMZ as suggested. My network lay-out is displayed in the picture:
I've succeeded to setup the ISA server as an edge firewall and included the DMZ 2 subnet in the 'Internal network'. Since NAT is applied on the Netscreen firewall, all network rules on the ISA server are on Route mode. Web proxying and publishing websites are working without problems.
Now here's my problem: Incoming e-mail is denied by the Enterprise default rule, since it does not match my publishing rule (the published server is my SMTP relay with IP 192.168.200.11, that resides in the DMZ 2).
The logs show that the ISA server sees incoming SMTP traffic as sent to its own external IP (192.168.100.11 in the DMZ 1). Applying NAT to the network rule from the external to the internal network solves the issue, but causes problems with the published websites. In order to keep it "simple", I would prefer to leave the networking rules on Route for all networks.
My question therefore is: Is there a way to have the ISA server accept incoming SMTP traffic at its own external IP (192.168.100.11) and direct it to the published e-mailserver (192.168.200.11) without applying NAT?
Incredible how quickly you respond, even to such an old thread!
Well, the e-mail server is not yet configured with the ISA server as its default gateway, since I haven't placed it in production yet.
Would that really solve the issue for incoming traffic? It sounds a bit odd to me, if I am honest. Does it have anything to do with being configured as a secureNAT client? If so, I might have to digg into that a bit deeper...
Is there a way to test it before reconfiguring the e-mail server?
(edit: typo - Since I am currently in Nice only speaking French, my English has not really improved )
< Message edited by Arcesilaus -- 8.Aug.2008 6:27:50 PM >
That's correct. If the mail server is a SecureNAT client, then it has to have the default gateway be the ISA firewall, or a router that routes the outbound connections to and from the mail server through the ISA firewall.
However, you can change this by configuring the SMTP server publishing rule to change the source IP address to the IP address of the ISA firewall.
When using Route, you should target the packet for the actual IP address of the destination. However, the "port stealing" feature of ISA should allow you to use the external address of the ISA firewall -- it's just that you shouldn't need to depend on port stealing and that you should use the actual IP address of the destination server.
Thanks for the info! I've been thinking it over: a 'simple' Route relationship won't work, since the Netscreen Firewall also has access to the DMZ 2, with subnet 192.168.200.0. A MIP or VIP towards the actual IP of the mailserver thus would not be sent to the ISA in DMZ 1, but directly to the mailserver in DMZ 2.
That leaves me with three options:
Adding a NAT relationship with the mailserver only, by adding the mailserver as a computer object and specify that particular network relationship above the general Route relationship
It seemed to me that a Route relationship was preferred since the reverse-proxy would took care of the problem for web-publishing rules, but that indeed won't not work for non-web-servers. Is any of the three solutions above preferred over the others?
For now, I will first have to configure the ISA server a bit further so I can set the mailserver as a SecureNAT client while keeping the existing setup working (I've been bypassing the ISA server so far for incoming e-mail) and keep the ability to manage it over RDP. It will probably have to wait for a while (priorities are set by others), but I'll keep this thread posted!
I prefer to change the entire relationship to NAT, as it makes it a more simple configuration and perhaps a bit more secure.
You're right that this is not an issue in either case with Web Publishing, since the Web Proxy listener will always intercept the request and you should configure DNS to be the address on the external interface (or the public address on an upstream device that forwards to the external interface).
I've changed all non-localhost network rules to NAT and re-created the firewall policies. I've been able to publish Exchange, multiple websites and, finally, the e-mailserver.
The e-mailserver is still not a SecureNAT client (gateway is still the Netscreen), but by changing the 'to' option on the ISA server to 'appears to come from the ISA server' and adding the ISA server in the DMZ server list of my Antispam application, everything works just fine!
It has thus been proved that with a dual DMZ setup of the Netscreen it is possible to implement an ISA 2006 in Edge Mode without having to break the existing IPSEC VPN infrastructure.
Thank you very, very much for your help. I've definitely learnt a lot by trial and error and I am starting to feel comfortable with maintaining the ISA server.
P.s. For playing around with custom HTML forms and publishing Citrix Secure Gateway without breaking the SSL connection, I might need a second public IP after all
Tom or Deb, I am struggling with a config very similar to the one layed out in this older article, specifically the diagram 7 proposed.
We have acquired a small firm with 2 branch offices that I need to integrate with our existing Corporate domain. This is a temporary configuration as I migrate the netscreen out of the picture. I want to join all of the client machines from domain 1 to domain 2, and then temporarily share the file server and printer resources from domain 1 to those domain 2 clients while I work on migrating the users/machines at the other branch site the same way. I have the TMG Site-to site working well, but every time I try to connect the tmg to the existing domain 1, it breaks the link to the internet and thus the site to site.
I have three NICs in the tmg server and I have tried it as a dmz and internal network, but it still breaks the connection. Can you point me to a potential resource or suggest a place to look for help? Thanks DG
< Message edited by dglasgow -- 21.May2013 4:02:17 PM >