Re: [pfSense] RDP port forward based on destination name.

[Chris Buechler]

On Fri, Mar 28, 2014 at 9:54 AM, greg whynott  wrote:
> thanks for all the suggestions folks!   While very nitchy and sure not to be
> a wildly popular function,  it would be nice to see, "policy-routing/nating"
> based on matching an ACL which can make decisions based on data from the
> higher layers.
>

It's not that simple. What you have to do in the back end for
something along those lines is ugly, you have to terminate the
connection on the firewall, then have a proxy of some sort make the
connection to the back end. Not bad for web servers, web reverse
proxies have been common for quite some time, but for something like
RDP it's ugly. In the described circumstance, it's impossible to know
the hostname until well past the TCP session being established, so
it's impossible to just port forward the TCP connection to the
appropriate back end server. For something like this, Microsoft's
remote desktop gateway is the best bet under the constraints noted
here.
___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] RDP port forward based on destination name.

[greg whynott]

thanks for all the suggestions folks!   While very nitchy and sure not to
be a wildly popular function,  it would be nice to see,
"policy-routing/nating" based on matching an ACL which can make decisions
based on data from the higher layers.

his set up is one comprised solely of virtual hosts and networks (excluding
the router/firewall which run on its own hardware) under an ESX
environment.  They have about 12 customers and each has VMs and their own
L2 network and hosts.

For now it looks as if the jump host will be the best go.   Have one set up
where all the clients connect to and based upon who they log in as, will
determined what they see/have access to.

The VPN idea is a good one but they would rather not add more gears to the
machine which may generate support issues.


thanks again and have a great weekend,
greg




On Thu, Mar 27, 2014 at 6:37 PM, Jonathan Bainbridge
wrote:

> Remote Desktop Gateway, built into Windows 2008 and 2012. Put it behind
> the pfSense, port forward the rdp port to the RDG. It authenticates the
> user and the user can connect to any internal machine.
> In the Remote Desktop Connection you can enter the information for the
> RDG. Protect using an SSL on the RDG.
> Bonus, you can also setup Remote Desktop Web Services so you can have
> programs on Terminal Services available... Note, that part DOES require IE.
> On Mar 27, 2014 2:37 PM, "greg whynott"  wrote:
>
>> Hello,
>>
>> I'm not very familiar with TMG from Microsoft but a client I am helping
>> migrate to pfsense from TMG has asked me if they'll be able to use the RDP
>> port forward in the same way as TMG handles it.
>>
>>
>> Apparently there is a function within TMG which acts similar to named
>> based virtual web hosts,  where it parses the DNS name from the request and
>> makes a forwarding decision based on that bit of information.
>>
>> For example,  the firewall only has 1 public IP facing the internet.
>>
>> if you RDP to: you'll land on the internal server:
>>
>> host1.foo.com  10.101.1.2
>> host2.foo.com  10.101.3.4
>> host3.foo.com  10.101.1.8
>>
>>
>> host1,2 and 3 all resolve to the same public IP.  And we are not
>> specifying ports.
>>
>> That is the behaviour he is hoping to achieve,  where he can RDP to
>> various internal machines without referencing ports.
>>
>>
>> Sound do-able?If pfsense can not do this,  are you aware of anything
>> out there that can aside from TMG?
>>
>> -g
>>
>>
>>
>>
>>
>>
>>
>> ___
>> List mailing list
>> List@lists.pfsense.org
>> https://lists.pfsense.org/mailman/listinfo/list
>>
>
> ___
> List mailing list
> List@lists.pfsense.org
> https://lists.pfsense.org/mailman/listinfo/list
>
___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] RDP port forward based on destination name.

[greg whynott]

Hi Walter,

Apparently RDP must use parse-able strings within the request as well,
after reading your post I did a quick tcpdump and within the TPKT headers
there is the hostname string of the machine I'm connecting to.

bit messy but here it is,  ad01.workplacehere.com being the host I'm
connecting to.

