Date: Wed, 23 Jan 2008 09:48:36 -0800 From: "Chris H." <chris#@1command.com> To: Doug Poland <doug@polands.org> Cc: freebsd-pf@freebsd.org Subject: Re: pf how-to: Single public IP --> many private NAT'd HTTPS servers Message-ID: <20080123094836.pah12u0agwkg8w80@webmail.1command.com> In-Reply-To: <4794F117.2000804@polands.org> References: <4794C5A8.8040402@polands.org> <1200904649.33634.9.camel@z60m> <4794CF21.2090606@polands.org> <1200906215.33634.14.camel@z60m> <4794D38C.6020007@polands.org> <20080121175551.GB11928@verio.net> <4794F117.2000804@polands.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Doug Poland <doug@polands.org>: > David DeSimone wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Doug Poland <doug@polands.org> wrote: >>> I have DNS resolution, the problem ( I think ) is in that pf simply >>> sees the packet destined for my single public IP (because all my >>> public host names must resolve to the same public IP address) and port >>> 443. >> >> I am not sure how you expect this to work. The web browser will expect >> the server to send a certificate with its identity as part of the >> initial SSL negotiation. The client has not yet sent its request, so >> the web server has no idea which of the three domains the browser wanted >> to talk to, so it does not know which certificate should be sent. This >> is the reason why every SSL site must have its own unique (public) IP >> address. >> >> - -- David DeSimone == Network Admin == fox@verio.net >> > I see what you are getting it. I told pf to simply route all https > requests to a fixed private IP. When I pointed my browser at the > FQDN, firefox told me I had a certificate problem... i.e., the > certificate returned was not the one expected. > > So, is the bottom line, one *cannot* hide multiple (NAT'd) SSL hosts > behind a single public IP? So my only solution, given apache and one > public IP, is a single host listening on 443 and each "domain" would > have to be served as a <Directory></Directory>. e.g., > > https://secure.example.com/webmail/ > https://secure.example.com/subversion/ > > instead of > > https://webmail.example.com > https://subversion.example.com > This is actually more a DNS solution than anything else. For example there is nothing to stop you from using the following in example.com's zone file: $ORIGIN example.com @ IN SOA ns.example.com. rootexample.com. ( ... ) IN A pu.bl.ic.IP IN NS ns.example.com. IN NS another-ns.some-domain.tld. webmail IN A pu.bl.ic.IP subversion IN A pu.bl.ic.IP another-host IN A pu.bl.ic.IP where pu.bl.ic.IP = your internet routeable IP. then simply setup another zone to route your private IP block. This requires a "multi-view" named configuration. But will give you all the routing you require to get this done. Given the above, you'll be able to self-sign all of your hosts certs - or better still, have them signed "officially". But if you self-sign, you can have example.com sign all the hosts certs that are within example.com. Anyway, point being; you can resolve alot of what you are trying to accomplish with a little DNS trickery. Best wishes. --Chris > > -- > Regards, > Doug > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > -- panic: kernel trap (ignored)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080123094836.pah12u0agwkg8w80>