Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NAT broken for ICMP messages that contain original datagram as payload. #369

Open
rcgoodfellow opened this issue May 13, 2023 · 0 comments
Milestone

Comments

@rcgoodfellow
Copy link
Contributor

There are several ICMP messages that contain a copy of the original datagram that caused the ICMP message to be sent. When the sender of the original message is behind an OPTE NAT, the expectation would be that the copy of the original datagram in the ICMP message payload would be translated to be consistent with what the guest sent.

As a concrete example, we see traceroute packets like the following from within the guest.

23:32:41.655456 IP (tos 0x0, ttl 250, id 2385, offset 0, flags [DF], proto ICMP (1), length 96)
    68.86.93.241 > 172.30.0.5: ICMP time exceeded in-transit, length 76
        IP (tos 0x20, ttl 1, id 28766, offset 0, flags [DF], proto ICMP (1), length 60)
    10.100.0.11 > 1.1.1.1: ICMP echo request, id 914, seq 19, length 40 (wrong icmp cksum c209 
(->7ed5)!)

Here the guest address is 172.30.0.5 and the assigned external IP is 10.100.0.11. As we can see the ICMP packet itself had NAT performed showing 68.86.93.241 > 172.30.0.5. However, the copy of the original packet in the ICMP payload shows 10.100.0.11 > 1.1.1.1. This prevents traceroute from working properly.

@rcgoodfellow rcgoodfellow added this to the MVP milestone May 13, 2023
@rcgoodfellow rcgoodfellow modified the milestones: MVP, MVP+1 Jun 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant