Senthil, I ran into problems with the NAT timeout because I had LARGE_NAT defined and that setting enforced a 10 minute timeout on NAT connections when there was no traffic over the NAT mapping in a 10 minute time period. After much discussion on this list, I was able to get a resolution to my problem AND was able to get a better understanding than I had before of how ipnat worked. Here is what I got out of those discussions:
For TCP-based flows that need longer timeouts AND the users/applications that require those timeouts can be qualified (in my case, I had a (1) subnet with a small number of users), I was directed by Darren Reed to use the map-block statement instead of the map statement because: "This uses an algorithm that will result in the same NAT'ing every time, so that if a NAT session times out, a packet sent in the direction that caused the prior NAT mapping to be created will create another one the same (not restricted to SYN flags.) This will not work if the next packet sent comes from the destination of the connection, however. [Darren Reed]". My users were timing out after the 10 minutes of inactivity. Since making the change to map-block, my users have been able to work most of the day without having the session break. I need to note that the timeout in my configuration for the ipfilter rules in 1 hour. So my users can keep their application idle for up to 59 minutes without having to log into the application again due to inactivity. If they use the app once during that 1 hour period, the timer is reset. For non-tcp based flows you can use the age parameter at the end of the map statement. If I understand the age parameter correctly, it was added to that specific non-tcp services that do not need the 10 minute timeout (such as DNS) would time out quicker and not clot up the map table. Before I read the man page correctly and found out that the map statement applied to non-tcp flows AND that it was designed to make mappings timeout before defnatage, I was requesting a change to the age parameter so that I could set the age in the map statement to be greater than defnatage. Again, Darren provided a patch based on the request. The patch is listed at the end of this message. If you go to http://marc.theaimsgroup.com/?l=ipfilter and search for "IPNAT Age vs. IPFILTER Age", you will see the conversation regarding the problem I encountered. Hope this helps. ------------------------------------------------ -jwb Jim Beers Networking Team Leader Moravian College 610-861-1449 Index: ip_nat.c =================================================================== RCS file: /devel/CVS/IP-Filter/ip_nat.c,v retrieving revision 2.37.2.74 diff -c -r2.37.2.74 ip_nat.c *** ip_nat.c 2002/12/06 11:40:21 2.37.2.74 --- ip_nat.c 2003/02/19 12:21:09 *************** *** 2510,2516 **** if (NAT->nat_age < fr_defnaticmpage) NAT->nat_age = fr_defnaticmpage; #ifdef LARGE_NAT ! else if (NAT->nat_age > fr_defnatage) NAT->nat_age = fr_defnatage; #endif /* --- 2510,2517 ---- if (NAT->nat_age < fr_defnaticmpage) NAT->nat_age = fr_defnaticmpage; #ifdef LARGE_NAT ! else if ((!np || !np->in_age[1]) && ! (NAT->nat_age > fr_defnatage)) NAT->nat_age = fr_defnatage; #endif /* *************** *** 2731,2737 **** if (NAT->nat_age < fr_defnaticmpage) NAT->nat_age = fr_defnaticmpage; #ifdef LARGE_NAT ! else if (NAT->nat_age > fr_defnatage) NAT->nat_age = fr_defnatage; #endif /* --- 2732,2739 ---- if (NAT->nat_age < fr_defnaticmpage) NAT->nat_age = fr_defnaticmpage; #ifdef LARGE_NAT ! else if ((!np || !np->in_age[0]) && ! (NAT->nat_age > fr_defnatage)) NAT->nat_age = fr_defnatage; #endif /* -----Original Message----- From: Narayanasamy, Senthil (Exchange) [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 3:02 PM To: [EMAIL PROTECTED] Subject: Question about increasing NAT timeout value. Hi, Is there any way ipnat timeout can be increased dynamically?, I am using ipf version(3.4.14) under Solaris 8. I have tried setting ipf:fr_defnatage in /etc/system, it seems to have no effect on the default timeout value of 10 minutes. Regards, senthil *********************************************************************** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. ***********************************************************************
