Stupid network question.

[theweaselking]

I've got a lovely smart SonicWall firewall.

I have multiple servers behind it.

I have multiple domain names.

I want to forward port 443 to machine A if the URL is "vpn.domain1.com" and to machine B if the url is "servername.domain2.com".

Both of those are the same IP in DNS, because that single IP is how you get to my network.

This HAS to be perfectly possible. Is there an easy way to do it from the firewall? If not, I suspect I can configure a server to use squid or the like to redirect, so I send all traffic to that server, which then forwards it to the correct server - does that seem sensible to you?

(right now, I've got one of them running a nonstandard port. I want to stop doing that.)

Comments

[theweaselking.livejournal.com]

With name-based virtual hosting in a webserver, the connecting client provides the hostname in its connection headers; the webserver reads the header, determines the desired site, and returns the correct page.

Yes, but I can server multiple sites from the webserver easily. I don't want to do that - I want multiple destination servers, based on the name the surfer puts in.

the router would need to 1) tell the difference between VPN and web traffic

No, it wouldn't. Traffic to the first machine name goes to the first machine. Traffic to the second machine name goes to the second machine. Content of the traffic should not be relevant.

But yes.

[theweaselking.livejournal.com]

Well, kind of. It's the "DNS-ignorant" bit that's the problem, but it shouldn't care about the *protocol* as long as it knows the port and the destination machine name.

The problem is that it doesn't know the machine name.

Oh, well, no worries.

[rbarclay.livejournal.com]

No, a router or classic firewall can NOT do this as the information needed (the "Host:" line in the HTTP (1.1) request) is not present in the SYN packet of the connection which a firewall uses to decide where to route a connection. And especially not in the presence of SSL (as port 443 indicates https) - it would need to decrypt the connection to get at the information (cf. man-in-the-middle attack)

This is a classic case for an application-level proxy, not a firewall - for example, it should be doable with apache in a reverse-proxy style setup (with a proper SSL-certificate for *.foo.tld). There's stuff that can do this (the better load-balancers for example, Radware etc.), but that's about a magnitude or two more expensive than a shitty SonicWall.

[elffin.livejournal.com]

Assuming that you have a SonicWall TZ 170 standard (which is what I've got):

No.

The sonicwall has one-to-one NAT, but doesn't have port forwarding capabilities (which is what your scenario would need) because that requires full state packet inspection, which it doesn't perform. Sadly, expensive firewall can't perform a function that a cheap Chinese DSL router can perform. Granted, the firewall runs much faster than the cheap Chinese DSL router, and can handle multiple concurrent ethernet connections and tonnes of external IPs.

Or, to put it another way: The SonicWall's routing tables are DNS-ignorant. The report functions can resolve DNS, however the only thing the core architecture cares about is MAC and IP.

Sorry. I had the same issue. Thankfully my company has a netblock with a few IPs to spare.

[quotation.livejournal.com]

I have an alternate suggestion. It is not what you asked for, but may still fix the problem.

Run one and only one HTTPS/443 webswerver on the internal notwork. Make it apache with name-based virtualhosing. One virtual host for vpn.domain1.com and one for servername.domain2.com.

Give each virtualhost a DirectoryRoot of nothingness. Your magical configuration directive is:
ProxyPass ProxyPass / http://192.168.1.3/

Where "3" is the addy of the machine to which you want access. A different ProxyPass for each virtualhost.

Of course, this is nothing like what you were asking for. It centralizes the SSL on your apache instance, so you won't have separate certificates for each thingy, unless you set them up as SSL virtualhosts with independant certificates, etc. Additionally, it introduces the apache thingy as a single point of failure, etc.

But, I got the impression that it was a user experience you were trying to accomplish. It'll do the trick.

Personally, though, I use https://stupid.domain.com/server1/ and /server2/ as proxypasses instead of based on DNS. And I proxypass to other apaches on localhost so I can have different module version setups for different apps.

[theweaselking.livejournal.com]

Honestly, the single point of failure worries me very little at this point.

And your solution seems to solve my problem (which is to say, the use of ugly ":port"s on the end of URLs for my users).

This is promising and entirely worthy of consideration.

So:

I take my existing SSL site, set the router to forward to 443 on it.

In my happy /sites-available/hostname file, I edit it to be

NameVirtualHost *:443

{VirtualHost *:443}
ServerName thing.domain1.com
ServerAlias whatever
ProxyPass / https://[VPN IP HERE]/
{/VirtualHost}

{VirtualHost *:443}
ServerName servername.domain2.com
DocumentRoot /var/www/whatever
[insert SSL cert for domain2.com]
[insert all the other settings I want, here]
{/VirtualHost}

which should cause all connections to thing.domain1.com to go right through blindly to it, and pass back the same way, and all connections to servername.domain2.com to be served locally?

I don't actually want multiple apaches running, but, if I did, I'd set up the other apaches to listen on other ports and I'd add a
"{VirtualHost *:443}
ServerName otherapache.me.com
ProxyPass / https://localhost:port/ " entry up top, right?

That seems... too easy. I like easy, mind, but this is a web server. Having things make that much sense is just weird.

But does it seem I've got the gist of it?

And if I wanted to do it your way, I'd have just one VirtualHost and just one SSL cert that gets called up, and then I'd have multiple ProxyPass statements:

ProxyPass /vpn/ https://[VPN IP HERE]/
ProxyPass /site1/ http://[other webserver]/
ProxyPass /ninjas/ http://localhost:1492/ohgod_ninjas/

[quotation.livejournal.com]

Ah, yes. "It feels too easy."

I forgot to warn you about that feeling.

Hang in there, you'll start to see the other caveats.

Weird things in the logs. Two logs to read instead of one. Internal apaches making up broken permalinks, etc.

[theweaselking.livejournal.com]

I'm actually planning to use this for only two sites, and I'm quite confident in the ability of the one who's picking up the ProxyPass link to log itself nicely.

After all, it genuinely only cares about people who log in, and ALREADY logs itself to the apache server's syslog server all on it's own.

And the main server isn't going to change. It's just going to lose connections to domain1.com

(But, really, I have the concept down? And my syntax appears basically correct, including the ability to not include an SSL cert in my VirtualHost but to simply ProxyPass an HTTPS link?)

I plan to try all this out tomorrow morning, at work. I'd just rather have any REALLY obvious problems not waste my time, then.

And, by the way, Rob, I owe you a beer. Or a scotch. Or a coffee. Or whatever, the point is thanks a lot for the help you've offered on this and other problems.

[quotation.livejournal.com]

Really. You got it. It's really that easy.

I use it all the time, and couldn't imagine my life without it.

I like to put all images, static content and SOAP services on apaches with a tiny memory footprint, and ProxyPass the web UI in to another apache that has perl and php and bloat. Superfly.

[quotation.livejournal.com]

Oh, wait. I should mention about the HTTPS passing.

You said:
ProxyPass /vpn/ https://[VPN IP HERE]/

That should work, based on my experience, but it's silly. The ProxyPasser will then be decrypting the traffic and re-encrypting. The user will see the cert installed on the ProxyPasser, not the cert from the internal host.

I believe this is what's referred to as a man-in-the-middle attack.

Works like a charm. Stupid as hell.

[theweaselking.livejournal.com]

Right, then.

I was hoping it would simply pass the traffic through without giving a shit, at all, about the actual content, or parsing any of it. That's not so good.

So, since...

1) the internal host *simply doesn't do* anything but HTTPS (being, itself, a hardware SSL-VPN device),
2) while I would love to have it simply serve HTTP I am also fine with the overhead involved in encrypting/decrypting the traffic if that's the only *real* cost of doing it this way[1]
3) I can't make *it* the primary server and have the web server just server HTTP, as much as I might want to

