OpenWrt Forum Archive

Topic: https server behind openwrt box

The content of this topic has been archived on 5 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi,

I'm trying to make an owncloud server accessible from the internet with self signed certificates (obviously it needs to be encrypted). I have a separate linux box, which would serve as the owncloud server. I've got the owncloud server working with internal 192.168 beginning address, in LAN. I have spend hours googling, but I can't find the answer how to forward the traffic coming to WAN port 443 to the owncloud server port, so that it works with https... I've tried to adding a alias IP to owncloud servers eth0, the same as my WAN IP... might be that its either openwrt configuration issue, or apache/certificate configuration issue...

I'm really/clearly not an expert in networking or https... Am I trying to do impossible things? Would really appreciate advice. I have Attitude Adjustment installed on my router/AP box.

Thanks!

Did you try to go to "Network > Firewall" page, and add a new rule in the "Port Forwards" section?

Yes, but the problem (as far as I understand it) is that https is designed to prevent that. Essentially preventing "man in the middle" attack. Https server responds/redirects with LAN address as a address to contact to. Ofcourse that fails.

Looks like the problem is in your HTTP server: it should respond with external name as server name, not internal ip address; this is not a "man-in-the-middle attack", as your router is just redirecting packets.

Not answering your question, but I ended up setting up OpenVPN on my OpenWRT-router. I then run ownCloud over http/80 (instead of https/443), but over VPN, so it is secure anyway.

One advantage is that ownCloud is slow, and not running over https makes it a bit faster.

flexy wrote:

Yes, but the problem (as far as I understand it) is that https is designed to prevent that. Essentially preventing "man in the middle" attack. Https server responds/redirects with LAN address as a address to contact to. Ofcourse that fails.

Pretty sure that's absolutely wrong otherwise https wouldn't work anywhere on the internet since everything is being "man-in-the-middled" by a lot of routers on the internet before reaching your destination. Your device will be entirely unaware of the OpenWrt router since it is directly forwarding the traffic to your machine.

Show us your port forwarding configuration. Also are you testing the forwarding from within your private network? Your port forward will only work from other public IP addresses on the internet.

arfett wrote:
flexy wrote:

Yes, but the problem (as far as I understand it) is that https is designed to prevent that. Essentially preventing "man in the middle" attack. Https server responds/redirects with LAN address as a address to contact to. Ofcourse that fails.

Pretty sure that's absolutely wrong otherwise https wouldn't work anywhere on the internet since everything is being "man-in-the-middled" by a lot of routers on the internet before reaching your destination. Your device will be entirely unaware of the OpenWrt router since it is directly forwarding the traffic to your machine.

Show us your port forwarding configuration. Also are you testing the forwarding from within your private network? Your port forward will only work from other public IP addresses on the internet.

My port forwardings are made with LuCI web pages provided by Openwrt. Nothing fancy there.

Yeah, I don't mean routers as being man in the middle... I know I'm a noob in this, but what I've tried to get my head around is... My linux box is in the LAN, with 192.169.10.2 as its address. Then, my Openwrt box has the public IP. I have to access my https (its secure http, not plain http) using that public IP. OK, I redirect this traffic to public IP port 443 to 192.168.10.2, same port. Apache responds to connection and wants the connection to continue using its internal IP, which of course is the IP that apache sees that eth0 has... and is configured to listen this IP. Now, that fails, because 192.168.10.2 address is private.

