There are three likely behaviors as the packet is sent from the LAN to the router:
- The router apply reverse route filtering and drop the packet.
- The router does not filter. Instead the router treat it like any other packet from the LAN, which means the source IP is replaced with the IP of the router, and the router create a connection tracking entry.
- The router does not apply filtering or NAT. Instead the router forward the packet with spoofed source address.
In the first case, nothing more happens. In the third case, the packet may be dropped or forwarded by the ISP. In one of these cases the spoofed packet makes it all the way to the target. But no reply will be coming back to this router, because it would go to the spoofed IP.
The most interesting case is the one where NAT is applied to the packet. The ISP will no longer be able to drop the packet based on the source IP, because in this case the source IP is in fact valid as far as the ISP is concerned. But this is not very harmful because the packets can be easily filtered based on source IP once they reach the destination (assuming the flood is large enough to be noticeable at the destination). It also cannot easily be abused in a reflection attack, because the replies go back to the NAT router.
What happens to any replies coming back to the NAT router is more interesting. They will match a connection tracking entry. But after the NAT has been applied, the destination address will not be inside the LAN, but externally. At this point there are a few possible outcomes:
- The router may refuse to forward the packet because it would be send back on the interface from whence it came.
- The router may forward the packet back on the outside network as soon as it has applied NAT according to the connection tracking entry.
- The router may attempt to perform NAT on the packet again, because it would be leaving on the external interface.
The first case where the packet is dropped, is not particular interesting or harmful.
The second case where the packet is forwarded back on the external network is more interesting. This is the case where the NAT prevented any spoofing from taking place in the first place, but a side effect of this is that on processing the reply, it actually produces a packet with spoofed source IP (effectively the source and destination IP of the original packet has been reversed).
If the ISP does not filter the packet due to invalid source IP, the return traffic will then be forwarded to the IP which was spoofed in the first place. And on arrival will look pretty much the same as it would, if no NAT had taken place at all.
But since this involves three trips across the external connection of the attacking network, the rate of attack traffic is limited compared to what it could have been.
If the router tries to NAT again, stuff gets a bit interesting. The issue here is that it isn't the first packet of a flow, so the NAT layer may not know how to deal with it. So the packet may be dropped because of NAT being applied without having seen the first packet of the flow.
It is also possible that a connection tracking entry is created. Since that newly created connection tracking entry was obviously not applied to the first packet of the flow, there is no way this could work at all for a TCP connection. But other protocols could possibly work even in such a scenario. However since this particular packet is due to spoofing, nothing good will come from NATing it.
If we assume this was a TCP SYN-ACK packet, and the router does NAT it again in spite of not making any sense at all, then the SYN-ACK will be forwarded by the ISP. The SYN-ACK will trigger a RST response (assuming the destination is functional), the RST will then go back through both connection tracking entries and get forwarded to the host from where the SYN-ACK came and clean up the connection.
As you can see, there is lots of ifs in this flow. And there is likely some possible outcome, which I have not considered.