Skip to content

Port-forwarding not working in VPC Virtual Router #9053

Closed
Closed
Port-forwarding not working in VPC Virtual Router#9053
Milestone
unplanned

Description

@cdfgallo
cdfgallo
opened on May 7, 2024
ISSUE TYPE
  • Bug Report
COMPONENT NAME
VR in VPC
CLOUDSTACK VERSION
4.19
CONFIGURATION

Advanced networking, VPC network

OS / ENVIRONMENT

N/A

SUMMARY

It looks like that, starting with CS version 4.19, the VR is not properly forwarding traffic to the VM when a port-forwarding rule is created on a secondary IP assigned to the VR.

STEPS TO REPRODUCE
Create a VPC (or use an existing one).
Create a new network tier.
Create a new VM in the tier.
Assign a new Public IP address to the VR and configure a pf rule on it.
Create a new ACL rule allowing traffic on the public port selected.
Try to reach the service exposed on the VR.
EXPECTED RESULTS
You should be able to reach the service
ACTUAL RESULTS
You can't reach the service. Executing a tcpdump on the VR I saw that traffic is not forwarded to the VM behind it and no nat rules were created in iptables.
Rebooting the VR or re-creating it doesn't resolve.

As a work-around (still a poor one) you can use LB service on the VR instead of PF. Haproxy works as expected.

Activity

  1. boring-cyborg commented on May 7, 2024

    @boring-cyborg
    boring-cyborgbot
    on May 7, 2024 – with boring-cyborg

    Thanks for opening your first issue here! Be sure to follow the issue template!

  2. weizhouapache commented on May 7, 2024

    @weizhouapache
    weizhouapache
    on May 7, 2024
    Member

    @cdfgallo
    the issue looks same as an issue I reported before: #8366

  3. cdfgallo commented on May 7, 2024

    @cdfgallo
    cdfgallo
    on May 7, 2024
    Author

    @weizhouapache it looks similar but it's not related to the VM configuration but on the VR configuration.
    The issue is present if any configuration is applied on any other additional IP of the Virtual Router.

  4. weizhouapache commented on May 7, 2024

    @weizhouapache
    weizhouapache
    on May 7, 2024
    Member

    @weizhouapache it looks similar but it's not related to the VM configuration but on the VR configuration. The issue is present if any configuration is applied on any other additional IP of the Virtual Router.

    oh, I did not notice it, sorry @cdfgallo

    are the public port and private port the same ?

    can you share the output of iptables-save command in the VPC VR in both scenarios (lb and pf) ?

  5. weizhouapache commented on May 7, 2024

    @weizhouapache
    weizhouapache
    on May 7, 2024
    Member

    @cdfgallo I was able to reproduce the issue.
    However, I think the ACL rule should use the private port, not the public port. If use private port, both LB/PF should work

    The major issue in my testing is, LB on additional public IP range always works, even if the ACL rule list is set to "default_deny".
    can you test and confirm it ? @cdfgallo

  6. cdfgallo commented on May 8, 2024

    @cdfgallo
    cdfgallo
    on May 8, 2024
    Author

    @cdfgallo I was able to reproduce the issue. However, I think the ACL rule should use the private port, not the public port. If use private port, both LB/PF should work

    @weizhouapache
    using LB I was able to have it working allowing the public port in ACL rules, insted with port-forwarding it looks like it works with the private port, I'll keep that in mind.

    The major issue in my testing is, LB on additional public IP range always works, even if the ACL rule list is set to "default_deny". can you test and confirm it ? @cdfgallo

    I'll try that @weizhouapache

  7. weizhouapache commented on May 8, 2024

    @weizhouapache
    weizhouapache
    on May 8, 2024
    Member

    @cdfgallo I was able to reproduce the issue. However, I think the ACL rule should use the private port, not the public port. If use private port, both LB/PF should work

    @weizhouapache using LB I was able to have it working allowing the public port in ACL rules, insted with port-forwarding it looks like it works with the private port, I'll keep that in mind.

    my finding is, the LB always works, no matter what ACL rules are. I have created an issue #9054

    The major issue in my testing is, LB on additional public IP range always works, even if the ACL rule list is set to "default_deny". can you test and confirm it ? @cdfgallo

    I'll try that @weizhouapache

    thanks @cdfgallo
    If port forwarding works with the ingress rule with private port , can we close this issue ?

  8. cdfgallo commented on May 8, 2024

    @cdfgallo
    cdfgallo
    on May 8, 2024
    Author

    my finding is, the LB always works, no matter what ACL rules are. I have created an issue #9054

    I'd guess that LB works because its iptables rules are in the "INPUT" chain which is checked before the "FORWARD" chain (where the ACL for the tier resides).

    The major issue in my testing is, LB on additional public IP range always works, even if the ACL rule list is set to "default_deny". can you test and confirm it ? @cdfgallo

    I'll try that @weizhouapache

    thanks @cdfgallo If port forwarding works with the ingress rule with private port , can we close this issue ?

    @weizhouapache yes, we can close the issue!

  9. weizhouapache commented on May 8, 2024

    @weizhouapache
    weizhouapache
    on May 8, 2024
    Member

    my finding is, the LB always works, no matter what ACL rules are. I have created an issue #9054

    I'd guess that LB works because its iptables rules are in the "INPUT" chain which is checked before the "FORWARD" chain (where the ACL for the tier resides).

    agree @cdfgallo
    thanks for the points.

    The major issue in my testing is, LB on additional public IP range always works, even if the ACL rule list is set to "default_deny". can you test and confirm it ? @cdfgallo

    I'll try that @weizhouapache

    thanks @cdfgallo If port forwarding works with the ingress rule with private port , can we close this issue ?

    @weizhouapache yes, we can close the issue!

    closing

  10. weizhouapache
    closed this as completedon May 8, 2024
  11. DaanHoogland
    added this to the unplanned milestone on Sep 20, 2025

  12. daviftorres commented on Jul 31, 2026

    @daviftorres
    daviftorres
    on Jul 31, 2026
    Contributor

    This issue is certainly present it latest version because I stumbled on it multiple times this week until I realized it was a known bug.

  13. DaanHoogland commented on Jul 31, 2026

    @DaanHoogland
    DaanHoogland
    on Jul 31, 2026
    Contributor

    @daviftorres , as @weizhouapache and @cdfgallo agreed this could be closed I think you should open a new issue. Maybe expanding onto why the reason for closing it, does not apply to your situation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions