does VPP support ACL-based NAT?
 
by that i mean can I have a NAT44 entry that is only triggered for packets matching an ACL?
 
I want to replicate what the kube-proxy component in Kubernetes does today using iptables.
 
as an example for kube-dns you’ll see the following entries for UDP port 53:
 
-A KUBE-SERVICES -d 10.96.0.10/32 -p udp -m comment --comment "kube-system/kube*dns*:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU
A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kubedns:dns" -j KUBE-SEP-TMWAR6GAXPQPDDNX
A KUBE-SEP-TMWAR6GAXPQPDDNX -s 10.1.1.2/32 -m comment --comment "kube-system/kubedns:dns" -j KUBE-MARK-MASQ
A KUBE-SEP-TMWAR6GAXPQPDDNX -p udp -m comment --comment "kube-system/kubedns:dns" -m udp -j DNAT --to-destination 10.1.1.2:53
 
As far as I can work out the reason there’s an intermediate “SVC” rule between the “SERVICES” and the “SEP” (service endpoint) rule is so Kubernetes can support load balancing for services.
 
I’ve hacked up a modified kube-proxy for now - that inserts an extra rule between the two SEP rules to do an SNAT for outbound traffic as well as inbound.  That way the outbound packets appear to come from the host kernel rather than the application pod, so they flow back through iptables rather than going direct to the application pod.  That fixes e.g. DNS lookup and Istio service discovery in our environment but means that to get the benefit of VPP performance we need to send traffic "pod to pod" rather than “pod to service”.
 
so what I’m looking to do is to implement VPP as a provider for kube-proxy so we can get full performance for pod to service traffic.  I’d probably go via the Ligato VPP agent rather than going direct to GoVPP.  But of course it depends on VPP being able to support SNAT and DNAT based on protocol/port/IP match.