Koozali.org: home of the SME Server

port forward

Offline ReetP

  • *
  • 3,722
  • +5/-0
Re: port forward
« Reply #75 on: July 07, 2015, 03:48:37 PM »
Would it be logical or truthful to suggest adding a toggle switch in the server-manager console that implements an nftables route or masq or iptables script?

or just a philosophically sound suggestion?

Sound but has to be balanced with practicality... :-) I haven't seen people clamouring for this as a feature... !

First we use iptables, not nftables

Next, as the FAQ at Opensim says :

"Many DSL routers/modems prevent loopback connections as a security feature."

So it may be opening you up to other issues. I think personally I'd ask Opensim to change their code, but hey ho.

Finally there is an example script for iptables rules at opensim - DON'T use it on SME as you will break your firewall. This is a guide so you can see the sort of rules that need templating to make it work. And then you need to write a server panel entry for it....

Code: [Select]
#!/bin/bash
#
# vvvvv - Fix these! - vvvvv
IPTABLES=/usr/sbin/iptables
LAN_NETWORK=192.168.0.0/24
SERVER_IP=192.168.0.2
INTERNET_IP=100.100.100.100
REMOTING_PORT=8895
REGION_PORT=9000
# ^^^^^ - Fix these! - ^^^^^
 
# First, the Destination NAT, anything going to the external address on our ports, we redirect to the server
# Note, if you have a double NAT running and this router doesn't actually have the internet IP address, you'll
# need another set of PREROUTING-DNAT lines with the --destination (-d) set to the internet facing private address
$IPTABLES -t nat -I PREROUTING -d $INTERNET_IP -p tcp --dport $REMOTING_PORT --jump DNAT --to-destination $SERVER_IP
$IPTABLES -t nat -I PREROUTING -d $INTERNET_IP -p udp --dport $REGION_PORT --jump DNAT --to-destination $SERVER_IP
$IPTABLES -t nat -I PREROUTING -d $INTERNET_IP -p tcp --dport $REGION_PORT --jump DNAT --to-destination $SERVER_IP
 
# Second, the Source NAT, we need this so that returning packets to our LAN clients go back through the router first,
# otherwise, the server will try to talk directly to the client and the client will reject them
$IPTABLES -t nat -I POSTROUTING -s $LAN_NETWORK -d $SERVER_IP -p tcp --dport $REMOTING_PORT --jump SNAT --to-source $INTERNET_IP
$IPTABLES -t nat -I POSTROUTING -s $LAN_NETWORK -d $SERVER_IP -p udp --dport $REGION_PORT --jump SNAT --to-source $INTERNET_IP
$IPTABLES -t nat -I POSTROUTING -s $LAN_NETWORK -d $SERVER_IP -p tcp --dport $REGION_PORT --jump SNAT --to-source $INTERNET_IP

Sounds like we need Stephane on the job :lol:

Yes, it might be nice to have, but the security implications need to be considered as we don't mess with firewalls lightly. It will also take a bit of coding to implement and we don't have a massive amount of resources to dedicate to a request that seems a bit of a one off.

You are more than welcome add a NFR bug, and to code it yourself ;-)

B. Rgds
John
...
1. Read the Manual
2. Read the Wiki
3. Don't ask for support on Unsupported versions of software
4. I have a job, wife, and kids and do this in my spare time. If you want something fixed, please help.

Bugs are easier than you think: http://wiki.contribs.org/Bugzilla_Help

If you love SME and don't want to lose it, join in: http://wiki.contribs.org/Koozali_Foundation

Offline ReetP

  • *
  • 3,722
  • +5/-0
...
1. Read the Manual
2. Read the Wiki
3. Don't ask for support on Unsupported versions of software
4. I have a job, wife, and kids and do this in my spare time. If you want something fixed, please help.

Bugs are easier than you think: http://wiki.contribs.org/Bugzilla_Help

If you love SME and don't want to lose it, join in: http://wiki.contribs.org/Koozali_Foundation

