[nsp] ICMP type 3 code 4 + NAT (Was: ICMP: time exceeded(reassembly))

Vincent De Keyzer vincent at dekeyzer.net
Thu Feb 5 06:51:30 EST 2004


you would have to hope that the ICMP T3C4 has some copy of the originating
packet (like I think it does in the echo reply packet?).

Otherwise, I don't really see how the NAT box could relate the incoming ICMP
packet to outgoing packets of the previously established incoming TCP
session, and send them to the web server.

MTU, ICMP T3C4 and firewalls used to be a pain a few years ago, but that was
with GRE - not sure this relates to your problem?
093f1f.shtml (might require login)


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jason Lixfeld
> Sent: jeudi 5 février 2004 8:58
> To: cisco-nsp at puck.nether.net
> Subject: [nsp] ICMP type 3 code 4 + NAT (Was: ICMP: time 
> exceeded(reassembly))
> A question popped into my head while reading the earlier thread.
> Assuming a web server is addressed via RFC1918 and accesses the 
> internet via NAT.  Client is on some crummy link which 
> requires a lower 
> MTU than the web server, ICMP T3C4 message sent back to the 
> web server 
> (nat box).  How does the ICMP message get back to the web server from 
> the NAT box?  Are there specific NAT hooks for these types of 
> circumstances or are there special NAT provisions that need 
> to be taken 
> into consideration when running services like this behind a NAT box?  
> (Assume NAT box is >= 12.0 IOS box).
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco> -nsp
> archive at 
> http://puck.nether.net/pipermail/cisco-nsp/

More information about the cisco-nsp mailing list