How do I go around this? Is just plain old port forwarding from Openwrt AND some nice configuration to apache enough? (I've done the basic port forwarding for SSH connection to the same linux box and it just works.) Or, some iptables rules to Openwrt box AND configure linux boxes eth0 to have alias IP, which is the same as my public IP. Or some other method...? I have no idea.

zo0ok wrote:

Not answering your question, but I ended up setting up OpenVPN on my OpenWRT-router. I then run ownCloud over http/80 (instead of https/443), but over VPN, so it is secure anyway.

One advantage is that ownCloud is slow, and not running over https makes it a bit faster.


Yeah, I've thought of that too, but that is like giving medicine to the symptom, not for the illness... I'd rather do it "correctly" than add more clutter to stuff...

Your understanding of all of this is entirely incorrect.

The port forwarding for all intents and purposes gives your Linux box the public IP address, for that port at least, and Apache is NOT responding with a private IP back to the host on the internet. I am currently connected to two different pages hosted on my home machine using Apache and port forwarding on my OpenWrt router so I can assure you I know what I'm talking about. HTTPS and HTTP behave exactly the same.

Can you please answer the questions I asked?
1. Can you please post your port forwarding configuration? It doesn't matter if your configuration is done from CLI or LuCI or if it's "fancy" or not... we can tell you right away if it was configured properly or not if you just show us.
2. Are you testing the port forwarding from a different public IP on the internet or from within your LAN? It will NOT work from within your LAN.
3. Are you on a "consumer-grade" internet connection? If so then port 80 and 443 are typically blocked and you will probably have to use a different port.

If you don't answer these questions them I'm afraid there's not a single person on this forum that will be able to help you.

(Last edited by arfett on 3 Mar 2015, 18:14)

flexy wrote:

Yeah, I don't mean routers as being man in the middle... I know I'm a noob in this, but what I've tried to get my head around is... My linux box is in the LAN, with 192.169.10.2 as its address. Then, my Openwrt box has the public IP. I have to access my https (its secure http, not plain http) using that public IP. OK, I redirect this traffic to public IP port 443 to 192.168.10.2, same port. Apache responds to connection and wants the connection to continue using its internal IP, which of course is the IP that apache sees that eth0 has... and is configured to listen this IP. Now, that fails, because 192.168.10.2 address is private.

You do not have a TCP/IP problem, you have a HTTP problem.

Your web server has a private IP address, so it will only listen to a private IP address, and all packets coming out of that box will have a private IP address as a source. But all of this is just "business as usual": the port forwarding functions in your router are responsible for translating the public IP address from its WAN interface to the private IP address of your web server, and will also take care to do the inverse change on the outgoing packages. That is what NAT means: "Network Address Translation".

Now, the problem is that your web server is telling all clients to contact him at the private IP address, and they obviously fail. Please notice that this happens one layer above the TCP/IP layer. If you are using Apache, please see the ServerName and ServerAlias directives, and how they work.

arfett wrote:

Your understanding of all of this is entirely incorrect.

The port forwarding for all intents and purposes gives your Linux box the public IP address, for that port at least, and Apache is NOT responding with a private IP back to the host on the internet. I am currently connected to two different pages hosted on my home machine using Apache and port forwarding on my OpenWrt router so I can assure you I know what I'm talking about. HTTPS and HTTP behave exactly the same.

Can you please answer the questions I asked?
1. Can you please post your port forwarding configuration? It doesn't matter if your configuration is done from CLI or LuCI or if it's "fancy" or not... we can tell you right away if it was configured properly or not if you just show us.
2. Are you testing the port forwarding from a different public IP on the internet or from within your LAN? It will NOT work from within your LAN.
3. Are you on a "consumer-grade" internet connection? If so then port 80 and 443 are typically blocked and you will probably have to use a different port.

If you don't answer these questions them I'm afraid there's not a single person on this forum that will be able to help you.

OK, great. So you have done it, you can help. Here comes the answers...

1. In Luci, Network -> Firewall -> Port Forwardings:

copy paste from luci interface:
htpc ssl
   
IPv4-TCP
From any host in wan
Via any router IP at port 443
   
IP 192.168.10.2, port 443 in lan

and this configuration is made the same way for SSH. Only difference in creating it, was that I did not include UDP. SSH just works.

2. I'm testing from WAN, as in, with my smart phone using the 3G connection. Definately different IP. Not via WLAN.

3. I have no such restrictions on my network connection. I have used network scanners found via google, that scan my ports. Even one, which tests the https server. That port is open.

So, this must be just my failure to configure the apache correctly. And / or create self signed certificate correctly. Can you provide me with copy of your apache config? Method of creating certificate, with all inputs?

Thanks smile

eduperez wrote:
flexy wrote:

Yeah, I don't mean routers as being man in the middle... I know I'm a noob in this, but what I've tried to get my head around is... My linux box is in the LAN, with 192.169.10.2 as its address. Then, my Openwrt box has the public IP. I have to access my https (its secure http, not plain http) using that public IP. OK, I redirect this traffic to public IP port 443 to 192.168.10.2, same port. Apache responds to connection and wants the connection to continue using its internal IP, which of course is the IP that apache sees that eth0 has... and is configured to listen this IP. Now, that fails, because 192.168.10.2 address is private.

You do not have a TCP/IP problem, you have a HTTP problem.

Your web server has a private IP address, so it will only listen to a private IP address, and all packets coming out of that box will have a private IP address as a source. But all of this is just "business as usual": the port forwarding functions in your router are responsible for translating the public IP address from its WAN interface to the private IP address of your web server, and will also take care to do the inverse change on the outgoing packages. That is what NAT means: "Network Address Translation".

Now, the problem is that your web server is telling all clients to contact him at the private IP address, and they obviously fail. Please notice that this happens one layer above the TCP/IP layer. If you are using Apache, please see the ServerName and ServerAlias directives, and how they work.

I've tried reading about them, but I seem to fail to understand them correctly. Or then something else is configured improperly... I got it working in my LAN, but trying to convert it to work from outside... I just fail. Yes, apache is the webserver of my choice.

flexy wrote:

I've tried reading about them, but I seem to fail to understand them correctly. Or then something else is configured improperly... I got it working in my LAN, but trying to convert it to work from outside... I just fail. Yes, apache is the webserver of my choice.

As a first step, ServerName should be the FQDN (fully qualified domain name) or IP address that clients should use to reach your server; for example, "www.myserver.com" or "192.168.1.24". Please, notice that it must be valid both for computers in your network, and computers outside your network; so it is a bit more complex that what it may seem.

I guess (I have never done it) you can configure two virtual hosts inside the same server, one for the intranet and one from the internet; each virtual host would be configured with a different ServerName. Or you could use the external IP address (or a FQDN that resolves to that address), but you will have to configure the router to redirect all internal traffic to your public IP address (never did this, either). Or you could use the external name, and configure the DNS in your router to resolve that name to the internal IP addres; this is what I did.

Yes, the fault was inside /etc/owncloud/config.php, it had a line  'overwrite.cli.url' => 'https://192.168.10.2'...  This was leading to the replacement of the URL, what was confusing me totally... Did not try to serve any other content, than just the owncloud. So, yes, normal port forward works as it should. And so does NATted https server.

Thanks for help!

The discussion might have continued from here.