Port Triggering (now $400)

[supz]

Introduction

I'm a new pfSense user, having previously used DD-WRT and enjoyed it but was looking for something a bit more stable and with better performance, now I've been using pfSense 2.0-RC3 for a week, and really like it.

One feature I'm missing is DD-WRT's feature called "Port Triggering", which I believe is based on an iptables/netfilter extension.

Problem Statement
In a typical single WAN, single subnet LAN home network, the public IP address is overloaded with many private addresses using a single public address. Historically this has been a challenge to some applications that require outbound client->server connections and then inbound server->client connections, like FTP, SIP, etc.
One example would be IRC, where a client may initiate an outbound connection for example on port 6667, and connect to an IRC server which will then attempt to connect back on the client's IP address to port 113, doing an ident check. This ident check will likely fail, unless port 113 on the WAN side is able to accept inbound connections, either by forwarding to a LAN client, or answered by a server running on the WAN IP address (like widentd).

Solution
Certain router firmwares support a feature titled "Port Triggering", which is a simple function that creates a port forwarding entry towards a host that makes an outgoing connection on a certain port. Abstracting this out to a more generic form, it is:

1. Trigger event is defined
 e.g., when LAN client A establishes NAT'd TCP connection to server B on port X
   Where
   A is a variable and can be any client on the network, or a specified host
   B is a variable and can be potentially any server, or a specified host
   X would be defined by the user input and could be a single port or port range

2. Trigger action is defined
 e.g., create port forwarding rule on WAN to forward port Y to client A
   Where
   Y would be defined by the user input and could be a single port or a port range
   A is the client initiating the connection in the trigger event above

3. Optionally an action event timeout should be defined, to remove the action configuration, so remove the port forwarding

4. When an event matching the trigger event occurs, the action defined by the trigger action is executed. After a timeout defined in the action event timeout occurs, remove that action

Example:
1. client connects to server (192.168.0.10:54023 -> irc.efnet.org:6667)
2. pfSense sees an established connection (3-way handshake has completed) to irc.efnet.org on port 6667
3. Upon connection being established, pfSense matches trigger rule and creates port forward entry from WAN IP:113 to client 192.168.0.10:113
4. At some point in the IRC negotiation process, the server will try to connect to the WAN IP on port 113 and it gets forwarded to the client, who responds with his appropriate ident value
5. After a timeout defined by the user configuration, the port forwarding entry on port 113 should be removed

Other Thoughts

• It may be possible to use the PF logging mechanism for trigger events, so when a log message showing a new connection comes up on port X, then execute some command. I initially thought of implementing something like this just using
    tail -f /var/log/filter.log | grep 6667 | awk 'match($0, 'regex') {system("portforwardrule.sh")}'
  But trying that it quickly became apparent that I am not familiar enough with the inner workings of pfSense, to get it working, but it could be possible
• It would be nice if the framework was dynamic enough to have a nice trigger event/action mechanism in pfSense that could be used for lots of other stuff, but for my purposes, I only care about it being able to handle port triggering, so event rules would be an outgoing TCP connection, event actions would be port forwarding, and you get the bounty
• An obvious flaw in this overall idea is what if two clients make an outbound connection on the trigger port within a short time frame, and sure we could come up with elegant solutions to this, but my choice here would just be for the newest rule to win, so whoever was the last to make the connection on port 6667 is the person who gets port 113 forwarded to them.
• This shouldn't be something extremely resource intensive, and should be capable of running on a device with a 1Ghz i386 processor, 1GB RAM, etc.
• Update: UPnP is great, unfortunately, it requires the clients to support it, and in my case not all clients support UPnP

Form of Delivery
In whatever the latest development branch of pfSense is fine. I'm running the latest nightly snapshots on my router, and I'm quite happy with it. This would be something for the greater good, and would go back into the main pfSense branch.

This is my first bounty on here, and my first post, so hopefully I followed the guidelines appropriately, and my bounty price is adequate for the feature request. I guess I will find out

References
[1] DD-WRT wiki - http://www.dd-wrt.com/wiki/index.php/Port_Forwarding#Triggered_Port_Forwarding

[eri--]

It can be implemented for sure in different ways but it just needs more budget than that :).
At least that is my prediction.

[supz]

Bump

Upping the bounty on this to $400 from me, and I'm hoping that somebody else may be willing to contribute if they need this functionality

[xbipin]

$20 from me too if its not just limited to IRC but applies in general (sorry for the low amount, im a bit broke right now)

[supz]

Bum. Will leave this open for another few weeks, but if no one picks it up, I'll be withdrawing.

Thanks

[xbipin]

im out of this

[serialdie]

$50.00 From my side.