2

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 /etc/openvpn/server.conf,

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.crt and suppliers.key to the client computer, and created the following suppliers.ovpn file:

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 https and 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?


EDIT


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   

Typing 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 and 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 my.server.ip.

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/administrators and /etc/openvpn/ccd/suppliers shown above.


EDIT#2


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.


EDIT#3


Based on @garethTheRed's edit, I deleted https and 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 and 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.

Similarly, typing 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

But then 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

But then 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 username@10.8.0.1 when connected to OpenVPN as administrator, so only the https and https-app2 are broken.

1

Run app1 on the default https port (443) and run app2 on another port (444 - Unless you're using SNPP in which case you'll need to choose another free port).

Clone the https.xml file (located in /usr/lib/firewalld/services) to /etc/firewalld/services and rename it to (for example) https-app2.xml.

Edit this new file and change the port to 444.

Ensure that https (and https-app2) are removed from the internal zone.

Run:

firewall-cmd --zone=internal --add-rich-rule='rule family="ipv4" source address="10.8.0.0/24" service name="https" accept'
firewall-cmd --zone=internal --add-rich-rule='rule family="ipv4" source address="10.8.0.0/24" service name="https-app2" accept'
firewall-cmd --zone=internal --add-rich-rule='rule family="ipv4" source address="10.8.1.0/24" service name="https" accept'
firewall-cmd --zone=internal --add-rich-rule='rule family="ipv4" source address="10.8.2.0/24" service name="https-app2" accept'

Note that these are not permanent, therefore if they work, you'll need to re-run them all with --permanent appended.

  • @CodeMed - if you get this to work, you could consider adding a port forward later so that users of app2 do not have to add :444 to their URL. – garethTheRed Mar 11 '15 at 21:10
  • It is giving me appONE both at https : / 10.8.0.1:444 and at https : / 10.8.0.1. I guess this means the firewall is not causing the problem, so I marked this +1 accepted. But do you have any insights as to why it is not routing 444 requests to appTWO? When I tried to have the appTWO ajp work on port 8010, I got the telnet failure shown in one of my edits above, so port 8009 is used to reverse proxy both apps. I'm not sure if this is the problem. – CodeMed Mar 12 '15 at 20:07
  • That solved the problem. Thank you again. – CodeMed Mar 12 '15 at 20:43
  • @CodeMed - No problem. I've tidied the answer so that it answer your original question and nothing more. – garethTheRed Mar 12 '15 at 20:51
  • I apologize for pinging you twice about this other question, but the deeper I get into it, the more it seems like it elaborates upon things that you have taught me in other postings. I just added the ifcfg-* files. Are you willing to take a look? Here is the link: unix.stackexchange.com/questions/235958/… – CodeMed Oct 15 '15 at 0:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.