I have OpenVPN successfully configured on a remote
CentOS 7 server to allow https access to employees and administrators, while also blocking ssh access to everyone who is NOT an administrator. This has been working fine with appONE being served to employees who type
https: / 10.8.0.1. But what rules do I have to add to firewalld so that a third group
suppliers has https access that gets routed to a different app, called appTWO, when they log in to the vpn and type
https: / 10.8.0.1?
As per @garethTheRed's suggestion, I imagine the answer involves having appONE running on port 80 and then having appTWO running on port 81. This would simply require firewalld rules to direct the employees ip range to port 80 while routing the suppliers ip range to port 81, but how do I define the firewalld rules to make this happen?
Here is what I have done so far:
I summarized the required user classes, ip ranges, and services as follows:
Class Virtual IP range Allowed Services employees 10.8.0.0/24 https (but only appONE) administrator 10.8.1.0/24 ssh, https suppliers 10.8.2.0/24 https (but only appTWO)
Next, I added the following in
define the Employee IP address pool: server 10.8.0.0 255.255.255.0 Add a route for the System Administrator IP range: route 10.8.1.0 255.255.255.0 Add a route for the Supplier IP range: route 10.8.2.0 255.255.255.0 Specify client configuration directory to assign a fixed IP forAdministrator: client-config-dir ccd
I then created a new config file
/etc/openvpn/ccd/suppliers in the following steps:
nano suppliers type the following into /etc/openvpn/ccd/suppliers: ifconfig-push 10.8.2.1 10.8.2.2
Given that the OpenVPN configuration was initially created using the instructions in this tutorial, I next created a cert in
/etc/openvpn/easy-rsa by typing
source ./vars, followed by
./build-key suppliers. (These were two of the commands from the referenced tutorial.) I copied the resulting
suppliers.key to the client computer, and created the following
client dev tun proto udp remote my.SERVER.ip.addr 1194 resolv-retry infinite nobind persist-key persist-tun verb 3 ca /path/to/ca.crt cert /path/to/suppliers.crt key /path/to/suppliers.key
I then tried to log in to the VPN from the client by typing the following into the terminal in the client machine:
openvpn --config /path/to/suppliers.ovpn. The result in the terminal seemed to indicate that the vpn connection was made because the last two lines printed in the terminal were:
Tue Mar 10 15:39:50 2015 /usr/sbin/ip route add 10.8.0.1/32 via 10.8.2.2 Tue Mar 10 15:39:50 2015 Initialization Sequence Completed
Notice that I seemed to have successfully connected as the correct ip
10.8.2.2, but yet there was no reply when I tried to
https : / 10.8.0.1.
To confirm that OpenVPN was working, I typed the following in the client terminal
openvpn --config /path/to/administrators.ovpn and was able to successfully
ssh to the server as expected.
When I type
firewall-cmd --list-all-zones at the server, the active zones in the results are the following:
internal (active) interfaces: tun0 sources: services: dhcpv6-client https ipp-client mdns samba-client ssh ports: masquerade: no forward-ports: icmp-blocks: rich rules: rule family="ipv4" source NOT address="10.8.1.1" service name="ssh" reject public (default, active) interfaces: enp3s0 sources: services: dhcpv6-client openvpn ports: masquerade: yes forward-ports: icmp-blocks: rich rules:
So why can't the supplier account https? And how can I define the firewalld rules so that supplier https requests get routed to one port abc, while employee and administrator https requests get routed to another port xyz?
As per @garethTheRed's suggestion, I typed
ip route on the CLIENT and got the following results:
default via 10.0.0.1 dev wlp1s0 proto static metric 1024 10.0.0.0/24 dev wlp1s0 proto kernel scope link src 10.0.0.2 10.8.0.1 via 10.8.2.2 dev tun0 10.8.2.2 dev tun0 proto kernel scope link src 10.8.2.1
ip route on the SERVER resulted in:
default via my.server.ip.1 dev enp3s0 proto static metric 1024 10.8.0.0/24 via 10.8.0.2 dev tun0 10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1 10.8.1.0/24 via 10.8.0.2 dev tun0 my.server.ip.0/24 dev enp3s0 proto kernel scope link src my.server.ip.addr
Note the difference between
my.server.ip.addr. The entire 4 block server ip address is represented by
my.server.ip.addr. By contrast, only the first three blocks are represented by
The contents of
nano /etc/openvpn/ccd/administrators are just the one line
ifconfig-push 10.8.1.1 10.8.1.2.
The only two ccd files are
/etc/openvpn/ccd/suppliers shown above.
After following @garethTheRed's directions, the employees ip address range is able to log into appONE by typing
https : / 10.8.0.1, but the administrators no longer have https access, and the supplies do not have https access either. When connected as a supplier, my https requests were rejected when I typed in
https : / 10.8.0.1:444 and when I typed
https : / 10.8.0.1.
NOTE: To diagnose this problem, I have had to experiment with some things that may seem off topic. I would be happy to post the content of this EDIT#2 as a SEPARATE QUESTION if necessary, but for now I am keeping it here because the firewall settings might still be the problem. There is no evidence that these other topics are causing the problem. I am merely including them as due diligence.
I guessed that the lack of https access for suppliers might be due to the the fact that the apps are being served by tomcat behind an httpd reverse proxy. I therefore followed the instructions from this other posting to get tomcat to serve appTWO through port 8081 while continuing to serve appONE through port 8080. I opened ports 8080 and 8081 in the public zone of firewalld to confirm that both apps are being served correctly by tomcat.
I then examined the code for the reverse proxy connecting httpd and tomcat.
The reverse proxy is defined in httpd by the following file
/etc/httpd/conf.d/mydomain.com.conf, which had the following contents:
<VirtualHost *:443> ServerName www.mydomain.com ServerAlias mydomain.com ErrorLog /path/to/mydomain_com_error.log CustomLog /path/to/mydomain_com_requests.log combined SSLEngine on SSLProxyEngine on SSLCertificateFile /path/to/localhost.crt SSLCertificateKeyFile /path/to/localhost.key ProxyPass / ajp://my.server.ip.addr:8009/ ProxyPassReverse / ajp://my.server.ip.addr:8009/ </VirtualHost>
Note that mydomain.com is the hostname for the machine, but that there is no traffic from the internet coming to mydomain.com because https and http are closed in the public zone. Only OpenVPN users are able to access the web apps, and then only in the internal zone.
Tomcat's server.xml defines the reverse proxy with
<Connector port="8090" protocol="AJP/1.3" redirectPort="8443" />.
To experiment with a separate reverse proxy for appTWO on port 444, I added the following to
/etc/httpd/conf.d/mydomain.com.conf, following and in addition to the code section above:
#I added this entire following section as a test for this question <VirtualHost *:444> ServerName www.mydomain.com ServerAlias mydomain.com ErrorLog /path/to/mydomain_com_error.log CustomLog /path/to/mydomain_com_requests.log combined SSLEngine on SSLProxyEngine on SSLCertificateFile /path/to/localhost.crt SSLCertificateKeyFile /path/to/localhost.key ProxyPass / ajp://my.server.ip.addr:8009/ ProxyPassReverse / ajp://my.server.ip.addr:8009/ </VirtualHost>
I made sure that
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> was defined in both of the services in server.xml, but I still could not https when logged in to OpenVPN as a supplier.
I then experimented with port 8010 in both server.xml and
/etc/httpd/conf.d/mydomain.com.conf, but still could not get https access as a supplier.
Finally, I tried
[root@mydomain ]# telnet localhost 8010 Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused [root@mydomain ]# telnet localhost 8009 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'.
This causes me to wonder if perhaps the problem is that port 8010 is not open for the reverse proxy, thus causing suppliers not to be able to get access to appTWO.
However, I also uncommented the folowing in httpd.conf, and tried
https : / 10.8.0.1:444 again, but was still rejected, which causes me to wonder if the problem is in the firewall:
<Directory "/var/www"> AllowOverride None # Allow open access: Require all granted </Directory>
NOTE: I did not restart httpd.service.
If I could at least get suppliers to have static html served through https, then the firewall question could be considered solved and I could post the reverse proxy question separately, if necessary.
Based on @garethTheRed's edit, I deleted
https-app2 from the internal zone. I also deleted the
reject rich rules from the internal zone. And I added the new
accept rich rules with the exception that I gave administrators the right to see both
https-app2. The result is the following output when I type
firewall-cmd --list-all --zone=internal:
internal (active) interfaces: tun0 sources: services: dhcpv6-client ipp-client mdns samba-client ssh ports: masquerade: no forward-ports: icmp-blocks: rich rules: rule family="ipv4" source address="10.8.1.0" service name="https" accept rule family="ipv4" source address="10.8.1.0" service name="https-app2" accept rule family="ipv4" source address="10.8.2.0" service name="https-app2" accept rule family="ipv4" source NOT address="10.8.1.1" service name="ssh" reject rule family="ipv4" source address="10.8.0.0" service name="https" accept
I also kept the
<VirtualHost *:444> section in
/etc/httpd/conf.d/mydomain.com.conf as shown in EDIT#2 above. However, I did type
systemctl stop httpd.service and
systemctl start https.service before doing the tests described below.
But now I am not able to log in to https or https-app2 under any account.
For example, when I type
openvpn --config /path/to/employees.ovpn, the terminal replies with:
Thu Mar 12 09:46:22 2015 /usr/sbin/ip route add 10.8.0.1/32 via 10.8.0.9 Thu Mar 12 09:46:22 2015 Initialization Sequence Completed
This seems like I logged in, but then
https : / 10.8.0.1 and
https : / 10.8.0.1:444 both result in "Unable to connect" errors in Firefox.
openvpn --config /path/to/suppliers.ovpn results in:
Thu Mar 12 09:45:19 2015 /usr/sbin/ip route add 10.8.0.1/32 via 10.8.2.2 Thu Mar 12 09:45:19 2015 Initialization Sequence Completed
https : / 10.8.0.1 and
https : / 10.8.0.1:444 again both result in "Unable to connect" errors in Firefox.
And also, typing
openvpn --config /etc/openvpn/administrators.ovpn results in:
Thu Mar 12 09:15:36 2015 /usr/sbin/ip route add 10.8.0.1/32 via 10.8.1.2 Thu Mar 12 09:15:36 2015 Initialization Sequence Completed
https : / 10.8.0.1 and
https : / 10.8.0.1:444 still both result in "Unable to connect" errors in Firefox.
I AM able to
ssh firstname.lastname@example.org when connected to OpenVPN as administrator, so only the
https-app2 are broken.