Persistent connection/ iptables

Content Authoring
1

We have persistent connection enables across the board but we have 200+ openshift server which has iptables configured. The iptables is necessary part of the openshift cluster. We can’t turned it off. or we can’t use the bigfix fixlet either to modify the iptables to jeopardize the openshift functioanlity.

this what we have in the iptables about the udp.
# iptables --list|grep -i udp
ACCEPT udp – anywhere anywhere udp dpt:4789 /* VXLAN incoming */
ACCEPT udp – anywhere anywhere state NEW udp dpt:4789

The odd part is some of the openshift node do respond to the bigfix query and some don’t. I am suspecting it could be the iptables playing tricks but i can’t pin point it.

Does the persistent connection make any diff to get the query response ? I don’t think its making any difference in this case. do we have another way to get the query response without updating iptables?

https://help.hcltechsw.com/bigfix/9.5/platform/Platform/Config/c_persistenconn.html

2

Can you add a rule to iptables to allow inbound udp to destination port 52311 ?

Persistent Connections will enable Query, as long as you don’t exceed the number of persistent Connections allowed on the Relay.

3

I am contemplating that to add the rule in the openshift cluster but it will be uphill battle to convince the openshift team to add that rule.
we are not exceeding the persistent connection limit though.
I don’t think persistent connection is in picture to reply back the query, even the other node in same openshift cluster/subnet is replying back. Some thing really funky about the iptables.

4

Does the bigfix has way to test udp ping ( 52311/udp) ?
Openshift guys throw punch on my face that its not the firewall its bigfix issue, I know its firewall is messing the query response.

5

This is iptables setting where 52311/udp packet is getting dropped. I am wondering if “*nat” is dropping the udp packet.

$ cat /etc/sysconfig/iptables
# Generated by iptables-save v1.4.21 on Fri Jan 10 22:33:46 2020
*nat
...
COMMIT
# Completed on Fri Jan 10 22:33:46 2020
# Generated by iptables-save v1.4.21 on Fri Jan 10 22:33:46 2020
*filter
...
COMMIT

The server which accepts the packet it has 800 lines in the iptables but no “*nat” top in the config.

6

If the system is behind a Hide NAT then the UDP message will not make it there; you’d need to use Persistent Connections or Command Polling. Command Polling is not likely to help with Query, but would give faster responses to actions or new content updates.

7

I will try that. I am wondering if the order “*nat” is messing udp response.
This is where UDP works. *nat is after the *filter. but in case where it didnt’ work *nat is first and then *filter

$ cat /etc/sysconfig/iptables
# Generated by iptables-save v1.4.21 on Sat Oct 19 15:42:21 2019
*filter
:INPUT ACCEPT [0:0]
…
COMMIT
# Completed on Sat Oct 19 15:42:21 2019
# Generated by iptables-save v1.4.21 on Sat Oct 19 15:42:21 2019
*nat
…
COMMIT

8

I think bigfix should come up utility ( wintel and unix) to test “tcp/udp” connection to besclient and run sample query on the besclient using that utility to eliminate all the hoops of relay host between the besclient.
Not sure how to request that sort of enhancement.

9

I’m not sure what that would prove that query doesn’t, or watching the client log after a “force refresh”.

Or really, what it would matter since you said you aren’t allowed to apply the rules to iptables anyway. You just won’t be able to use Query. The old-school method, before Query, was to write Analyses for whatever you want to check, so that will probably need to remain in your workflow.