Change NAT Reflection from INETD to SOCAT
-
I find that INETD in pfsense gets in a state where the system log files there are conflicts: inetd[1323]: 19125/udp: bind: Address already in use
I have tried SOCAT in a simple example to listen for requests on port 8090 and forward it to port 80:
socat TCP-LISTEN:8090,fork TCP:192.168.10.249:80
Obviously we should bind it to local loopback address only and generate a entire config file (see links below).
http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,7/func,view/id,11107/
A benefit is that UDP redirection aslo works:
http://mattryall.net/blog/2011/09/udp-port-forwarding-with-socat
I am willing to put up $50 for this feature to be incorporated into PFSENSE 2.0.1 and beyond.
-
I've seen the port conflicts from inetd once, haven't seen a way to replicate it. That has no relation to an issue with doing it in inetd, it's because at some point something tries to launch inetd when it's already running.
-
I've seen this condition happen when the load balancer kicks in and takes a gateway offline/online.
Wouldn't it be nice to be able to implement a more flexible redirection program that supports UDP and other neat things?
-
YES! 50$ from me!
-
For reference, there is already an open ticket for this in redmine - http://redmine.pfsense.org/issues/2281
If anyone commits this, make sure to update the ticket. (Or put "Ticket #2281" in the commit message) -
Any updates on this?
-
I was looking into this, I found where are the calls to load the config for /usr/bin/nc, but I cannot find in builder tools where the binary is compiled. Is this a part of the kernel build and not a port?
-
nc is included in FreeBSD, so nothing special is needed to ensure it's there.
socat would have to be added to the buildports file and copy list for the appropriate branch/version so it would be built and included.
-
Thanks Jim.
nc is included in FreeBSD, so nothing special is needed to ensure it's there.
socat would have to be added to the buildports file and copy list for the appropriate branch/version so it would be built and included.
-
For testing you can always just "pkg_add -r socat" though. Once the code is ready to be used in pfSense we can work out the pfPorts part, that's easy. The hard part is translating all the NC bits to socat.
-
Estimated time for this and can it be quickened in any way?
-
I'm not sure anyone has actually officially picked up the bounty, I was just offering tips to whoever did.
-
I am thinking about it … there is a lot to be done for this. To be honest with you, I now use split dns (using the forwarder in pfSense) to access the servers by URL or names. This translates the names into local addresses (even on DMZ) and works without issue for me.
-
I am thinking about it … there is a lot to be done for this. To be honest with you, I now use split dns (using the forwarder in pfSense) to access the servers by URL or names. This translates the names into local addresses (even on DMZ) and works without issue for me.
If you use split dns, how do you get around the fact that the external port address is different than the internal port address? For example, I NAT an internal service on port 123 to external 321. The client wants to be able to connect externally (mobile device) and internally when on wifi to port 321. The DNS part I get, how about the port issue?
