Should PNRP UDP port 3540 Inbound Traffic Be Blocked?

WIN 7 x64 SP1, Comodo v5 .1383

First, I don’t use IPv6. That option is turned off in Comodo firewall.

I am seeing a lot of UDP inbound port 3540 activity - see attached TCPView output.

PNRP appears to be a P2P DNS resolution protocol used by IPv6. Since P2P tunnels can bypass any firewall, I feel this inbound UDP port 3540 activity should be blocked. Looking for opinions on this.

[Edit] When surfing with IE8, port 3540 activity is extremely active. Even when a web page has been displayed for sometime, inbound received bytes increases dramatically.

[attachment deleted by admin]

The default state for the PRNP service is manual, which means it will only be started when something invokes the service. Unless you’re actively using IPv6 I’d suggest disabling the service as it’s unnecessary in an IPv4 environment.

As far as tunnelling is concerned, it is true that PRNP can resolve IPv4 addresses over 6to4 and Teredo, so I’d also suggest disabling the tunnelling features of IPv6, which can be easily achieved by copying and pasting the following into a command prompt. This process is reversible:

netsh interface ipv6 set privacy state=disabled
netsh interface ipv6 6to4 set state state=disabled
netsh interface ipv6 isatap set state state=disabled
netsh interface ipv6 set teredo disabled

You can also go further by following the instructions found in this thread. Remember, however, that even disabling IPv6 in this way, you will not stop the apparent listening ports on TCP6/UDP6, as this is a function of the protocol driver tcpip.sys.

Thanks, Radaghast.

I will give your suggestions a try.

I previously implemented the ‘Comodo Firewall IPv6 Gudelines.’ These did not mention disabling IPv6 tunneling interfaces other than Teredo.

Looks like an issue here.

First, PRNP service is not running.

Second, any attempt to block port 3540 UDP inbound activty fails. I have created both a global inbound block rule and a inbound block rule for svchost.exe which is the process that is receiving the inbound port 3540 UDP activity. Neither block rule worked.

I disabled all IPv6 tunneling activity as recommended.

Think I got this figured out.

The PNRP machine service shown in services.msc has nothing to do with udp port 3540 activity from what I can determine. The service that controls this UDP activity is PNRPSvc accessed via Registry only.

I was reviewing the WIN 7 firewall rules in the registry and it showns that UDP port 3540 is allowed for Private network only. In other words, local network activity is allowed. It however is blocked from any other network access.

This is another instance I have to question if Comodo firewall is up to handling WIN 7 IPv6 activity. From my research, WIN 7 uses IPv6 internally therefore disabling it is not recommmended. However, the WIN 7 firewall by default restricts many of the WIN 7 IPv6 processes to Private or local network access only.

Symantec’s NIS 2011 has many system(global) rules that restrict IPv6 processes inbound activity to local network only. I have added those rules to my Comodo global rules. Interestingly this UDP port 3540 inbound activity was not a rule NIS 2011 has in place.

Actually, the service that controls this activity is found in services.msc (see images off and on)

I was reviewing the WIN 7 firewall rules in the registry and it showns that UDP port 3540 is allowed for Private network only. In other words, local network activity is allowed. It however is blocked from any other network access.

The Windows Peer to Peer Collaboration Foundation is only one aspect of PRNP, you also need to take a look at the rules for Remote Assistance PRNP, which supports public and Domain profiles.

This is another instance I have to question if Comodo firewall is up to handling WIN 7 IPv6 activity. From my research, WIN 7 uses IPv6 internally therefore disabling it is not recommmended.

The only aspects of CIS that are currently broken/not working, with regard to IPv6, are ICMPv6 filtering and support for header extensions, everything else works quite well. However, I agree that disabling IPv6 is not particularly recommended, which is why I tend to suggest disabling the tunnelling features, only.

However, the WIN 7 firewall by default restricts many of the WIN 7 IPv6 processes to Private or local network access only.

There are a lot of aspects of IPv6 that only need local access, however, there are just as many that require complete Network/Internet access. It really just depends on your environment.

Symantec's NIS 2011 has many system(global) rules that restrict IPv6 processes inbound activity to local network only. I have added those rules to my Comodo global rules. Interestingly this UDP port 3540 inbound activity was not a rule NIS 2011 has in place.

Simply adding a bunch of global rules from some other firewall, is really not the best of ideas, without at least a basic understanding of the protocol requirements.

[attachment deleted by admin]

Actually, the service that controls this activity is found in services.msc

Yes, I found it listed as Peer Name Resolution Protocol.

Simply adding a bunch of global rules from some other firewall, is really not the best of ideas, without at least a basic understanding of the protocol requirements.

Most of the NIS 2011 rules cover IPv6 stateless UDP inbound non-local network activity. I always code on the side of caution. The NIS 2011 firewall is stateful as is Comodo’s. I assume those rules are there for a reason.

Undoubtedly they are, but just because they’re included in NIS, doesn’t automatically make them useful in Comodo or your environment. As I said, adding rules for the sake of it, without knowing what they do, or why you’re adding them, is not the best practice.