../*..Cookie: mstshash=g.whynott
.'.+.#.,.$...
.@.2.j.8...N..*ad01.workplacehere.com
*..
.M...M..S5.9.$.?,..\*.ce..;...>.
.
.G'.D]..T0..*.H...0.1.0...U*AD01.workplacehere.com
*0..


so while for some protocols your statements would be true,  this isn't the
case for all protocols which one would be considering in a similar
situation it appears.









On Fri, Mar 28, 2014 at 12:03 PM, Walter Parker  wrote:

> The big problem that I see people have that that want to do networking
> based on hostnames rather than IP addresses. Such as how named virtual
> hosting works on Apache. But the problem is that the hostname is translated
> to an IP address on the client side and the only thing the server sees is
> the IP address that the client used to connect. Apache knows what hostname
> was used because the browser sets a HTTP header that has the hostname. This
> was an after the fact addition to the HTTP standard to allow for lots of
> websites on one IP address. A few years ago TLS was extended to allow for
> the same thing to happen w.r.t. HTTPS web sites. To allow this this on
> other internet protocols will require that both the clients and server both
> be upgraded to pass the hostname as a parameter (worse, not all protocols
> were designed to allow for this to be done in a backwards compatible
> fashion), which is now much more of a issue with a billion users than it
> was in the mid 90's with only a few million users.
>
> I'd love it if there was simple solution, but I don't see one that would
> compatible with today's internet. Much of the original design of the
> internet was for a 1 to 1 mapping of IP addresses, rather than a 1 to many
> mapping (which is why there is usually a lack of a disambiguation field in
> the protocol).
>
>
> Walter
>
>
>
>
> On Fri, Mar 28, 2014 at 7:54 AM, greg whynott wrote:
>
>> thanks for all the suggestions folks!   While very nitchy and sure not to
>> be a wildly popular function,  it would be nice to see,
>> "policy-routing/nating" based on matching an ACL which can make decisions
>> based on data from the higher layers.
>>
>> his set up is one comprised solely of virtual hosts and networks
>> (excluding the router/firewall which run on its own hardware) under an ESX
>> environment.  They have about 12 customers and each has VMs and their own
>> L2 network and hosts.
>>
>> For now it looks as if the jump host will be the best go.   Have one set
>> up where all the clients connect to and based upon who they log in as, will
>> determined what they see/have access to.
>>
>> The VPN idea is a good one but they would rather not add more gears to
>> the machine which may generate support issues.
>>
>>
>> thanks again and have a great weekend,
>> greg
>>
>>
>>
>>
>> On Thu, Mar 27, 2014 at 6:37 PM, Jonathan Bainbridge <
>> jbainbri...@avmi.org> wrote:
>>
>>> Remote Desktop Gateway, built into Windows 2008 and 2012. Put it behind
>>> the pfSense, port forward the rdp port to the RDG. It authenticates the
>>> user and the user can connect to any internal machine.
>>> In the Remote Desktop Connection you can enter the information for the
>>> RDG. Protect using an SSL on the RDG.
>>> Bonus, you can also setup Remote Desktop Web Services so you can have
>>> programs on Terminal Services available... Note, that part DOES require IE.
>>> On Mar 27, 2014 2:37 PM, "greg whynott"  wrote:
>>>
 Hello,

 I'm not very familiar with TMG from Microsoft but a client I am helping
 migrate to pfsense from TMG has asked me if they'll be able to use the RDP
 port forward in the same way as TMG handles it.


 Apparently there is a function within TMG which acts similar to named
 based virtual web hosts,  where it parses the DNS name from the request and
 makes a forwarding decision based on that bit of information.

 For example,  the firewall only has 1 public IP facing the internet.

 if you RDP to: you'll land on the internal server:

 host1.foo.com  10.101.1.2
 host2.foo.com  10.101.3.4
 host3.foo.com  10.101.1.8


 host1,2 and 3 all resolve to the same public IP.  And we are not
 specifying ports.

 That is the behaviour he is hoping to achieve,  where he can RDP to
 various internal machines without referencing ports.


 Sound do-able?If pfsense can not do this,  are you aware of
 anything out there that can aside from TMG?

 -g







 ___

Re: [pfSense] RDP port forward based on destination name.

[Chris Bagnall]

On 28/3/14 4:03 pm, Walter Parker wrote:

I'd love it if there was simple solution, but I don't see one that would
compatible with today's internet. Much of the original design of the
internet was for a 1 to 1 mapping of IP addresses, rather than a 1 to many
mapping (which is why there is usually a lack of a disambiguation field in
the protocol).


IPv6 :-)

Kind regards,

Chris
--
This email is made from 100% recycled electrons
___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] RDP port forward based on destination name.

[Walter Parker]

The big problem that I see people have that that want to do networking
based on hostnames rather than IP addresses. Such as how named virtual
hosting works on Apache. But the problem is that the hostname is translated
to an IP address on the client side and the only thing the server sees is
the IP address that the client used to connect. Apache knows what hostname
was used because the browser sets a HTTP header that has the hostname. This
was an after the fact addition to the HTTP standard to allow for lots of
websites on one IP address. A few years ago TLS was extended to allow for
the same thing to happen w.r.t. HTTPS web sites. To allow this this on
other internet protocols will require that both the clients and server both
be upgraded to pass the hostname as a parameter (worse, not all protocols
were designed to allow for this to be done in a backwards compatible
fashion), which is now much more of a issue with a billion users than it
was in the mid 90's with only a few million users.

I'd love it if there was simple solution, but I don't see one that would
compatible with today's internet. Much of the original design of the
internet was for a 1 to 1 mapping of IP addresses, rather than a 1 to many
mapping (which is why there is usually a lack of a disambiguation field in
the protocol).


Walter




On Fri, Mar 28, 2014 at 7:54 AM, greg whynott wrote:

> thanks for all the suggestions folks!   While very nitchy and sure not to
> be a wildly popular function,  it would be nice to see,
> "policy-routing/nating" based on matching an ACL which can make decisions
> based on data from the higher layers.
>
> his set up is one comprised solely of virtual hosts and networks
> (excluding the router/firewall which run on its own hardware) under an ESX
> environment.  They have about 12 customers and each has VMs and their own
> L2 network and hosts.
>
> For now it looks as if the jump host will be the best go.   Have one set
> up where all the clients connect to and based upon who they log in as, will
> determined what they see/have access to.
>
> The VPN idea is a good one but they would rather not add more gears to the
> machine which may generate support issues.
>
>
> thanks again and have a great weekend,
> greg
>
>
>
>
> On Thu, Mar 27, 2014 at 6:37 PM, Jonathan Bainbridge  > wrote:
>
>> Remote Desktop Gateway, built into Windows 2008 and 2012. Put it behind
>> the pfSense, port forward the rdp port to the RDG. It authenticates the
>> user and the user can connect to any internal machine.
>> In the Remote Desktop Connection you can enter the information for the
>> RDG. Protect using an SSL on the RDG.
>> Bonus, you can also setup Remote Desktop Web Services so you can have
>> programs on Terminal Services available... Note, that part DOES require IE.
>> On Mar 27, 2014 2:37 PM, "greg whynott"  wrote:
>>
>>> Hello,
>>>
>>> I'm not very familiar with TMG from Microsoft but a client I am helping
>>> migrate to pfsense from TMG has asked me if they'll be able to use the RDP
>>> port forward in the same way as TMG handles it.
>>>
>>>
>>> Apparently there is a function within TMG which acts similar to named
>>> based virtual web hosts,  where it parses the DNS name from the request and
>>> makes a forwarding decision based on that bit of information.
>>>
>>> For example,  the firewall only has 1 public IP facing the internet.
>>>
>>> if you RDP to: you'll land on the internal server:
>>>
>>> host1.foo.com  10.101.1.2
>>> host2.foo.com  10.101.3.4
>>> host3.foo.com  10.101.1.8
>>>
>>>
>>> host1,2 and 3 all resolve to the same public IP.  And we are not
>>> specifying ports.
>>>
>>> That is the behaviour he is hoping to achieve,  where he can RDP to
>>> various internal machines without referencing ports.
>>>
>>>
>>> Sound do-able?If pfsense can not do this,  are you aware of anything
>>> out there that can aside from TMG?
>>>
>>> -g
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> List mailing list
>>> List@lists.pfsense.org
>>> https://lists.pfsense.org/mailman/listinfo/list
>>>
>>
>> ___
>> List mailing list
>> List@lists.pfsense.org
>> https://lists.pfsense.org/mailman/listinfo/list
>>
>
>
> ___
> List mailing list
> List@lists.pfsense.org
> https://lists.pfsense.org/mailman/listinfo/list
>



-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis
___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list