VR Port Forward rule check on Non-VPC Isolated networks

[Pearl1594]

Description

Port forwarding rules not checked properly on Isolated networks (non-VPC)
Port forwarding checks is reported as failing on non-VPC Isolated networks (works fine on VPC Isolated networks).
Reason for this seems to be different IP tables rules when it comes to non-VPC vs VPC Isolated network.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)

Screenshots (if appropriate):

How Has This Been Tested?

Ran the Health check on UI and cmk and obtained successful results for Isolated networks (VPC and non-VPC)

[DaanHoogland]

code looks good

[DaanHoogland]

@Pearl1594 there is a pylint failure. Can you have a look?

[Pearl1594]

@DaanHoogland handled the previous pylint failure. Looking into the current one, but not exactly sure what it is

[DaanHoogland]

E:392,12: Too many positional arguments for function call (too-many-function-args)

---

Your code has been rated at 9.99/10

9.99/10 is good @Pearl1594 ;) but pylint wants perfection :(
I think the solution is to change positional paramters to named parameters. This can also contribute to the readability.

[weizhouapache]

we need to review the iptables rules in isolated network and vpc

[weizhouapache]

@rhtyd @Pearl1594
I will check the iptables rules in VPC/network VRs.
The iptables rules for port forwarding in VRs should be very similar.

it is not an issue with monitoring script I think.

[weizhouapache]

check network VR and VPC VR, found difference as below

1. network VR

root@r-753-VM:~# iptables-save |grep POST
-A POSTROUTING -s 192.168.10.0/24 -d 192.168.10.251/32 -o eth0 -p tcp -m tcp --dport 22 -j SNAT --to-source 192.168.10.141

2. VPC VR

root@r-1074-VM:~# iptables-save |grep POST
-A POSTROUTING -d 10.11.118.150/32 -p tcp -m tcp --dport 22 -j SNAT --to-source 192.168.0.12:22
-A POSTROUTING -s 192.168.0.0/27 -d 192.168.0.12/32 -o eth2 -p tcp -m tcp --dport 22 -j SNAT --to-source 192.168.0.3

3. The first rule in VPC VR seems wrong.
   everything seems ok even if I remove it in VPC VR.

root@r-1074-VM:~# iptables -t nat -D POSTROUTING -d 10.11.118.150/32 -p tcp -m tcp --dport 22 -j SNAT --to-source 192.168.0.12:22

@rhtyd @DaanHoogland @Pearl1594 I will create a PR to remove the rule in VPC VR. what do you think ?

[DaanHoogland]

you might be right @weizhouapache but i am missing some context.
Are you stating that this fix is not needed, or not enough?
As for your example; what rule did you add?
It seems you added portforwarding on port 22 in one case from 192.168.10.251 to 192.168.10.141 and in the other case from 192.168.0.12 to 192.168.0.3. is that correct?

the rule -A POSTROUTING -d 10.11.118.150/32 -p tcp -m tcp --dport 22 -j SNAT --to-source 192.168.0.12:22 is in the way, how?

All that said, what is the course of action in your opinion?

[DaanHoogland]

@blueorangutan package

[blueorangutan]

@DaanHoogland a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

[blueorangutan]

Packaging result: ✖centos6 ✔centos7 ✖debian. JID-1022

[DaanHoogland]

@blueorangutan test

[blueorangutan]

@DaanHoogland a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

[blueorangutan]

Trillian test result (tid-1210)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 39215 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr3937-t1210-kvm-centos7.zip
Intermittent failure detected: /marvin/tests/smoke/test_internal_lb.py
Intermittent failure detected: /marvin/tests/smoke/test_kubernetes_clusters.py
Smoke tests completed. 83 look OK, 0 have error(s)
Only failed tests results shown below:

Test	Result	Time (s)	Test File

[DaanHoogland]

@weizhouapache can we merge this and solve your issue in a separate PR?

[andrijapanicsb]

This one was implemented via simpler fix, as discussed on #3952 - via #3963 - so closing this PR.