Re: [vpp-dev] Linux-cp with Det44 stop working
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 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Linux-cp with Det44 stop working
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 On Mon, Feb 6, 2023 at 8:18 AM Petr Boltík wrote: > Hi all, > > I have an issue with a combination of Linux-cp + Det44. If Det44 is > activated, access to the VPP0 using Linux-cp is not working. All dynamic > configuration possibility is lost. I lose access from both sides - WAN and > LAN from any IP address (not only from configured 192.168.17.0/24). > Any suggestions? In which section of VPP code is Det44 hooked before > Linux-cp? Communication from PC1 to router0 successfully working. All ideas > are welcome. > > Thank you very much > > Petr B. > > > the simple scenario below ... > > Upstream router0 > + address 192.168.15.1/24 > + route 213.192.0.0/32 via 192.168.15.2 > > VPP0 Device: > WAN enp2s0 > + address 192.168.15.2/24 > + route 0.0.0.0/0 via 192.168.15.1 > + Linux-cp > > LAN enp3s0 > + address 192.168.16.1/24 > + route 192.168.17.0/24 via 192.168.16.2 > + Linux-cp > > det44 plugin enable > set interface det44 inside enp3s0 outside enp2s0 > det44 add in 192.168.17.0/24 out 213.192.0.0/32 > - > Internal router1 > + address 192.168.16.2/24 dev e1 > + address 192.168.17.1/24 dev e2 > + route 0.0.0.0/0 via 192.168.16.1 > - > PC1 - test device > + address 192.168.17.2/24 > + route 0.0.0.0/0 via 192.168.17.1 > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22552): https://lists.fd.io/g/vpp-dev/message/22552 Mute This Topic: https://lists.fd.io/mt/96783537/21656 Group Owner: vpp-dev+ow...@lists.fd.io
[vpp-dev] Linux-cp with Det44 stop working
Hi all, I have an issue with a combination of Linux-cp + Det44. If Det44 is activated, access to the VPP0 using Linux-cp is not working. All dynamic configuration possibility is lost. I lose access from both sides - WAN and LAN from any IP address (not only from configured 192.168.17.0/24). Any suggestions? In which section of VPP code is Det44 hooked before Linux-cp? Communication from PC1 to router0 successfully working. All ideas are welcome. Thank you very much Petr B. the simple scenario below ... Upstream router0 + address 192.168.15.1/24 + route 213.192.0.0/32 via 192.168.15.2 VPP0 Device: WAN enp2s0 + address 192.168.15.2/24 + route 0.0.0.0/0 via 192.168.15.1 + Linux-cp LAN enp3s0 + address 192.168.16.1/24 + route 192.168.17.0/24 via 192.168.16.2 + Linux-cp det44 plugin enable set interface det44 inside enp3s0 outside enp2s0 det44 add in 192.168.17.0/24 out 213.192.0.0/32 - Internal router1 + address 192.168.16.2/24 dev e1 + address 192.168.17.1/24 dev e2 + route 0.0.0.0/0 via 192.168.16.1 - PC1 - test device + address 192.168.17.2/24 + route 0.0.0.0/0 via 192.168.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22550): https://lists.fd.io/g/vpp-dev/message/22550 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] -=-=-=-=-=-=-=-=-=-=-=-
