Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1231127

Summary: Router stats port will be rejected by iptables on ose
Product: OpenShift Container Platform Reporter: zhaozhanqi <zzhao>
Component: NetworkingAssignee: Dan Mace <dmace>
Networking sub component: router QA Contact:
Status: CLOSED WONTFIX Docs Contact:
Severity: low    
Priority: medium CC: bbennett, bleanhar, dmcphers, ederevea, pep, rbost, sdodson
Version: 3.2.0Keywords: Reopened
Target Milestone: ---   
Target Release: 4.1.0   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-01-30 18:39:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description zhaozhanqi 2015-06-12 08:21:50 UTC
Description of problem:
Create router on ose env, the router stats page cannot be accessed.

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1. Create router with default stats port
   oadm router --credentials=/etc/openshift/master/openshift-router.kubeconfig --images=registry.access.redhat.com/openshift3/ose-haproxy-router:v0.6.0.1
2. the default stats-port is 1936, so access the stats page
   http://$nodeip:1936
3.

Actual results:
The page can not be accessed

Expected results:
The page can be accessed

Additional info:

Checked the iptables, seems it will be rejected with INPUT chain

14   REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

When I deleted this chain, the page will be accessed.

Comment 2 Paul Weil 2015-06-12 15:09:18 UTC
Discussed in libra:

<pweil> sdodson, who is the right person to look at ose iptables issues?  https://bugzilla.redhat.com/show_bug.cgi?id=1231127
<sdodson> pweil: I sort of saw that as a one-off thing that admins would enable or disable on their own.
<sdodson> pweil: I think if we want to automate it, we want to default to blocking.
<pweil> sdodson, you ok with me putting it to ON_QA with that comment?
<sdodson> bleanhar: You ok with us not adding iptables rules for haproxy stats port by default?
<sdodson> pweil: Perhaps only from localhost?
<bleanhar> only from localhost sounds ok
<sdodson> pweil: assign it to me, i'll work on having ansible open the port on all hosts that have label infra
<pweil> ok

Comment 3 Scott Dodson 2015-06-12 15:10:36 UTC
We'll look at implementing this in ansible post GA, leaving bug as NEW.

Comment 4 Scott Dodson 2016-01-28 15:57:42 UTC

*** This bug has been marked as a duplicate of bug 1293578 ***

Comment 5 zhaozhanqi 2016-02-22 08:08:38 UTC
since bug 1293578 has been verified, and it can be access using 1936 using 'localhost'

-bash-4.2# curl localhost:1936
<html><body><h1>401 Unauthorized</h1>
You need a valid user and password to access this content.
</body></html>

I'm wondering how to access stats page by public ip since we cannot access it using 'localhost' or internal ip from outside.

-bash-4.2# curl openshift-143.lab.sjc.redhat.com:1936
curl: (7) Failed connect to openshift-143.lab.sjc.redhat.com:1936; No route to host

so we still need to add the following rule to solve the issue:
iptables -I OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 1936 -j ACCEPT

or do we have another way to resolve this issue?

Comment 6 Scott Dodson 2016-02-22 14:03:30 UTC
Zhao,

I don't think we'll open up port 1936 by default as we'd have to either figure out which hosts are running the router or open it up on all nodes which is undesirable. I think the usefulness of opening 1936 externally is nearly zero. If someone were to write monitoring scripts they'd probably run those scripts on the hosts where the router is running.

I can make sure that we have docs that explain the need to open up port 1936 if you want access to the stats from outside the host.

Do you think that's sufficient?

Brenton, your thoughts on if we should open 1936 by default now that the liveness probe no longer requires it?

Comment 7 Brenton Leanhardt 2016-02-22 14:13:09 UTC
I don't think we should open it up.  Admins will know best if this is secure in their environment.  Like you mentioned the focus of our bug fixes was to ensure the liveness probes could function securely.  I'm find with someone adding a note to our documentation on how to access this page.

Comment 8 Evgheni Dereveanchin 2016-04-01 08:02:17 UTC
There are some use cases when opening port 1936 is needed: for example in cases when there's a load balancer in front of HA routers, which has to monitor health of the actual router. In this case port 1936 will not be accessible from the Internet, yet it has to be open on nodes. 

I think there has to be an option, or at least documentation on how to do this with Ansible to ensure all newly added hosts have the port open, as well as ensuring updates don't close this port.

Comment 9 Josep 'Pep' Turro Mauri 2016-04-01 12:47:10 UTC
For special needs it should be fine to have custom firewall rules, but these would be added/managed outside of the OpenShift installer. The installer can't (and probably shouldn't) aim to cover all potential customizations.

The requirement here would be that the installer does not interfere with them, but this should already be the case.

Will create a kbase entry to document how to open that port for that purpose and link it here. Let me know if that's not enough.

Comment 10 Ben Bennett 2017-06-22 20:53:49 UTC
Closing because this is the admin's responsibility to open.

Comment 11 Robert Bost 2018-10-08 16:09:20 UTC
> I think the usefulness of opening 1936 externally is nearly zero. If someone were to write monitoring scripts they'd probably run those scripts on the hosts where the router is running.

I'd like to reopen this bug for reconsideration since the addition of Prometheus monitoring to OpenShift. The Prometheus installation playbook configures monitoring via router.default.svc:1936. This requires port 1936 to be opened on the node where the router is running. 

It is awkard to have the completely automated Prometheus installation playbook and then one manual step of opening the port. Can the iptables rule be included in the playbook?