... do you have any suggestions beyond "create a cert for the VPN name on the Apache server and the users simply won't see what's going on"?

If there's a better way to do this, I'm all ears. I just don't know what that might be. And if this doesn't actually compromise security as long as the referrer is good, it might be worth doing.

[1]: As in, I might be perfectly willing to MITM my own SSL-VPN if it doesn't show to the outside world, since the most important things on the network are on the original Apache server. And, as far as I can tell, to take advantage of the flaw in this setup, one would have to compromise the Apache server, at which point the VPN is totally not my biggest worry, at all.

[sterroneous.livejournal.com]

I'm probably stating the obvious, but you can't virtual-host across a set of SSL certificates, only present a set of virtual hosts behind a single common SSL cert. The SSL handshaking and authentication is performed before any traffic is shared, so only one certificate can be presented per port.

Ie, you'll need your vpn.domain1.com certificate to be the same as the https.domain2 certificate.com, and either the browser or VPN client may then get an authentication issue (since the DNS name they're using won't match the name presented in the cert). Wildcard names, or certificates listing multiple domain names may help you, somewhat.

Here's an old but still slightly handy O'Reilly (http://www.onlamp.com/pub/a/apache/2005/02/17/apacheckbk.html) link, and some information (http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-virtual-hosts-with-mod_gnutls/) on a TLS extension that doesn't sound production-grade, yet.

[quotation.livejournal.com]

About an easier way to do it -- depends on why you're coddling your users so much.

You could run the VPN through the firewall on port 4433, with the apache server on 443 and 80. When someone accesses /vpn/ on the apache server, they just get back a redirect to port 4433.

Of course, the user's source network might be proxied and only permit access to ports 80 and 443.

[theweaselking.livejournal.com]

on why you're coddling your users so much.

Because making things Just Work is always a good thing, and this *seems* so simple, on paper - make the firewall put HTTPS to servername 1 to IP 1, servername 2 to IP 2.

And, really, it seems it's not as simple as I was hoping, but that doesn't make it not worth doing if the results are good.

[quotation.livejournal.com]

It would work great with HTTP, you only get in trouble with HTTPS because, by design, HTTPS is supposed to verify the server's identity. This is a Feature.

Why not do the redirect to the secondary port?

[theweaselking.livejournal.com]

Because the hardware device on the other end only appears to listen on 443.

As in, I don't think it's *possible* to have it listen to anything else. It demands an IP, but doesn't have any options to run it on a different port.

(I've contacted support about that)

[quotation.livejournal.com]

Ya know, if you forward 4433 on the firewall to 443 on the VPN "hardware device," that should work fine.

[theweaselking.livejournal.com]

Maybe I'm just dumb, but I've never been quite able to make that work on any router where it's been an option. I've always had to pass port X to port X if I wanted it to work.

(and SonicWall devices don't let you change ports. Instead, you can only make firewall rules based on letting the ports of a "service" go from WAN to LAN to DMZ and whatever, and creating a "service" means setting a static port range.

Meaning, you can't put port X to port Y on this firewall. And no, I don't know why they did that.)

[quotation.livejournal.com]

I hope you've got a very good reason for using sonicwall, then.

I had a router once that couldn't pass from one port to another, but it cost me $30. While I was saving up $35 for a better one, here's what I did:

Forward port 4343 to Linux box. Port-forward 4343 on the Linux machine to 443 on the hardware appliance.

Worked like a charm for other protocols on other ports, don't see why it wouldn't work in your case.

[theweaselking.livejournal.com]

Hey, Rob, Stupid Question Time related to this:

I've got:

ServerName server.domain.com
ServerAlias other.domain.com
ServerAdmin it@domain.com

SSLEngine On
SSLCertificateFile /etc/apache2/ssl/apache.pem

ProxyPass /zimbra/ http://192.168.1.15/
DocumentRoot /var/www/html/

The server name works for all local stuff, I've got mod_proxy enabled, and I'm trying to make everything on https://server.domain.com/zimbra/ be loaded from http://192.168.1.15/

And I can't seem to make that work. I'm currently getting 403 Forbidden, with the error in the logs being
[Wed Jan 16 17:18:12 2008] [error] [client 192.168.1.1] client denied by server configuration: proxy:http://192.168.1.15/

All the proxy modules are enabled, but I'm obviously missing something critical, and it's probably something stupid.

Ideas?

[quotation.livejournal.com]

What's the exact line from the access log to go along with that error log?

If it's "GET https://server.domain.com/zimbra HTTP/1.1" instead of "GET https://server.domain.com/zimbra/ HTTP/1.1" then that's your problem. The probypass requires you to add the / after zimbra.

Also, you're not telling me if that log is from the "ServerName server.domain.com" apache, or from the "ServerName 192.168.1.15" apache.

[theweaselking.livejournal.com]

I did add the slash. And this log is on the server.domain.com server - the https server.

And the 403 error message comes from it, not from 192.168.1.15.

Access log: [16/Jan/2008:21:10:17 -0500] "GET /zimbra/ HTTP/1.1" 403 372 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

Error log: [Wed Jan 16 21:10:17 2008] [error] [client 99.240.165.140] client denied by server configuration: proxy:http://192.168.1.15/

192.168.1.15's apache logs nothing at all when I make this attempt.

[quotation.livejournal.com]

I would comment out the proxypass and "mkdir -p /var/www/html/zimbra ; touch /var/www/html/zimbra/index.html" to prove that you can load an empty index.html at that URL.

It might not be the proxypass itself that you're having trouble with.

[theweaselking.livejournal.com]

No, that works just fine.

[theweaselking.livejournal.com]

A-ha! Got it!

I didn't have a
[proxy *]
allow from all
[/proxy]
block

Now it's fixed, and I feel dumb.

Thanks!

[quotation.livejournal.com]

I was gonna ask why the error log said "proxy" as the policy in question. . . .

[theweaselking.livejournal.com]

Yeah. I'm kinda special sometimes.

And this is one of them.

[quotation.livejournal.com]

Well, you're special enough to put together a webserver setup that would make the average webmaster weep tears of blood.

[theweaselking.livejournal.com]

That's not necessarily a compliment.

But I'm going to pretend it is in this case.

[anivair.livejournal.com]

I'm actually doing almost the same thing at work. if you don't have an answer by morning ping me and I'll let you know when I can look at our firewall.

[jsbowden.livejournal.com]

You know, I've read all the stuff above, and I have to ask, doesn't your firewall let you write custom rules? You should be able to parse the header, and forward the traffic to the appropriate internal host (where host may just be an aliased interface, which you have to do if you're running multiple SSL sites on the same web server) based on the IP header content (I don't know what Sonicwall you've got...some SOSHO cable/DSL gateway thing, an enterprise level firewall, or something in between, but anything better than the SOHO cable/dsl gateway should let you do this, but we use Juniper nee Netscreen appliances here, so don't ask for specifics).

[theweaselking.livejournal.com]

It's a TZ170 Standard.

So it doesn't do packet inspection, meaning it can't parse the headers, or so I hear from the other people who user them.