Re: Understanding path MTU discovery

Rick Jones wrote:
David Brown <david.brown@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Can someone confirm or correct my understanding of path MTU
discovery regarding packets passing through a linux router/firewall
to a server on a DMZ? As far as I can tell from my reading, if a
computer on the internet accesses our web server, but the reply from
the server is too big (for example, the client computer is using a
PPPoE link with an MTU of 1492), the client's ISP's gateway router
will send an ICMP package back to our router. The router will see
this as a "related" packet, and pass it on to the web server in the
DMZ, and the web server will use the smaller packet size for the
rest of the connection.

Assuming that there wasn't anything filtering the requisite ICMP
messages in the name of security.


I gather that this is becoming a problem, with many firewalls being set to filter out the relevant ICMP messages "in the name of security". Our current firewall/router (an old ZyWall 10, to be replaced by a linux or possibly bsd box) blocks all ICMP messages, so I've had no choice but to force the server's Ethernet port to use an MTU of 1492 for compatibility with some clients. That works, but is not really ideal. As far as I can see, allowing "related" ICMP packets through should cover the required messages while blocking any other ICMP's.

Will the web server machine remember that lower MTU as being
connected to the client's IP address, so that future connections by
the client will avoid the overhead of the path MTU discovery, or
will the discovery be needed for each new connection? I presume the
lower MTU will not be needed for connections to/from other IP
addresses.

Typically a host route for that client's IP address is created in the
server's routing table. This route has a timer associated with it to
a) reset the PathMTU back to link-local and later b) remove the route
entirely if idle. So, it will be rememebered so long as the new
connections to the same client IP happen within the timeouts.

For the second question, indeed the lower PathMTU will not be used for
connections to/from other IP addresses.


Excellent - thanks for that information.

What will happen if our router has more than one route back to the
client (i.e., two DSL links)? I understand that I could mark
incoming packets from clients so that replies are sent out through
the same interface they came in, but I would prefer to balance the
output packets (downstream ADSL has more than enough bandwidth for
web server requests, but it would be best to take advantage of two
upstream links for replies). Suppose the client's original request
comes in via eth0, gets passed on to the server on eth2, and the
reply happens to go out on eth1 via the other ADSL line. The ICMP
packet complaining about the MTU size is going to be sent back to
the eth1 address - will that still count as "related" and therefore
be passed on to the web server?

On that one I've no idea, other than to say that the ICMP messages
will be send based on the source IP address in the TCP segment which
triggered it, and the source IP (as well as destination IP and the
local/remote port numbers) will be invariant for a connection
regardless of the path it takes.


The source IP will not be invariant for packets coming out of the router towards the internet - such packets will have different SNAT addresses depending on which of the two ADSL lines it passes through (each line has its own Ethernet port on the router, and they have different public IP addresses). I think I'm going to have to read a bit more about exactly how SNAT is implemented and how "related" states are determined, so that I can see what happens here.

Thanks,

David


rick jones
.

Relevant Pages

  • Re: read() returns ETIMEDOUT on steady TCP connection
    ... I'am also meet this problem in my mss server(missey streaming server). ... What is unusual is that this is happening right in the middle of sending a steady stream of data with no network congestion. ... The likelihood of this happening seems to increase as the number of audience connections increases. ... all packets received are delivered to the upper layer. ...
    (freebsd-net)
  • Re: Improving FreeBSD NFS performance (esp. directory updates)
    ... >> I don't think the network is at fault, nor is the server really going ... 155645171 data packets ... discarded for bad header offset fields ... 790 connections established ...
    (freebsd-questions)
  • Re: read() returns ETIMEDOUT on steady TCP connection
    ... I'am also meet this problem in my mss server(missey streaming server). ... What is unusual is that this is happening right in the middle of sending a steady stream of data with no network congestion. ... The likelihood of this happening seems to increase as the number of audience connections increases. ... all packets received are delivered to the upper layer. ...
    (freebsd-net)
  • Re: read() returns ETIMEDOUT on steady TCP connection
    ... I'am also meet this problem in my mss server(missey streaming server). ... I'm are having a trouble with TCP connections being dropped with "read: ... the middle of sending a steady stream of data with no network congestion. ... all packets received are delivered ...
    (freebsd-net)
  • Re: WORM? ... server generating NBT-NS (port 137) traffic on WAN interface
    ... Another possibility is that another computer on the network is channeling through the SBS server since you mentioned a WAN NIC, so I have to assume you are running 2 nics and SBS is tunneling LAN traffic. ... We have to target monitoring on the LAN interface because your router will be logging the packets as coming from SBS. ... they are...SBS does NAT so everything on the WAN side of the link will appear to the router as originating from the SBS server. ...
    (microsoft.public.windows.server.sbs)