As per I posted earlier I would do, I have developed some patches that 
add support for bouncing connections.  I have posted all the changed 
files (against the beta 1.1b8) here:  http://snurkle.net/m0n0/  (the 
tarball, if extracted in the root of the rootfs, replaces all the 
proper files).

Basically, it adds the 'bounce' binary to /sbin, and a new 
configuration script called 'bounce.inc' in /etc/inc.  This script gets 
called from rc.bootup, and it is in charge of either starting all the 
bounce processes, or killing the running ones and starting new ones.

I placed the bounce configuration under the NAT tabs.  It does some 
validation checks to make sure that you do not have more than one 
bounce on the same local port, and it also re-configures bounce on the 
fly (ie, no reboot required).

I also had to modify the 'Inbound nat' to allow the source interface to 
be LAN, so that the bounce rules will work.  This has a bug as the 
display list does not display the interface correctly, but the rule 
gets made correctly.  I'll get this fixed soon.

Other mods include adding a sort function to guiconfig.inc, adding a 
call to the bounce_configure in rc.bootup, adding the 'bounce' XML 
entry to xmlparse.inc,  adding an example XML under the nat section in 
the default config.xml, and adding links from the other nat pages to 
the bounce page, as well as adding a call to reconfigure bounce when 
the nat rules change.

A basic run down of the feature:

Bounce listens on a local port on the m0n0wall box.  It waits to 
'bounce' connections from this local port to a remote box on a possibly 
different port.  It does this by opening a new socket connection to the 
remote box.  This solves the problem of internal machines not being 
able to access services on machines that are also internal via their 
public IP address.  This also works for bridges.  Therefore, the reason 
why you need to be able to apply NAT rules against the LAN interface is 
so that you can 'catch' an internal client trying to goto, say, port 80 
of a local machine on its public IP, redirect it to the port bounce is 
listening on, who then connects back into the right box, making the 
connection not hang :)


Please let me know what you think.  Hopefully this will be a valuable 
addition to m0n0wall, otherwise I will have to maintain this patch 
in-house for my clients :)

Steven Ball
Snurkle Engineering