2

I have a router running DD-WRT. In my network I have a NAS device which runs an OpenSSH server. I want to be able to access the OpenSSH server from outside the LAN.

This is accomplished by adding rules to iptables

The router has configured:

  1. OpenVPN client
  2. DDNS

Assumming:

  • <routerIp> the internal router IP

  • <routerPort> the port on router for listening the incoming traffic

  • <nasIP> the internal NAS IP

  • <nasPort> the OpenSSH server port on NAS

Also currently I have <routerPort> == <nasPort>

I have to:

  1. open a port on the router
  2. route the traffic coming to this port to NAS.

The rules that should accomplish this task, but not working, are:

iptables -A FORWARD -i tun1 -p tcp -d <nasIP> --dport <nasPort> -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -d <routerIp> --dport <routerPort> -j DNAT --to-destination <nasIP>:<nasPort>

References:

EDIT according RalfFriedl's answer:

Changed the rules to:

iptables -A FORWARD -i tun1 -p tcp -d <nasIP> --dport <nasPort> -j ACCEPT
iptables -t nat -A PREROUTING -i tun1 -p tcp --dport <nasPort> -j DNAT --to-destination <nasIP>:<nasPort>

but didn't work either

How can I get the external IP?

EDIT output of ip a:

1: lo:  mtu 65536 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: imq0:  mtu 1500 qdisc fq_codel qlen 30
    link/void 
3: imq1:  mtu 16000 qdisc fq_codel qlen 11000
    link/void 
4: eth0:  mtu 1492 qdisc htb qlen 1000
    link/ether dc:ef:09:f2:87:e9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.3/24 brd 192.168.100.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::deef:9ff:fef2:87e9/64 scope link 
       valid_lft forever preferred_lft forever
5: eth1:  mtu 1500 qdisc fq_codel master br0 qlen 1000
    link/ether dc:ef:09:f2:87:e8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::deef:9ff:fef2:87e8/64 scope link 
       valid_lft forever preferred_lft forever
6: teql0:  mtu 1500 qdisc noop qlen 100
    link/void 
19: ip6tnl0@NONE:  mtu 1452 qdisc noop 
    link/tunnel6 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
20: br0:  mtu 1500 qdisc noqueue 
    link/ether dc:ef:09:f2:87:e8 brd ff:ff:ff:ff:ff:ff
    inet 169.254.255.1/16 brd 169.254.255.255 scope global br0:0
       valid_lft forever preferred_lft forever
    inet 192.168.2.1/24 brd 192.168.2.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::deef:9ff:fef2:87e8/64 scope link 
       valid_lft forever preferred_lft forever
21: ath0:  mtu 1500 qdisc noqueue master br0 
    link/ether 0a:b1:2c:d4:5e:f0 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::8b1:2cff:fed4:5ef0/64 scope link 
       valid_lft forever preferred_lft forever
22: ath0.1:  mtu 1500 qdisc noqueue 
    link/ether 08:b1:2c:d4:5e:f0 brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.1/24 brd 172.16.1.255 scope global ath0.1
       valid_lft forever preferred_lft forever
    inet6 fe80::ab1:2cff:fed4:5ef0/64 scope link 
       valid_lft forever preferred_lft forever
23: ath1:  mtu 1500 qdisc noqueue master br0 
    link/ether dc:ef:09:f2:87:eb brd ff:ff:ff:ff:ff:ff
    inet6 fe80::deef:9ff:fef2:87eb/64 scope link 
       valid_lft forever preferred_lft forever
24: tun1:  mtu 1500 qdisc fq_codel qlen 100
    link/[65534] 
    inet 10.128.250.xxx/16 brd 10.128.255.xxx scope global tun1
       valid_lft forever preferred_lft forever
T81
  • 33
  • 6
  • Run `ip a` on the router to see the interfaces and the addresses. Are you sure `tun1` is the correct interface? – RalfFriedl Aug 19 '18 at 12:04
  • @RalfFriedl How do I interpret the output of this command? What exactly is the "correct interface"? – T81 Aug 19 '18 at 12:39
  • The "correct interface" is where the requests come in. As your other answer says, they don't come in at all, so there is no "correct interface". Just append the output to your question. You can hide the end of the addresses if you think they should remain secret. – RalfFriedl Aug 19 '18 at 12:41
  • @RalfFriedl OK. I have a lot of port forwards using `-i tun1` and all work as they should. I think it is the right one. Also added output of `ip a` to post – T81 Aug 19 '18 at 12:54
  • Your `tun1` uses a private address. It is probably a VPN, maybe OpenVPN. You must do something at the VPN server to forward the connection to you. Do you have access to the configuration of the VPN server? – RalfFriedl Aug 19 '18 at 12:57
  • @RalfFriedl OMG! You are right. I totally forgot about that... All my ports are there... Feel so stupid... Let'me check it – T81 Aug 19 '18 at 13:03

2 Answers2

1

Your second rule contains -d <routerIp> but according to your description, is the internal router IP.

Packets from the outside won't arrive at the internal IP. If your external IP is static, you can insert your external IP, otherwise just specify the external interface, which seems to be tun1, otherwise you must also adapt your first rule.

RalfFriedl
  • 3,008
  • 4
  • 12
  • 17
  • please check the above edit. This is what I was supposed to do? – T81 Aug 19 '18 at 11:26
  • That should work. Run `tcpdump -n -iany port ` on your router while you try to connect. Do you see any packets? – RalfFriedl Aug 19 '18 at 12:03
  • `tcpdump -n -iany port returns no packets. Also canyouseeme.org cannot see the port open. I suppose even the first rule is not right. I must accept a connection at on router and not at . Am I right> – T81 Aug 19 '18 at 12:36
  • If no packet arrives at your router, the problem happens earlier. What are your IP addresses, and what is your `tun1`? You said == . – RalfFriedl Aug 19 '18 at 12:39
1

As RalfFriedl correctly pointed out, since I am connecting to a VPN provider, I should login to site and add the port which I want to use under my profile.

After that, the rules are:

iptables -A FORWARD -i tun1 -p tcp -d <nasIP> --dport <nasPort> -j ACCEPT
iptables -t nat -I PREROUTING -i tun1 -p tcp --dport <nasPort> -j DNAT --to-destination <nasIP>

something that I have already done dozens of times in the past...

T81
  • 33
  • 6