Re: [pfSense] RDP port forward based on destination name.
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 greg.whyn...@gmail.comwrote: 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 greg.whyn...@gmail.com 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
Re: [pfSense] RDP port forward based on destination name.
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.
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 http://ad01.workplacehere.com*.. .M...M..S5.9.$.?,..\*.ce..; . .G'.D]..T0..*.H...0.1.0...U*AD01.workplacehere.com http://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 walt...@gmail.com 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 greg.whyn...@gmail.comwrote: 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 greg.whyn...@gmail.com 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
Re: [pfSense] RDP port forward based on destination name.
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.orgwrote: 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 greg.whyn...@gmail.com 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.
On Fri, Mar 28, 2014 at 9:54 AM, greg whynott greg.whyn...@gmail.com 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
