Hi Greg, On Wed, Sep 25, 2019 at 3:33 PM George Neuner <gneun...@comcast.net> wrote: > > Hi David, > > On 9/25/2019 1:08 AM, David Storrs wrote:
> What you are overlooking is that UDP is a level 4 [end-to-end] protocol, > but you are trying to get level 3 [routing] information. > > Neither UDP nor TCP normally records the path a packet takes - only the > routers themselves know what they do to forward the packet. The path > between 2 machines is never fixed, and it may change abruptly due to > congestion or outage along the way. "traceroute" uses a special > (level 3) IP packet which explicitly commands each router along the way > ... and the end destination as well if the packet gets there ... to send > back a response to the traceroute initiator. The path is discovered > dynamically from the responses. I don't think this is correct. NAPT is defined here: https://www.ietf.org/rfc/rfc3022.txt The relevant section is 4.1 (NB: "TU port" means "TCP or UDP port") -------- start quote 4.1. IP, TCP, UDP and ICMP Header Manipulations In Basic NAT model, the IP header of every packet must be modified. This modification includes IP address (source IP address for outbound packets and destination IP address for inbound packets) and the IP checksum. For TCP ([TCP]) and UDP ([UDP]) sessions, modifications must include update of checksum in the TCP/UDP headers. This is because TCP/UDP checksum also covers a pseudo header which contains the source and destination IP addresses. As an exception, UDP headers with 0 checksum should not be modified. As for ICMP Query packets ([ICMP]), no further changes in ICMP header are required as the checksum in ICMP header does not cover IP addresses. In NAPT model, modifications to IP header are similar to that of Basic NAT. For TCP/UDP sessions, modifications must be extended to include translation of TU port (source TU port for outbound packets and destination TU port for inbound packets) in the TCP/UDP header. ICMP header in ICMP Query packets must also be modified to replace the query ID and ICMP header checksum. Private host query ID must be translated into assigned ID on the outbound and the exact reverse on the inbound. ICMP header checksum must be corrected to account for Query ID translation. -------- end quote The firewall that I'm behind, like most modern NAT instances, is a NAPT instance -- a single external address that maps multiple internal addresses based on a semi-randomly-chosen port assigned when the initial connection is made. As stated above, the differences between the two are: Basic NAT rewrites - IP header -- IP address for source (on outbound) or destination (on inbound) -- IP checksum UDP header: UDP checksum NAPT rewrites: - IP header -- IP address for source (on outbound) or destination (on inbound) -- IP checksum - UDP header: -- UDP checksum -- TU port for source (on outbound) or destination (on inbound) In short, the connection should go like this: local machine (192.168.1.221, port 25891) sends message to <AWS_SERVER_IP>:54545 by way of router (192.168.1.1). At each step the source/destination are: local machine -> router (source: 192.168.1.221:25891 dest: <AWS_SERVER_IP>:54545) router -> AWS-server (s: <ROUTER_IP>:XXXXX <--- arbitrary port number for this session d: <AWS_SERVER_IP>:54545) AWS-server -> router (s: <AWS_SERVER_IP>:54545 d: <ROUTER_IP>:XXXXX) router -> local machine (s: <AWS_SERVER_IP>:54545 d: 192.168.1.221:25891 Did I misunderstand something? If not, then I think that the udp-receive! on the AWS server should return IP address <ROUTER_IP> and port <XXXXX>. This matches when Matt Flatt is seeing, but not what I'm seeing. As yet, I have no explanation, but it's obviously something to do with my specific setup. > > > Hope this helps, > George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKocBySEa-_58_U0Cs2tR%2BMMOG4pwBJqd1Tsd6WLugypQ-g%40mail.gmail.com.
