ATTENTION Customers, All Partners and Employees: The Customer Support Portal (CSP) will be undergoing maintenance and unavailable on Saturday, November 7, 2020, from 11 am to 11 pm PST. Please read our blog for more information.
Hey TyMiller Thanks for reaching out via email and showing interest in this implementation. I am the developer who implemented this functionality. Thank you for the detailed use cases and the potential solutions. Just to get started, I will try to clarify some additional details. - Everything we configure needs to be possible through the CS UI (or API). This means we need to understand what the expected flow is in CS for the desired functionality. - What you are referring to as the 'Default Deny Policy' is the 'Default Egress Policy' in CS. This default policy can be either a default of 'allow' or 'deny' depending on how the network is setup, so we have to be able to handle both cases. - CS distinguishes between Egress (leaving the network) and Ingress (entering the network) ACL policies, so we need to consider this when defining a solution. - CS does not support the ordering of ACL policies (PAN does). There are a couple ACL policies which will always be ordered in my implementation. The 'isolation' policy will always be the first policy for a specific network. The default egress policy will always be the last egress policy for a network. - Ordering of policies on the PAN is VERY hard with this implementation because CS does not respect ordering, so it can add policies in any order once things are initially setup, so you can never guarantee the order of policies on the PAN. The way I am guaranteeing the order of those two policies is by making sure that the 'isolation' policy is ALWAYS the first policy added (and every additional policy is added after by default). The way I am ensuring that the default egress policy is always the last egress policy is by watching for new egress policies. If a new egress policy comes in, I check if there is a default egress policy, if there is I save it into memory and delete it from the PAN. Then I add the new egress policy and then re-add the default egress policy after it. This works because it is a single policy so every time I want to add a new egress policy I can make sure the default egress policy is deleted and re-added after it. More complex ordering will be almost impossible... - When you acquire a new IP address for VM, it does not always have to be implemented as a static NAT rule. A VM can get a public IP address through either a static NAT rule or a destination NAT rule (also called a Port Forwarding rule). It can also get a public IP through a Load Balancing rule, but that is not implemented on the PAN. Ok, on to some of the finer points... - My current implementation assumes that an Egress policy will go from the trust-to-untrust. It is probably a good idea for me to modify this behavior to go from trust-to-any so that an egress policy could have a private destination as well as a public destination. - Likewise, my current implementation assumes that an Ingress policy will go from untrust-to-trust. It is probably a good idea for me to modify this behavior so it can do any-to-trust so that an ingress policy can origin from a private source as well as a public source. - The 'isolation' policy is required because every private vlan is implemented on the same physical interface. Without that policy then all the different vlans could just talk to each other unhindered because they are all theoretically physically connected. - My understanding is that two vlans can currently talk to each other, but the traffic has to go through the public network on both sides. So it has to go from trust-to-untrust and then from untrust-to-trust. So you would have to setup static NAT on both sides and then connect through the public static NAT IP addresses. I could be wrong, but I thought I had tested that (it was a long time ago)... Here is my initial thoughts on a potential solution (very theoretical at this point, tbd if it is possible)... I think it is VERY important that inter-vlan functionality is approved by the owners of both vlans because it would be a huge security risk otherwise. If one vlan can setup access to another vlan and get access without the other side having to agree to this connection this would be very bad. Consider that in most CS use cases these different vlans are owned by different accounts/companies, so it is usually important that they CAN NOT talk to each other. Because of this policies would have to be created on both sides for the connection to be able to work. - Modify the implementation of Egress policies to go from trust-to-any - Modify the implementation of Ingress policies to go from any-to-trust - Setup an Egress policy on vlan1 to allow traffic from a portion of its CIDR out on specific ports. This assumes a 'deny' default. If setup with an 'allow' default I don't think this is required. - Setup an Ingress policy on vlan1 to allow traffic from a portion (or all) of vlan2's CIDR on some specific ports. - Setup an Egress policy on vlan2 to allow traffic from a portion of its CIDR out on specific ports. This assumes a 'deny' default. If setup with an 'allow' default I don't think this is required. - Setup an Ingress policy on vlan2 to allow traffic from a portion (or all) of vlan1's CIDR on some specific ports. - When the Ingress policies are made, I will need to check if the source CIDR is public or private. If it is private, I will have to update the 'isolation' rule to allow that vlan to talk to its own gateway AS WELL as the private range specified by the Ingress rule. This will be done on both vlans because the Ingress rules would be created in both vlans. I believe this would extend the functionality to cover your use case. Yes??? If you have a lab setup and are able to test this scenario to see if the networking actually does work how I expect it to that would be awesome. I will still need to verify that CS will let us to specify an ingress rule with a different vlan's private cidr, but if it doesn't I might be able to extend the functionality to add this support as well. Let me know what you think of this proposed solution. If you want to discuss more you can get in touch with me over Linked In (I accepted your invitation earlier today). Cheers, Will
... View more