Project

General

Profile

Bug #1415

Nat reflection is installing rules with 'Array'

Added by Scott Ullrich about 8 years ago. Updated almost 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
NAT Reflection
Target version:
Start date:
04/05/2011
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.0
Affected Architecture:

Description

This leads to 10K+ nc processes which never go away and at some point will exhaust your firewalls resources.

inetd.conf (8.67 KB) inetd.conf inetd.conf Michele Di Maria, 04/29/2011 01:53 AM

Associated revisions

Revision 7788c76a (diff)
Added by Jim Pingle almost 8 years ago

Don't overwrite the $target variable. Fixes #1415

History

#1 Updated by Scott Ullrich about 8 years ago

  • Target version set to 2.0
  • Affected Version set to 2.0

#2 Updated by Scott Ullrich about 8 years ago

19001 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 Array 25535
19002 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 Array 25535

#3 Updated by Ermal Luçi about 8 years ago

  • Category set to NAT Reflection
  • Status changed from New to Feedback

#4 Updated by Michele Di Maria about 8 years ago

Processes are not spawn anymore but for example nat reflection seems anyway not working properly...
Examples: A nslookup from my lan using the public ip address of my dns does not work, while works from outside the network or using the dmz address of the dns...

#5 Updated by Ermal Luçi about 8 years ago

Can you show the content of /var/etc/inetd.conf?
Also ps -ax | grep inetd

#6 Updated by Michele Di Maria about 8 years ago

Here you are:

$ ps -ax | grep inetd
7108 ?? Ss 0:44.47 /usr/sbin/inetd -wW -R 0 -a 127.0.0.1 /var/etc/inetd.
29059 ?? S 0:00.00 sh -c ps -ax | grep inetd
29617 ?? S 0:00.00 grep inetd
50388 ?? I 0:00.00 inetd: wrapping (inetd)
50679 ?? S 0:00.00 inetd: wrapping (inetd)
50923 ?? I 0:00.00 inetd: wrapping (inetd)
50988 ?? I 0:00.00 inetd: wrapping (inetd)
56223 ?? I 0:00.00 inetd: wrapping (inetd)
56497 ?? I 0:00.00 inetd: wrapping (inetd)

and attached is the inetd.conf file...

Thanks!
Michele

#7 Updated by Michele Di Maria about 8 years ago

The problem looks still there when rules are applied to "port alias" with multiple entries...
The first entry of the port alias is correctly applied, while the following ports are still created as array... below an example from inetd.conf:

19084 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 10.0.3.11 137
19084 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 10.0.3.11 137
19085 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 Array 138
19085 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 Array 138
19086 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 Array 139
19086 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 Array 139
19087 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 Array 445
19087 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 Array 445
19088 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 Array 135
19088 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 Array 135

Thanks,
Michele

#8 Updated by Chris Buechler about 8 years ago

  • Status changed from Feedback to New

#9 Updated by Jim Pingle almost 8 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#10 Updated by Michele Di Maria almost 8 years ago

Hello,
I confirm that rules are not defined with "array" even in the case of "port alias" described above.
Anyway, this does not solve the problem of nat reflection on udp protocol. The conseguence in my production environment is about the two dns that are both behind pfSense, and they are unable to communicate and "notify" changes that occurs in the zones... I don't know if I should open this as a separate bug or it's just not impossible to solve...

Thanks,
Michele

#11 Updated by Jim Pingle almost 8 years ago

Try switching to manual outbound NAT if you haven't already, and then add an outbound NAT rule on the LAN with a source of 127.0.0.0/8 that translates to the interface address. Add one for every internal-facing interface. That may bring UDP reflection to life. (I had thought of that yesterday but had not tested it yet).

#12 Updated by Michele Di Maria almost 8 years ago

Dear Jim,
I tried, but it didn't work anyway... btw, I think this specific issue can be closed since is resolved, maybe it's better to open a new issue (starting from this one: http://redmine.pfsense.org/issues/1380 even if the problem of the processes is now solved)

Thanks a lot!
Michele

#13 Updated by Jim Pingle almost 8 years ago

  • Status changed from Feedback to Resolved

OK, I'm closing this out. That other bug isn't right either, it's really just this problem too.

Start a new ticket for that, but I'm not sure I'd get my hopes up. UDP reflection hasn't worked at all that I've ever seen, even on 1.2.3.

Also available in: Atom PDF