On Mon, 2004-10-25 at 16:21, Stewart Nelson wrote: > > I have found different NAT routers respond differently. For instance, > > using a standard Linksys NAT router and a Netgear FVS 318 router (has > > VPN support) produced different results. Systems connecting from the > > LAN using the public IP address on the Linksys router would have their > > packets redirected to the LAN retaining their local IP address as the > > source. > > This is typical (incorrect) behavior, but IMO you also have a bug in > the originating host's TCP stack if it works at all. > Let's say host A (192.168.0.2) starts a TCP connection from its > port 1025 to 1.2.3.4 port 22. The router sends the SYN packet to > host B (192.168.0.3) port 22, leaving the source IP address > unchanged. Now, host B must send the ACK directly back to A; it > has no information to do anything else. The router is not in the > path of the reply, and cannot affect it. When A receives the ACK, > it will have a source address of 192.168.0.3 -- that's not > the address it sent the SYN to, so the packet should be ignored, > or answered with a RST. If the TCP connection gets opened, there > is something wrong with host A. > I agree with you on how this has to work. Based on the ethereal traces I ran that is what is happening. Originally had the linksys in place which was working just fine. Replaced it with the netgear and found SMTP failing. Ran ethereal to sort out what it was doing. > > The Netgear router would actually translate the source address > > to the public IP address. > > That's how it should work. > > This had some interesting implications for > > SMTP and relaying for LAN based clients that were configured such that > > the used the public IP address of the SMTP server. > > IMO, you should only do that if the NAT has a static public IP. > Otherwise, your outgoing mails will often be rejected by servers > that won't accept mail sent directly from dynamic addresses. If you > do have a static address, it is easy to configure the SMTP server > so that relays from the NAT's public address are trusted. > Yes, have a static public IP address. This was a company location they switched from a DSL connection to a cable modem setup. Initially they were using the linksys and swapped it out for the netgear since they wanted to setup some VPN connections. Reconfigured sendmail to do just that. :) > > > IMO, there is only one correct way -- the router must set up the > usual dynamic association for the outbound leg, and use its static > (forwarding) association for the inbound leg. Both hosts will see > the public IP as the source address of packets that they receive. > I kind of like the netgear a little better than the linksys due to the logging features. But most of the other features are similar IMHO. Now that I know they treat such connections differently I know just where to look next time. :) I meant to go look up IP redirects to see what the rules are for that. Seems that it is permitted for a device to tell the initiator a different path for the connection being requested, but it has been some time since I worked with Cisco routers that supported that. Not sure if that is what the linksys was doing or not. The netgear did not do that in any case. > > As to why a NAT router would cause a slow down for ssh I don't know. > > With the various linksys and netgear devices I have used I have not seen > > a slow down in connectivity when using ssh, and I use ssh extensively > > both locally and remotely. > > I don't either. It would be interesting if Ben would run Ethereal on > his systems and see what the router is doing to his packets. > > --Stewart -- Scot L. Harris webid@xxxxxxxxxx Trap full -- please empty.
