VPC SourceNat with Port Forwarding

[alexandru-bagu]

I am wondering why the VPC network cannot offer both SNAT and PortForwarding. At the moment the VPC offering must be "Non Conserve". A network being "non conserve" means only one service type is allowed to be enabled at any one point. The issue is while Port Forward might be considered a separate service than Source Nat I do not see why a VPC network cannot do both at the same time. I tracked the issue to this place in code public boolean canIpUsedForNonConserveService(PublicIp ip, Service service) which is used by public Map<PublicIpAddress, Set<Service>> getIpToServices(List<? extends PublicIpAddress> publicIps, boolean postApplyRules, boolean includingFirewall).

Is there any specific reason why CloudStack would not be able to manage port forwarding rules on the SNAT ip for a VPC network? I've done some small tests with portfowarding on the VR and there did not seem to be any issues.

I've searched the issues for this but I did not find anything about it. I hope it's not a duplicate.

ISSUE TYPE

Improvement Request

COMPONENT NAME

VR

CLOUDSTACK VERSION

4.14.0.0 - 6f96b3b

[DaanHoogland]

@alexandru-bagu I could only imagine that unpredictable conflicts may arise from binds on forwarded ports choosing ports in use by an outgoing connection, or so. I think you are right and it could work in principle. cc @andrijapanicsb @PaulAngus ?

[alexandru-bagu]

@alexandru-bagu I could only imagine that unpredictable conflicts may arise from binds on forwarded ports choosing ports in use by an outgoing connection, or so. I think you are right and it could work in principle. cc @andrijapanicsb @PaulAngus ?

Any service that relies on the source nat ip would create a conflict like the VPN that can be setup with one click. However that should not restrict it's usage. Unless the system is intended to be idiot-proof the possible conflicts should not prevent other proper uses. At the moment the public ip used for source-nat is somewhat wasted because it can be used for only vpn (or other pre-defined services).

Edit 1: I suppose outgoing port binds might also create some conflicts but again that should not prevent all port forwards. Outgoing ports are generally above 50k and most services use ports below 10k.

Edit 2: I imagine the source-nat for a vpc network works the same as a wan connection on a normal house-hold router. Am I wrong?

[DaanHoogland]

Ad 2: yes, for sure.

[alexandru-bagu]

What would the guidelines be for creating a pull request for this? Can someone tell me if, at least for the API side, it's enough to modify the function public boolean canIpUsedForNonConserveService(PublicIp ip, Service service)? I will assume no and I guess I will become clear during development. Even so, maybe someone can point out possible issues that might arise so that I can test them too?

[DaanHoogland]

@alexandru-bagu I'm sure I'm going to forget a lot of issues but one thing to keep in mind is that source nat is for all of the VPC. Portforwarding would be for a specific VM on a specific client net, unless you are load-balancing! in which case it is a bit more complicated. a lot of scenarios to test there. (sorry for kicking in open doors).

If you speak of guideline it is that the feature must be tested/testable by unit-, integration or #!human script or a combination thereof. In the #!human case there is no guarantee the community will take it into account when building further on the system. there is a limited degree of maintenance burden on the users of the feature and it is in your interest to make tests as automated as possible.

happy dev'ing and there is dev@cloudstack.apache.org if you need hints or other help.

[DaanHoogland]

@alexandru-bagu are you still planning work on this (for 4.16) or should we archive the issue/mark it as unplanned?

[alexandru-bagu]

I've found workarounds for my requirements so I am not planning on working on this issue.
I tried a few changes but the fact that currently the ip must be associated with a network tier before it can be used makes it hard to implement.

[weizhouapache]

I have tried with latest main branch, the behaviour is same

(localcloud) 🐱 > create loadbalancerrule publicipid=57128f09-d932-4352-9a58-a7042fbe36b0 protocol=tcp publicport=8080 privateport=8080 algorithm=roundrobin name=test
🙈 Error: (HTTP 431, error code 9999) IP address ID=4 is not associated with any network

(localcloud) 🐱 > create portforwardingrule ipaddressid=57128f09-d932-4352-9a58-a7042fbe36b0 publicendport=8080 publicport=8080 privateport=8080 privateendport=8080 protocol=TCP virtualmachineid=cdda585f-f38b-4348-8d18-cae3d34979ff 
🙈 Error: (HTTP 431, error code 4350) Unable to create port forwarding rule for the ipAddress id=4 as ip is not associated with any network and no networkId is passed in

The public ip must be assocaited to a network (or vpc tier) before creating a LB rule or port forwarding rule.
However, the Source Nat IP is associated to the whole VPC, not a specified vpc tier.

It looks like a big change, let's move to 4.19.0.0