Hi Matt, Thank you for the detailed explanation. Bad news, this combination would be interesting. I'm already using nat44_ed plugin - there is a "hack" how to force tcp traffic through the WAN interface (with output-feature enabled) to the linux-cp. You can just add nat44_add_del_static_mapping with the WANs IP address. It is not the best solution but works for the BGP.
Is there (in VPP) some way how to configure multiple source nat (output feature) like iptables? "-s 192.168.20.0/24 -j SNAT --to 11.22.33.0/30" "-s 192.168.21.0/24 -j SNAT --to 11.22.33.4/30" Petr po 6. 2. 2023 v 18:12 odesílatel Matthew Smith via lists.fd.io <mgsmith= netgate....@lists.fd.io> napsal: > > Hi Petr, > > Deterministic NAT is not compatible with linux-cp. > > Linux-cp sets up some configuration for interfaces which are a member of a > linux-cp interface pair so that packets which arrive on the interface and > are punted get copied to the corresponding linux-cp tap. The packets which > are punted have a destination IP address that is "local' (usually interface > address or broadcast/multicast, but I believe that addresses in a NAT pool > also get local routes added) and are not handled by any other node via > registration of the destination protocol or port of the packet. For a > packet to be punted to the host across a linux-cp tap, it has to pass all > the way through the ip4-unicast feature arc. A FIB lookup happens at the > end of ip4-unicast, which determines that the destination is local and > passes packets to ip4-receive. From there, the packets can be sent across > the linux-cp tap. > > Deterministic NAT has an out2in node on the ip4-unicast arc of an outside > interface which compares an inbound packet to any deterministic NAT > mappings that are configured. If it finds a relevant mapping & session for > the destination address/port, the destination address/port will be > rewritten and the packet will be forwarded. If none is found, the packet > will be dropped before it reaches the point where it could be punted and > sent across a linux-cp tap. So even though your inbound packets may be > addressed to the WAN interface address and not an address in the prefix > being used by deterministic NAT, they will be dropped. This seems to be the > default behavior of at least the det44, nat44-ed, and nat44-ei plugins - > they seem to assume that all packets passing through an interface should be > translated or dropped. IMO it seems like it would be better if an inbound > packet that has a destination address which is not in the NAT pool/prefix > should pass through the NAT out2in feature untouched, but that's not > currently how the NAT plugins work. > > There is also a deterministic NAT in2out node on the ip4-unicast arc of an > inside interface that rewrites a packet's source address/port. This node > checks the source address to find if it matches an inside NAT prefix. If > not, the packet is dropped. If the source address is in an inside prefix, > the source address/port are rewritten. This happens, again, before the > packet reaches the end of ip4-unicast so the source address/port are > rewritten before it is determined that the destination address is local to > the system. I'm not sure exactly what happens once the FIB lookup occurs > and the packet is determined to have a local destination. I suspect that it > will be dropped by ip4_local_check_src() in ip4-receive ( > https://github.com/FDio/vpp/blob/master/src/vnet/ip/ip4_forward.c#L1581) > because it will have a source address that is local and a destination > address that is local so it will be considered "spoofed". My guess may be > wrong and the packet may reach the tap but it will already have a rewritten > source address/port so replies sent by the host would not be sent to the > correct address/port. > > I haven't experimented with it much, but I would guess that deterministic > NAT is not likely to be compatible with any other feature in VPP that > processes local packets (DHCP, DNS, IPsec/IKE, etc) for the same reasons > that linux-cp doesn't work. > > -Matt > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22553): https://lists.fd.io/g/vpp-dev/message/22553 Mute This Topic: https://lists.fd.io/mt/96783537/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
