Welcome to ISAserver.org

TSGateway in semi-DMZ scenario

Users viewing this topic: none

Logged in as: Guest

Printable Version

All Forums >> [ISA 2006 Firewall] >> DMZ >> TSGateway in semi-DMZ scenario

Page: [1]

Message

<< Older Topic Newer Topic >>

TSGateway in semi-DMZ scenario - 25.Aug.2008 10:13:43 AM

allybee

Posts: 17
Joined: 19.Apr.2008
Status: offline

Hello,
I'm having issues with publishing TSGateway HTTPS, but let me describe my env first.
I got two public ranges, one used by ISA to publish several internal servers and for outgoing internet access. The other range is configured as DMZ and is routed via ISA - so it is DMZ with public address space and my ISP set this range to be forwarded to one of external IPs from the first range. This works fine.
Now, I want to publish TSGateway server from interal subnet, however I'm out of free IP addresses in the first range, so I want to add additional IP from DMZ range to ISA's DMZ NIC (so I will have two IPs defined on that interface), then allow HTTPS traffic between external and that additional IP. Then use web publishing wizard to publish internal TSGateway on that DMZ IP and additionally on internal IP address via HTTPS.
I have set up certificates on both TSGateway and ISA box. Everything works fine from internal (even when traffic goes via ISA, as split-DNS and same internal and external namespace gives me possibility to use one certificate), however I can't get this working from external - I get RDP client error stating that certificate expired or has been revoked.
Now the question is can I publish servers using IP addresses from DMZ range when these are bound to one of ISA interfaces?

Thanks, Marcin

Post #: 1

Featured Links*

RE: TSGateway in semi-DMZ scenario - 28.Aug.2008 10:16:30 AM

pwindell

Posts: 782
Joined: 12.Apr.2004
From: Taylorville, IL
Status: offline

quote:

I got two public ranges, one used by ISA to publish several internal servers and for outgoing internet access. The other range is configured as DMZ and is routed via ISA - so it is DMZ with public address space and my ISP set this range to be forwarded to one of external IPs from the first range. This works fine.

What does that even mean? You don't "forward a range to an IP# in another range". When two Public Subnets exist together they must be sequential and must be able to be "supernetted" into a single route upstream (at the ISP). The ISP then treats both as a single combined subnet and passes the traffic to the Router on your end. The router on your end is the only router at that point in the process that knows the second range is a different subnet and would know what interface to direct it to.

quote:

Now, I want to publish TSGateway server from interal subnet, however I'm out of free IP addresses in the first range, so I want to add additional IP from DMZ range to ISA's DMZ NIC (so I will have two IPs defined on that interface), then allow HTTPS traffic between external and that additional IP. Then use web publishing wizard to publish internal TSGateway on that DMZ IP and additionally on internal IP address via HTTPS.
I have set up certificates on both TSGateway and ISA box. Everything works fine from internal (even when traffic goes via ISA, as split-DNS and same internal and external namespace gives me possibility to use one certificate), however I can't get this working from external - I get RDP client error stating that certificate expired or has been revoked.

There is more than one thing here. I'm not sure what to start with.

Well, first,...what you are wanting to do regaurdless of what specifically you are publishing will require two Publishing Rules if the Net Relationship is "NAT" between the LAN and DMZ. With TSG it will probably need three Publishing Rules (2 https, 1 RDP).

First this does not gain anything if you are out of IP#s. The DMZ does not listen to the Internet,..the External does. Publishing from External to Internal,..or from External to DMZ then to Internal does change the fact that you need to use an External IP#.

Second, Publishing the TSG only provides the means for the user's browser to "pickup" the RDP ActiveX Control,..it does not,..does not,..provide a connection to the machine you want to remote control with RDP. The RDP ActiveX Control then makes a direct and normal RDP connection to the actual target machine,...so therefore you also need to publish RDP from External directly to the target machine so that the ActiveX Control and use it.

_____________________________

Phillip Windell
www.wandtv.com

(in reply to allybee)

Post #: 2

RE: TSGateway in semi-DMZ scenario - 28.Aug.2008 6:02:31 PM

mylo

Posts: 138
Joined: 26.Mar.2002
Status: offline

Phillip,

I've seen you post in the past so I'll tread carefully :-)

