I'm trying to use HA Proxy as Reverse Proxy for LoadBalancing and Health-Check Purpose mainly.
Therefore, I have to address different domains with several subdomains and/or subpaths.
https://sub1.example1.com
https://subsub.sub1.example1.com
https://sub2.example2.com
https://example3.com/path1
Unfortunately, I'm not finding an opportunity to define a frontend for each Domain to bind the SSL-cert-file to.
Additionally, I'm not pretty sure whether HAProxy provides something like ProxyPass to handle the "path"-Stuff.
Can somebody please give me an example how to solve this with HAProxy?
Thanks
You can have a single frontend that handles all of the subdomains and use ACL's to route to different backends. You define your certificates on the bind line and multiple can be specified. I'm not quite sure what you mean by the "ProxyPass to handle the "path"-Stuff" but if you provide more detail I can help. HAProxy is extremely flexible.
provides something like ProxyPass to handle the "path"-Stuff.
Example of how you might handle the multiple subdomains:
defaults
mode http
frontend fe_main
bind :80
# define all certificates
bind :443 ssl crt /etc/haproxy/ssl/sub1.example.com.pem crt /etc/haproxy/ssl/sub2.example.com.pem crt /etc/haproxy/ssl/example3.com.pem
use_backend be_sub1 if { req.hdr(host) sub1.example.com }
use_backend be_sub2 if { req.hdr(host) sub2.example.com }
default_backend be_catchall
backend be_sub1
server app1 192.168.1.10:80 check
backend be_sub2
server app1 10.2.0.4:443 check ssl verify none
backend be_catchall
server catchall1 10.3.2.5:80 check
Related
Is it possible to configure a vhost on httpd that accepts any domain received and proxies to the actual website? Like subdomain wildcard but for the domain.
I'm assuming that tools like Squid Proxy can do this just fine, I'm just curious if it can be done with apache.
Sure that is possible, but you don't even need a proxy for that. The apache http server offers the concept of a "default virtual host". Which is exactly what you want: that host is responsible to respond to incoming requests to http hosts that do not have a specific configuration.
The default typically simply is the first of all hosts defined inside an apache http server.
An alternative I personally use is to setup the virtual hosts by just a basic configuration (name, admin and the like), but to include the actual content configuration (DocumentRoot and rewriting stuff) from a separate file). That way you can easily share the same setup between many virtual hosts but still have individual configuration options per domain, subdomain, http host, however you want to call that (there is no difference for the http server anyway, it is all http hosts).
I have a java application which is trying to call a HTTPS endpoint which is setup in my internal network. Also this request go through a corporate proxy.
Having said that, I don't want to implement a HTTPS client at my application level. Instead I will just trigger a plain http request, then further my proxy will take the http request and delegate it to the HTTPS endpoint. So that the proxy will take care of handling the SSL certificates & keys.
Is this something possible with Apache Httpd or Squid ?
Basically I dont want my application to worry about the SSL cerificates etc. Instead this can be managed at the proxy level ?
this should be easy with apache. in your virtual host add
ProxyPass /myapp https://somehost.com/myapp
ProxyPassReverse /myapp https://somehost.com/myapp
then you can use yourinternalhost.company.com/myapp/
then watch your error log about SSLProxyCheck* messages (depends on the ssl certificate)
see http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslproxycheckpeercn
mod_proxy:
httpd.apache.org/docs/2.4/mod/mod_proxy.html (see proxyremote for using another (corporate) proxy
example1.com and example2.com resolve to host0. host0 runs an Apache reverse proxy with two VirtualHosts. It delegates requests for example1.com to host1 and for example2.com to host2.
Using http in all places, that clearly can be made to work.
Using https, I could stick the keys for example1.com and example2.com on host0, and then have host0 talk http or https to host1 and host2. Given SNI, that should work, too.
My question: can it be made to work without the example1.com or example2.com keys on host0? I'd like to avoid that host0 is in a position to perform a man-in-the-middle attack.
If I understand SNI correctly, the key material is only exchanged after the client has communicated the desired virtual host to host0. This should be (?) sufficient information for Apache to essentially forward the connection to host1 or host2, without looking at the content of the transmission at all. That does not require key material at all.
Do you really need Apache reverse proxy, or you need the problem solved? I had the same problem and I resolved it with HAProxy in tcp mode as described here http://blog.haproxy.com/2012/04/13/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/ instead of Apache reverse proxy.
If you don't mind using Nginx or HAProxy instead of Apache, you'll find good answers at the following question at ServerFault:
Can a Reverse Proxy use SNI with SSL pass through?
For reasons we're not going to change, our application needs to handle the SSL connection, and not the ELB. The goal of using the Proxy Protocol is to get the client's IP address over an SSL connection.
http://aws.typepad.com/aws/2013/07/elastic-load-balancing-adds-support-for-proxy-protocol.html?ref_=9 indicates "Alternatively, you can use it if you are sending HTTPS requests and do not want to terminate the SSL connection on the load balancer. For more information, please visit the Elastic Load Balancing Guide."
Unfortunately, it appears the guide that's linked to doesn't actually elaborate on this, and the basic documentation for the Proxy Protocol ( http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-proxy-protocol.html ) fails in our environment when configured as described.
Does anyone have steps or a link for this?
The proxy protocol (version 1) injects a single line into the data stream at the beginning of the connection, before SSL is negotiated by your server. You don't get this information "over" an SSL connection; you get the information prior to SSL handshaking. Your server has to implement this capability and specifically be configured so that it can accept and understand it. For an IPv4 connection, it looks like this:
PROXY TCP4 source-ip dest-ip source-port dest-port\r\n
The standard for the protocol is here:
http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt
Additional info in the ELB docs here:
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html#proxy-protocol
Regarding Apache support, at least at the time AWS announced support for the proxy protocol...
“neither Apache nor Nginx currently support the Proxy Protocol header inserted by the ELB”
— http://aws.typepad.com/aws/2013/07/elastic-load-balancing-adds-support-for-proxy-protocol.html?ref_=9
That is subject to change, of course, but I didn't successfully google for any Apache support of the proxy protocol. Of course, since Apache is open source, you could presumably hack it in there, though I am unfamiliar with the Apache source code.
Realizing that you don't want to change what you're doing now, I still would suggest that depending on your motivation for not wanting to change, there may still be a relatively simple solution. It's a change, but not involving SSL on ELB. What about running HAProxy behind ELB to terminate the SSL in front of Apache? Since HAProxy 1.5 can terminate SSL and appears to be able to translate the proxy protocol string from ELB into an X-Forwarded-For header, as well as generate X-SSL headers to give your application information about the client's SSL cert (perhaps that's your motivation for terminating SSL at the app server instead of on the ELB?) ... so this might be an alternative.
Otherwise, I don't have suggestions unless Apache implements support in the future, or we can find some documentation to indicate that they already have.
For the newer Network Load Balancers which allow your application servers to terminate the TLS connections, you can still get the real IP addresses of your clients and avoid all the work of configuring proxy protocol on the ELBs and in the web server config by simply configuring the target groups to use the servers' instance ids rather than their IP addresses. Regardless of which web server you use, the real IPs of the clients will show up in the logs with no translation needed.
Just to follow up on Michael - sqlbot's answer discussing the AWS support for proxy protocol on EC2 instances behind classic TCP elastic load balancers, the Apache module to use that implements the proxy protocol is mod_remoteip. Enabling it and updating the configuration properly will correct the problem of logging IP addresses of users rather than the elastic load balancer's IPs.
To enable proxy protocol on the elastic load balancer you could use these aws cli commands described in the aws documentation:
aws elb create-load-balancer-policy --load-balancer-name my-elb-name --policy-name my-elb-name-ProxyProtocol-policy --policy-type-name ProxyProtocolPolicyType --policy-attributes AttributeName=ProxyProtocol,AttributeValue=true
aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-elb-name --instance-port 443 --policy-names my-elb-name-ProxyProtocol-policy
aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-elb-name --instance-port 80 --policy-names my-elb-name-ProxyProtocol-policy
To enable use of proxy protocol in apache, in a server-wide or VirtualHost context, follow the mod_remoteip documentation such as below:
<IfModule mod_remoteip.c>
RemoteIPProxyProtocol On
RemoteIPHeader X-Forwarded-For
# The IPs or IP range of your ELB:
RemoteIPInternalProxy 192.168.1.0/24
# The IPs of hosts that may need to connect directly to the web server, bypassing the ELB (if applicable):
RemoteIPProxyProtocolExceptions 127.0.0.1
</IfModule>
You'll need to update the LogFormat wherever you have those defined (e.g. httpd.conf) to use %a rather than %h else the load balancer IP addresses will still appear.
I have an application that acts as both a HTTP server as well as a HTTP client. For security reasons, the application runs on a server on a protected/internal network. I would like to setup a HTTP proxy that acts as an external interface for external parties to access the application.
For external HTTP clients to access my application, I would like to have a reverse proxy to handle such scenarios.
For HTTP request from my application to external parties, I would like to have a forward proxy to ensure my proper external URL's are sent to the external parties.
Question: Can Apache HTTPD proxy be configured to run a both a forward proxy and reverse proxy at the same time?
The short answer (from my reading of the docs) is No.
The forward proxy is activated using the ProxyRequests directive
A reverse proxy is activated using the ProxyPass directive.
The reverse proxy docs state
The ProxyRequests directive should
usually be set off when using
ProxyPass.
I think if you enable both on the same server, there will be a possible clash in your Allow, Deny settings for IPs etc