NAT Reflection for UDP
-
hey guys…
please let me know, how much one would have to spend to make this feature working properly?
the workaround with the split-dns is not working, having different servers running on several pcs in the lan.thx´n´greetz,
plex -
Not sure what it might take, but we do already install the NAT redirects and setup the netcat processes to accept the inbound traffic, not sure where it's going astray, but it hasn't ever worked that I'm aware of.
-
For the existing reflection implementation for port forwards, I don't really know for sure what is breaking it for UDP.
You could test the 1:1 NAT reflection to see if that works, as it is possible to implement the same rules for port forwards. For this test, on System: Advanced: Firewall/NAT, enable "Automatically create outbound NAT rules which assist inbound NAT rules that direct traffic back out to the same subnet it originated from." (that really needs a shorter descriptive name to the left…). Create a 1:1 NAT rule on LAN with some IP address for external IP other than your WAN IP or one on your LAN (it can be anything for this test, even just some made up IP, as long as it isn't one of those). You could do a rule for testing your whole LAN or just one IP, just whatever you want to for the test. Try locally accessing your UDP services through the appropriate "external IP" for the server you want to test (depending on how you configured the 1:1 rule) and report back on the results. The 1:1 NAT reflection code can be used for port forwards as well, but the code for using it as such is not there yet. If the test succeeds, that implementation would work for your UDP port forwards if/when completed.
If you want to pay something to get this done, whatever you think would be fair (fair to you or to me) would be fine with me. I'll probably finish it sometime anyway, but I might be more willing to do it sooner rather than later if someone was going to pay something for it, and I'd be more willing to do the work to make a package to retrofit it onto 2.0.1.
-
Sounds nice Erik!!
I would be willing to contribute to that.
-
Something tells me the fix isn't this easy, but it's worth a shot. While researching another problem I noticed that our inetd.conf had the udp entries using nowait, and inet.conf(8) says that dgram servers should always specify wait.
https://github.com/bsdperimeter/pfsense/commit/3a12bcc49b6ae8e7f283149a5f6dd423ce62a05c
Give that fix a try and see if it works for you.
-
Have you considered using socat (http://www.dest-unreach.org/socat/) instead of nc/netcat ?
It seems to work with UDP, according to this post.
-
I looked into socat at some point, and I don't remember why I passed it over. I'd have to look again to remember why.
-
I had used socat successfully for this type of work in the past, but only under Linux.
Based on some googl-ing I did yesterday, it seems to work fine for people under *BSD as well.
-
Something tells me the fix isn't this easy, but it's worth a shot. While researching another problem I noticed that our inetd.conf had the udp entries using nowait, and inet.conf(8) says that dgram servers should always specify wait.
https://github.com/bsdperimeter/pfsense/commit/3a12bcc49b6ae8e7f283149a5f6dd423ce62a05c
Give that fix a try and see if it works for you.
sry for my late reply but suddenly I was snowed under with work. Some days ago I tried your workaround but unfortunately it didn't fix the error. I expect to be finished with my assignment within 4 weeks and after gettiing paid I expect to have some cash making this issue a bit more palatable for you to fix…
-
http://forum.pfsense.org/index.php/topic,50339.0.html