I think what he means is that he has 2 sets of public IP address ranges (non-sequential)... say a /30 address range for his external firewall.. and say a /28 range for his DMZ (ISA connection)... they're not overlapping.. I can't talk about the States but this is quite common in Europe, particularly with DSL connections...

e.g.

1.2.3.4/30 (notwithstanding the incorrect notation)
and
3.4.5.6/28

So the /30 is a throwaway provided by the ISP and he's paid for 14 public IP's in the secondary range with the ISP routing thru the /30 gateway to the 3.4.5.6/28 range accordingly... I have this setup and works fine ....

On the TS front he means the TS Gateway in Windows 2008, so it's an HTTPS connection into RDP over HTTPS connection from the RDP client .. where I get confused is how he's configured the publishing rules....

Marcin, I think the questions you're asking don't relate to the problem you've described in your first few paragraphs.. have you configured a policy on the ISA server allowing it to communicate with your CA to download CRL's?

If you stick an RDP client on the DMZ side can you RDP thru ISA to the TS Gateway... take small steps first and try and resolve from the DMZ and then move externally...

Cheers,
Mylo

(in reply to pwindell)

Post #: 3

RE: TSGateway in semi-DMZ scenario - 29.Aug.2008 9:48:16 AM

pwindell

Posts: 782
Joined: 12.Apr.2004
From: Taylorville, IL
Status: offline

quote:

I've seen you post in the past so I'll tread carefully :-)

Don't worry about that. People always interpret way more emotion into my posts than what I am really feeling when I write them. If I'm really ticked off, everyone will know

It is difficult to emphasis points in a post without people thinking I am mad about something. It's always been that way with me,..I don't expect it to change. I'm an ex-truck driver of 10 years, I guess I never developed that Corporate skill of writing "softly",..I'm not too good in the Conference Room either for some reason.

Anyway, I think he should test using the regular Remote Destop Client from a machine outside the system as the user would be. Then target the machine that will actually be controlled by RDP (not the TSGateway site). The TSGateway doe not "route" the RDP,..it does not do anything with the RDP,..it just provides the RDP ActiveX Control to the user. From that point the RDP ActiveX Control just operates just like the regular Remote Desktop Client.

In the end all the TSGateway really does is keep the user from having to go to the Start Menu and choosing "Start-->Assessories-->Communications-->Remote Desktop Connection" and entering the target machine name.

Here is the article I get this idea from. There are 3 parts, this is part 1:

Publishing Remote Desktop Web Connection Sites with the ISA Firewall Part 1 � Remote Desktop Web Services Concepts
http://www.isaserver.org/tutorials/Publishing-Remote-Desktop-Web-Connection-Sites-ISA-Firewall-Part1.html

I am assuming that "Remote Desktop Web Connection" and TSGateway are either the same thing or at least work the same way.

_____________________________

Phillip Windell
www.wandtv.com

(in reply to mylo)

Post #: 4

RE: TSGateway in semi-DMZ scenario - 29.Aug.2008 3:41:26 PM

mylo

Posts: 138
Joined: 26.Mar.2002
Status: offline

Phillip,

lol.... i was referring to your broad experince (as per your previous posts), rather than your temper, but I can see how my comments might have alluded to the latter

Agreed with regards the testing. With regards TSGateway behaviour (under Win2k8 at least), from what I see he's running Windows 2008 and not using the ActiveX Control... so I didn't think Tom's article is relevant here.. since this is a Windows 2008 box .. with TSGateway support, he calls the external FQDN of te ISA directly from the RDP client (6.x) .. there's a tab in the configuration where you can specify the gateway settings.... this means an SSL connection into ISA.. ISA doesn't authenticate at the listener, it just proxies the connection to the TSGateway which in turn then communicates with the "called" Terminal Services machine, based on the IP address the user has specified in the RDP client... this way I can stipulate the IP address 192.168.1.1 (an obvious internal address) from the outside... the RDP client recognises this as non-local and forwards to the FQDN of the "gateway" I've set in my client.. in this case ISA... ISA, assuming web publishing rules have been set up correctly, then forwards the connection to the TS Gateway.... as far as I'm aware the behaviour is akin to RPC over HTTPS.

Lets see what our man has to say when I posts back .. the situation might be a little clearer then...

Cheers,
Mylo

(in reply to pwindell)

Post #: 5

RE: TSGateway in semi-DMZ scenario - 29.Aug.2008 4:52:45 PM