miniupnp.tuxfamily.org Forum Index miniupnp.tuxfamily.org
The forum about miniupnp and libnatpmp
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

netfilter: detect if port is forwarded already

 
Post new topic   Reply to topic    miniupnp.tuxfamily.org Forum Index -> miniupnpd Feature Request
View previous topic :: View next topic  
Author Message
nerdpunk



Joined: 26 Oct 2007
Posts: 1

PostPosted: Fri Oct 26, 2007 6:27 pm    Post subject: netfilter: detect if port is forwarded already Reply with quote

if you have some spare time... (maybe you're doing this already - i didn't understand all of your code yet... i was hacking some iptc stuff once, but i guess i didn't know what i we're doing ;)... maybe you could go through all rules in the nat table and try to detect if the desired port is already forwarded? because i have at least one chain which is overriding the MINIUPNPD chain with some "static" DNAT rules

and in case a port forwarding is denied, what does the client (let's say msn or skype on win-XP) do? retry with another port or do nothing?

ok, keep up that good work, thx!
Back to top
View user's profile Send private message
miniupnp
Site Admin


Joined: 14 Apr 2007
Posts: 1442

PostPosted: Fri Oct 26, 2007 11:55 pm    Post subject: Re: netfilter: detect if port is forwarded already Reply with quote

nerdpunk wrote:
if you have some spare time... (maybe you're doing this already - i didn't understand all of your code yet... i was hacking some iptc stuff once, but i guess i didn't know what i we're doing Wink... maybe you could go through all rules in the nat table and try to detect if the desired port is already forwarded? because i have at least one chain which is overriding the MINIUPNPD chain with some "static" DNAT rules

Miniupnpc doesn't go through all nat rules. It would be very difficult to handle all possibilities depending on the configuration of all chains...
The right thing to do is to play with allow and deny commands into miniupnpd.conf in order to limit problems. You can easily "deny" the forwarding of ports forwarded elsewhere.
nerdpunk wrote:

and in case a port forwarding is denied, what does the client (let's say msn or skype on win-XP) do? retry with another port or do nothing?

I'm not sure the UPnP IGD specification says something about that. Some clients will just fail Sad I'm pretty sure MSN does several try (with different ports) before doing so Smile
In my opinion, NAT-PMP is better designed, if the public port is not available, another one is allocated. I'm currently working on it, I discovered that many P2P are supporting it.

Thanks for your remarks !
_________________
Main miniUPnP author.
http://miniupnp.tuxfamily.org/
Back to top
View user's profile Send private message Visit poster's website
dkerr



Joined: 05 Jul 2012
Posts: 4
Location: CT

PostPosted: Thu Jul 05, 2012 9:00 pm    Post subject: Reply with quote

Found this old post because I've come across very similar problem. Miniupnpd is allocating an external port that is already in use. For example if you have an IP Sec VPN server on the gateway, then it is listening on port 4500. If you run back-to-my-mac on an internal system then it requests port 4500 on its NAT-PMP request.

Miniupnpd should not assign this, it should increment the external port to 4501 and try that. This should be simple enough to implement... if the port forward request is not already in the MINIUPNPD chain, then before adding it check to see whether there is already a listen or active connection on the external interface for the requested port. If there is, then increment the port number and try again.
Back to top
View user's profile Send private message
dkerr



Joined: 05 Jul 2012
Posts: 4
Location: CT

PostPosted: Sat Jul 07, 2012 1:26 pm    Post subject: Reply with quote

Okay, I have implemented a patch for miniupnpd that will detect both that a port is already open and in use on the gateway system and also if a pre-existing nat forward request has been manually configured for the requested external port. This is for linux / IPv4 and netfilter/ipchains only. I have some tidying up to do then I will upload a patch.

DAK
Back to top
View user's profile Send private message
dkerr



Joined: 05 Jul 2012
Posts: 4
Location: CT

PostPosted: Sat Jul 07, 2012 10:58 pm    Post subject: Reply with quote

This link will take you to the patch I created to test for a port in use...

http://astlinux.svn.sourceforge.net/viewvc/astlinux/branches/1.0/package/miniupnpd/miniupnpd-portinuse.patch

David
Back to top
View user's profile Send private message
miniupnp
Site Admin


Joined: 14 Apr 2007
Posts: 1442

PostPosted: Tue Jul 10, 2012 1:19 pm    Post subject: Reply with quote

dkerr wrote:
Found this old post because I've come across very similar problem. Miniupnpd is allocating an external port that is already in use. For example if you have an IP Sec VPN server on the gateway, then it is listening on port 4500. If you run back-to-my-mac on an internal system then it requests port 4500 on its NAT-PMP request.

Miniupnpd should not assign this, it should increment the external port to 4501 and try that. This should be simple enough to implement... if the port forward request is not already in the MINIUPNPD chain, then before adding it check to see whether there is already a listen or active connection on the external interface for the requested port. If there is, then increment the port number and try again.

BTW, Why don't you try to add
Code:
deny 4500 0.0.0.0/0 1-65535

at the top of your permission list in miniupnpd.conf ?
_________________
Main miniUPnP author.
http://miniupnp.tuxfamily.org/
Back to top
View user's profile Send private message Visit poster's website
dkerr



Joined: 05 Jul 2012
Posts: 4
Location: CT

PostPosted: Tue Jul 10, 2012 1:30 pm    Post subject: Reply with quote

miniupnp wrote:

BTW, Why don't you try to add
Code:
deny 4500 0.0.0.0/0 1-65535

at the top of your permission list in miniupnpd.conf ?


Doesn't work. Miniupnpd returns a error defined as...
2 - Not Authorized/Refused (e.g. box supports mapping, but user has turned feature off)
The client does not reattempt with an alternative port.

Irrespective of that, requiring listing all the possible ports-in-use in the .conf file is not an ideal solution. Yes you could do this for each port forward you manually set up, but not for ports that may be setup by services running on the gateway.

Further the ietf nat-pmp specification states
"The client normally requests the public port matching the private port. If that public port is not available, the NAT gateway MUST return a public port that is available or return an error code if no ports are available."

So an error code implies nothing available, not that the client should reattempt with a different port.

DAK
Back to top
View user's profile Send private message
miniupnp
Site Admin


Joined: 14 Apr 2007
Posts: 1442

PostPosted: Thu Aug 30, 2012 10:03 am    Post subject: Reply with quote

dkerr wrote:
This link will take you to the patch I created to test for a port in use...

http://astlinux.svn.sourceforge.net/viewvc/astlinux/branches/1.0/package/miniupnpd/miniupnpd-portinuse.patch

David

I created a branch on github for this patch :
https://github.com/miniupnp/miniupnp/tree/portinuse
_________________
Main miniUPnP author.
http://miniupnp.tuxfamily.org/
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    miniupnp.tuxfamily.org Forum Index -> miniupnpd Feature Request All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP
© 2007 Thomas Bernard, author of MiniUPNP.