Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Firewalls
[Top] [All Lists]

NAT vs PMTUd

Subject: NAT vs PMTUd
Date: Tue, 15 Feb 2005 16:18:54 -0800
Greetings list,

We're troubleshooting an issue in which a client TCP connection is
initiated which passes through a firewall NAT, then into a router to
which a GRE tunnel is connected. The MTU of the tunnel connection is
smaller than that used by the client, so the router generates an ICMP
error type 3 code 4 (frag req'd and DF set), which encapsulates the IP
and TCP headers of the generating packet. But when that ICMP packet is
received at the client, it's ignored, and the client continues resending
at a too-large MTU until the connection attempt times out. The headers
encapsulated in the ICMP message include the client's NAT IP as the
source IP address, not its native IP. I suspect that the client
therefore ignores the ICMP message. 

Is it a common option on firewalls to re-write encapsulated headers to
avoid this sort of thing? How is this handled correctly? We've worked
around it by setting the client's MTU smaller, but we'd prefer to use
path MTU discovery and keep default MTU settings.

Any insights are greatly appreciated.

Dan Lynch, CISSP
County of Placer
Auburn, CA


<Prev in Thread] Current Thread [Next in Thread>