Offline CharlieBrady

  • *
  • 6,918
  • +3/-0
Re: port forward
« Reply #77 on: July 07, 2015, 04:33:15 PM »
What type of tautology?
https://en.wikipedia.org/wiki/Tautology

I guess I meant 'circular definition'. What does the script do? "NAT loopback". What is "NAT loopback"? It's what the script does.

But we have an independent definition now, and it should like it could be added without breaking anything we have right now, and would be a good addition. But we would need to understand this "security feature" comment before we go there.

Offline CharlieBrady

  • *
  • 6,918
  • +3/-0
Re: port forward
« Reply #78 on: July 07, 2015, 04:34:46 PM »
So it may be opening you up to other issues. I think personally I'd ask Opensim to change their code, but hey ho.

I agree that this is a bug in opensim. It should "just work" - not depend on some obscure feature of a router which is unlikely to be present and working.

Offline Stefano

  • *
  • 10,836
  • +2/-0
Re: port forward
« Reply #79 on: July 07, 2015, 05:02:30 PM »
Quote
"Many DSL routers/modems prevent loopback connections as a security feature."

and that's the way things should work..

Offline Stefano

  • *
  • 10,836
  • +2/-0
Re: port forward
« Reply #80 on: July 07, 2015, 05:19:24 PM »
Quote
Yes, it might be nice to have, but the security implications need to be considered as we don't mess with firewalls lightly. It will also take a bit of coding to implement and we don't have a massive amount of resources to dedicate to a request that seems a bit of a one off.

I think that it should not be a SME's feature.. this is a kinda of customization one user needs to make something work.

security first of all.. one of the first FW rules I learnt was that a firewall have to block any request done from a private IP coming on the public interface..

things should work just playing with dns.. and, for sure, we should not add a feature to bypass sw bugs; this is why we have "templates-custom" tree, templates and fragments..

Offline CharlieBrady

  • *
  • 6,918
  • +3/-0
Re: port forward
« Reply #81 on: July 07, 2015, 07:23:16 PM »
security first of all...

Yes, but we need to understand what the security risk is.

I think I can see what that is here. With port-forwarding as we have now, the destination server always sees the true origin (source IP) of the connection. With 'NAT loopback', systems on the LAN will be able to connect to the destination server either directly, or via the forwarded port (WAN IP of the SME server). But in the latter case, the destination server will not see the real source IP of the connection. They won't be able to log which system on the LAN is connecting, or make access control decisions based on the real source IP.

guest22

Re: port forward
« Reply #82 on: July 07, 2015, 08:02:16 PM »
One case only in over a decade does not sound to me as worth the trouble and security risk.


It does not add anything substantial to SME Server, and I think we better focus on the release of 8.x and 9.x, and the queue of existing bugs and NFR's.

Offline CharlieBrady

  • *
  • 6,918
  • +3/-0
Re: port forward
« Reply #83 on: July 07, 2015, 09:14:14 PM »
One case only in over a decade does not sound to me as worth the trouble and security risk.

It's not really just one case. There have been multiple posts of people saying that port forwarding doesn't work, because when they try to access the forwarded port from inside the LAN it "doesn't work". Those confusions wouldn't have been seen if this feature had been implemented.

I'm just clarifying, not advocating for the feature.

Offline Stefano

  • *
  • 10,836
  • +2/-0
Re: port forward
« Reply #84 on: July 07, 2015, 09:24:34 PM »
Quote
It's not really just one case. There have been multiple posts of people saying that port forwarding doesn't work, because when they try to access the forwarded port from inside the LAN it "doesn't work". Those confusions wouldn't have been seen if this feature had been implemented.

if so, we should improve either the documentatio, the FAQ and (preferably) the server-manager panel

guest22

Re: port forward
« Reply #85 on: July 07, 2015, 10:25:31 PM »
Having/hosting SME servers and services requires a basic understanding of networking. Nothing just 'works' or 'doesn't work'. SME Server will never be a Chrystal sphere.

Maybe sometimes we are victim of our own simplicity and success...