T-mobile gateway, ASUS Merlin, trust.zone, OpenVPN, - need to get RDP forwarded!

[RRands]

I am switching to T-Mobile home internet, and have run into a snag. I previously had used port forwarding on the router to publish RDP onto the internet on a non-standard port (let’s call it 1234). So, if you hit <mypublicip:1234>, a port forwarding rule would route that to 192.168.1.2:3389. Worked great!

However, the T-Mobile gateway device (a rebranded Nokia) does not allow for port forwarding (or almost any config), so I have the following config:

inet <-> t-mo gw <-> ASUS (now double natted) <-> RDP PC
Public IP 192.168.12.1 192.168.1.1. 192.168.1.2

i have vpn service through trust.zone, and they offer a static IP with port forwarding (for an additional fee, of course… , so I am testing with that. It gives me a static public IP, and I now have the OpenVPN client on the ASUS merlin router set up to use it, and that seems to work fine for outbound internet traffic.

my challenge is how to configure OpenVPN to forward publicIP:1234 on to internalIP:3389. It does not seem to honor the GUI rules for port forwarding (in reading, it looks like I need to set those up for TUN instead of WAN, but other than understanding that these are different interfaces, this is a bit beyond me).

does anyone have a pointer or info on where/how to set this up?

thank you for any help, I appreciate it! (Also, not looking for reasons why publishing RDP on the internet is risky - I get that….

 

[eibgrad]

If you're using OEM/stock firmware, that could make things difficult. Just depends on how that firmware handles port forwarding. It may very well be limited to the WAN. However, in the case of Merlin, iirc, the port forwarding GUI should work regardless whether it's the WAN or VPN (I don't think it was intentional, but seems to just work that way). But even if that wasn't the case, at least you could add the appropriate firewall rules to implement port forwarding over the VPN. But if you're stuck on OEM/stock firmware, I don't know what to tell you.

 

[eibgrad]

P.S. I suppose using the DMZ is another possibility. It's essentially port forwarding, but it's unconditional. *Everything* that's not otherwise port forwarded in the GUI is sent to the IP in the DMZ, so that device would have to have a strong firewall to filter out bogus/unwanted remote access attempts. But I suspect if the OEM/stock firmware is only working w/ the WAN, the same will be true of the DMZ. Again, using Merlin, this isn't the case.

 

[RRands]

Hi, @eibgrad - thank you for the reply - I am running the Merlin firmware (I listed that in the thread’s title, though I realize I used it interchangeable with ASUS in the body…). And while I have the rules in the GUI under port forwarding (forward externalIP:1234 to internalIP:3389) set up, it does not appear to be working. In reading, it looks like maybe the Merlin GUI only forwards traffic inbound from the WAN interface, not the TUN interface, but I am not 100% on that, nor do I know how to create a rule outside of that, if true. Make sense?

 

[RRands]

P.S. I suppose using the DMZ is another possibility. It's essentially port forwarding, but it's unconditional. *Everything* that's not otherwise port forwarded in the GUI is sent to the IP in the DMZ, so that device would have to have a strong firewall to filter out bogus/unwanted remote access attempts. But I suspect if the OEM/stock firmware is only working w/ the WAN, the same will be true of the DMZ. Again, using Merlin, this isn't the case.

Also - note that my ASUS Merlin router is sitting behind the Nokia Gateway device, so I am double natted. I don’t think DMZ will get me much in that instance, as the T-Mo’s nat is filtering ahead of that. This is the reason I have the VPN client on the ASUS Merlin - it essentially punches through the T-Mo gateway and has a public IP on the other end that supports port forwarding directly back to it.

 

[eibgrad]

Sorry about the mixup. I didn't even notice the reference to Merlin in the title, esp. once I became fixated on the post itself. You're probably better off to use the Merlin forum anytime you're using Merlin, rather than this forum, even for VPN issues. I always assume it's NOT Merlin when placed in this forum.

I was only *looking* at the port forwarding rules, and as I said, it doesn't appear to be qualified by the WAN network interface. So I was guessing it might work even for the VPN. Regardless, you should be able to port forward over the VPN using VPN specific rules.

Forwarding an incoming port from OpenVPN to a local LAN IP

Hi! I have a possibly trivial scenario, which, after searching and reading some vaguely related threads would probably be solvable with iptables and some jffs scripts, but I found nothing that would cover my scenario: 1. I have a VPN service provider, where I configure portforwarding of port...

www.snbforums.com

 

[eibgrad]

FWIW, I got curious and started to investigate Trust.Zone's support for port forwarding. I was hoping to test it w/ the free 3-day account, but it seems you need the static IP option, which is apparently NOT available on the free account. I was particularly curious if I could get port forwarding working via the GUI.

All those VPN providers that do support port forwarding (which is a minority) seem to do so a bit differently, so I make it habit to check out the differences. I found the following webpage on their website.

Trust.Zone VPN Port Forwarding is Now Available with a Huge Discount - Trust.Zone

Trust.Zone VPN Port Forwarding is Now Available with a huge discount. Why do you need dedicated IP and port forwarding with Trust.Zone? To allow remote...

trust.zone

If I'm reading it correctly, it appears they do NOT firewall ports 5000-65535, but leave them wide open by default! Only other time I can recall this being the case is w/ PureVPN, and that was years ago. They've long since stopped that bad practice. Most providers keep the ports closed by default, then force you to use their website to explicitly open the ports that interest you. Obviously that's much safer. But because of providers like Trust.Zone, it's critical you maintain the Inbound Firewall on the OpenVPN client, and use port forwarding as necessary for accessing specific devices and ports.

 

[RRands]

Sorry about the mixup. I didn't even notice the reference to Merlin in the title, esp. once I became fixated on the post itself. You're probably better off to use the Merlin forum anytime you're using Merlin, rather than this forum, even for VPN issues. I always assume it's NOT Merlin when placed in this forum.

I was only *looking* at the port forwarding rules, and as I said, it doesn't appear to be qualified by the WAN network interface. So I was guessing it might work even for the VPN. Regardless, you should be able to port forward over the VPN using VPN specific rules.

Forwarding an incoming port from OpenVPN to a local LAN IP

Hi! I have a possibly trivial scenario, which, after searching and reading some vaguely related threads would probably be solvable with iptables and some jffs scripts, but I found nothing that would cover my scenario: 1. I have a VPN service provider, where I configure portforwarding of port...

www.snbforums.com

OK - this script looks like what I am after - couple of questions / issues, though, if I may? (and I really appreciate your help - thank you!!)

I ran the script, replacing the ports and IP's with the ones I needed, however I need TCP and UDP for my setup - is there a way to do that?
Secondly, I have 3 of these that I want to set up (so 3 different external ports forwarding to 3 different internal machines on 3 separate PrivateIP:3389 - how would I put those into the script?

Lastly, a challenge - I ran the script, and then attempted to connect via the public IP/Port - it got farther than it had before (all the way to securing connection), but then would not finish - I *think* that is because I also need UDP, but not 100% sure there... If you can answer #1 above, I can give it a try...
BUT... after I tried it once, I went back to a different machine (not the one I am trying to RDP in to), and it is "connected" wirelessly, and gets an IP, and I can connect to internal resources, however I can't get out to the internet via IP now (interestingly, ping will get DNS resolution, but times out at each hop now...) To "undo" the script, is it just a matter of deleting the nat-start file? (I can't decipher the script, but it looks like every time the router re-boots it's modding the IPTables maybe?) That might get me back to functioning until we can run this down a bit more...

Thank you - if there are any logs/info/whatever I can provide to help, happy to do that!


-randy

UPDATE: I deleted the nat-start file, and now my internal wireless machine is working as expected again, so that's something - going to go try and create it again just in case I fat-fingered something that caused the error...
UPDATE2: re-ran the script - did find that there is a small error in it, but I don't think it affects it running, as the DIR it is attempting to create is already there:
mkdir -p $SCRIPT_DIR
Should be: mkdir -p $SCRIPTS_DIR (note the S at the end of SCRIPTS)

But, after running it, my internal wireless machines no longer can reach the internet. Hopefully it's just a syntax error or something on the IPT command?


Thank you again - looking forward to your reply!

-randy

 

[eibgrad]

Thanks for catching the syntax error.

As long as you know where each parameter goes and its purpose (interface, protocol, external-port, etc.), you can just create each port forward directly, one after the other w/ the necessary substitutions.

SCRIPTS_DIR='/jffs/scripts'
SCRIPT="$SCRIPTS_DIR/nat-start"

mkdir -p $SCRIPTS_DIR

cat << "EOF" > $SCRIPT
#!/bin/sh

iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 5000 -j DNAT --to 192.168.1.100:3389
iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.100 --dport 3389 -j ACCEPT

iptables -t nat -I PREROUTING -i tun11 -p udp --dport 5000 -j DNAT --to 192.168.1.100:3389
iptables -I FORWARD -i tun11 -p udp -d 192.168.1.100 --dport 3389 -j ACCEPT

iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 5100 -j DNAT --to 192.168.1.200:22
iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.200 --dport 22 -j ACCEPT
EOF
chmod +x $SCRIPT
:

The nat rule redirects (DNAT's) the external port on the VPN into an internal IP+port, while the forward rule allows the routing from the VPN to that same internal IP+port.

One other thing to keep in mind. Any device that's being made remotely accessible via the VPN must itself be bound to that same VPN via the OpenVPN client. Just as you can't remotely access over the WAN while bound to the VPN, you can't remotely access over the VPN while bound to the WAN. For *all* traffic on any given LAN ip, the inbound and outbound network interfaces *must* be the same!

If problems persist, perhaps enumerate specifically what you want in terms of internet and external ports, protocols, etc., so I can precisely define the necessary rules.

P.S. You should always check those rules actually got added, and as you expected them, by dumping the relevant tables.

iptables -t nat -vnL PREROUTING
iptables -vnL FORWARD

It's easy to make a syntax error w/ this kind of stuff, so worth double-checking.

 

[eibgrad]

FYI. For posterity's sake, I decided to formalize the script, making it more robust and comprehensive. And a little easier to configure.

merlin-ovpn-port-forward.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

It's probably overkill for a single rule, but this is the first time I can recall someone requesting multiple rules, and my original script didn't scale very well. So this is my attempt to address that issue.

Improvements include:

- you can create multiple rules in the PORT_FORWARDS variable, one per line
- you can now port forward to the router itself by specifying its LAN ip for the internal IP
- you can include a source IP or network w/ any port forward to limit access (if it doesn't matter to you, specify 0.0.0.0/0)
- you can add comments, and comment out any port forward w/ a # sign; anything after the last parameter (internal-port) is treated as a comment as well

I suppose *technically* the INPUT and FORWARD rules should be part of the firewall-start script. But so far, it appears to function correctly as part of the nat-start script. I tried to minimize the impact by creating only the two rules that check for a DNAT state rather than creating rules for each and every port forward.

One last point. I stated previously that when using VPN port forwarding, any device that is the target of that port forwarding must be bound to the VPN. Just to be precise, that *assumes* the OpenVPN provider is NOT masking the public IP of the remote user who's using the port forward. But I suppose it's possible the OpenVPN provider *might* NAT the inbound traffic so it always appears to be coming from the OpenVPN server itself (e.g., 10.8.0.1). And in that case, the target of the remote access over the VPN would NOT need to be bound to the VPN, since that IP is KNOWN to be accessible over the VPN.

That's why this stuff can be a bit tricky. As I said, every OpenVPN provider offering port forwarding has their own take on the matter, and could configure things differently from other providers. And since I have no access to Trust.Zone for testing, I don't know w/ 100% accuracy how they've implemented it. I'm just assuming the target of the port forward will see the public IP of the client, just as when remote access is provided over the WAN. YOU will ultimately have to make that determination.

 

[RRands]

Thanks for catching the syntax error.

As long as you know where each parameter goes and its purpose (interface, protocol, external-port, etc.), you can just create each port forward directly, one after the other w/ the necessary substitutions.

SCRIPTS_DIR='/jffs/scripts'
SCRIPT="$SCRIPTS_DIR/nat-start"

mkdir -p $SCRIPTS_DIR

cat << "EOF" > $SCRIPT
#!/bin/sh

iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 5000 -j DNAT --to 192.168.1.100:3389
iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.100 --dport 3389 -j ACCEPT

iptables -t nat -I PREROUTING -i tun11 -p udp --dport 5000 -j DNAT --to 192.168.1.100:3389
iptables -I FORWARD -i tun11 -p udp -d 192.168.1.100 --dport 3389 -j ACCEPT

iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 5100 -j DNAT --to 192.168.1.200:22
iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.200 --dport 22 -j ACCEPT
EOF
chmod +x $SCRIPT
:

The nat rule redirects (DNAT's) the external port on the VPN into an internal IP+port, while the forward rule allows the routing from the VPN to that same internal IP+port.

One other thing to keep in mind. Any device that's being made remotely accessible via the VPN must itself be bound to that same VPN via the OpenVPN client. Just as you can't remotely access over the WAN while bound to the VPN, you can't remotely access over the VPN while bound to the WAN. For *all* traffic on any given LAN ip, the inbound and outbound network interfaces *must* be the same!

If problems persist, perhaps enumerate specifically what you want in terms of internet and external ports, protocols, etc., so I can precisely define the necessary rules.

P.S. You should always check those rules actually got added, and as you expected them, by dumping the relevant tables.

iptables -t nat -vnL PREROUTING
iptables -vnL FORWARD

It's easy to make a syntax error w/ this kind of stuff, so worth double-checking.

@eibgrad - thank you so much for the help so far and for the detailed explanation - it really helps!

I have (hopefully) one remaining issue. If I just cut and paste the iptables commands in manually (-vs the script putting them into the nat-start file), they work just fine and everything is ok. However, when I run the script above, let it create the file & then re-boot the router, while the machines I want to connect via the VPN work fine, all the other devices on my network no longer have internet access. (interestingly, DNS seems to work, as a ping will resolve the IP, but fail to ping, and this does work if I just cut/paste the commands manually.

any idea what might be happening? Is there something in the IPTables that the nat-start is overwriting when executed that way that is not being done when I just put the individual lines in via the CLI?


Thank you again - sorry for the delay - I was away for a bit & couldn't work on it.

-randy

 

[eibgrad]

while the machines I want to connect via the VPN work fine, all the other devices on my network no longer have internet access.

I couldn't even venture a guess. Best I can suggest is to dump the relevant data structures for each of the two different scenarios so I can compare them and perhaps gain a clue. Sometimes simply seeing the bigger picture helps.

ifconfig
ip route
ip route show table ovpnc1
ip route show table ovpnc2
ip route show table ovpnc3
ip route show table ovpnc4
ip route show table ovpnc5
ip rule
iptables -t nat -vnL
iptables -vnL INPUT
iptables -vnL FORWARD

 

[eibgrad]

Just a guess at this point.

Technically (and it's always been something I'm aware of), nat rules belong in the nat-start script, and forward rules belong in the firewall-start script. Why it works this way is beyond me. But in the past I've been able to get away w/ keeping them together in the nat-start script, if only for reasons of simplicity. But perhaps there are circumstances where it's NOT going to work. So try separating the rules into the two scripts and see it makes a difference.

SCRIPTS_DIR='/jffs/scripts'

mkdir -p $SCRIPTS_DIR

SCRIPT="$SCRIPTS_DIR/nat-start"

cat << "EOF" > $SCRIPT
#!/bin/sh
iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 5000 -j DNAT --to 192.168.1.100:3389
iptables -t nat -I PREROUTING -i tun11 -p udp --dport 5000 -j DNAT --to 192.168.1.100:3389
iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 5100 -j DNAT --to 192.168.1.200:22
EOF
chmod +x $SCRIPT

SCRIPT="$SCRIPTS_DIR/firewall-start"

cat << "EOF" > $SCRIPT
#!/bin/sh
iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.100 --dport 3389 -j ACCEPT
iptables -I FORWARD -i tun11 -p udp -d 192.168.1.100 --dport 3389 -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.200 --dport 22 -j ACCEPT
EOF
chmod +x $SCRIPT
:

 

[RRands]

I couldn't even venture a guess. Best I can suggest is to dump the relevant data structures for each of the two different scenarios so I can compare them and perhaps gain a clue. Sometimes simply seeing the bigger picture helps.

ifconfig
ip route
ip route show table ovpnc1
ip route show table ovpnc2
ip route show table ovpnc3
ip route show table ovpnc4
ip route show table ovpnc5
ip rule
iptables -t nat -vnL
iptables -vnL INPUT
iptables -vnL FORWARD

Ok - here you go - there is a lot of data here, so I put it into two text files. If I should put it in a different format or post it somewhere else, please let me know, OK? I changed my public IP address to X.X.X.X in these results, just FYI... Also, I think the VSERVER section is actually from the Merlin GUI's Port Forwarding setup, as it has an entry for Minecraft that I didn't do in the VPN yet.

 

[eibgrad]

Yep, I see the problem already, as I suspected. When NOT working, the FORWARD chain is messed up. It's missing rules, the most important being the one that allows forwarding from the private network (br0) to other network interfaces, specifically the WAN.

Chain FORWARD (policy DROP 943 packets, 98998 bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  tun11  *       0.0.0.0/0            192.168.1.12         udp dpt:3389
    0     0 ACCEPT     tcp  --  tun11  *       0.0.0.0/0            192.168.1.12         tcp dpt:3389
    0     0 ACCEPT     udp  --  tun11  *       0.0.0.0/0            192.168.1.10         udp dpt:3389
    0     0 ACCEPT     tcp  --  tun11  *       0.0.0.0/0            192.168.1.10         tcp dpt:3389
    0     0 ACCEPT     udp  --  tun11  *       0.0.0.0/0            192.168.1.5          udp dpt:3389
    0     0 ACCEPT     tcp  --  tun11  *       0.0.0.0/0            192.168.1.5          tcp dpt:3389
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  lo     lo      0.0.0.0/0            0.0.0.0/0

What I suspect is that having specified *multiple* forward rules from the nat-start script caused the corruption. As I said, normally I've only had users who needed *one* rule, and that worked when you combined nat and forward rules in the nat-start script. But for whatever reason, things go haywire w/ multiple rules. Even my new port forwarding script doesn't have this problem, which is probably explained by the fact it's only adding *one* forward rule from the nat-script.

This practice of placing forward rules in the nat-start script is probably just not a safe practice, even if it works *some* times.

 

[eibgrad]

P.S. It's possible you don't even need the FORWARD rules. I've noticed there's the following rule in the FORWARD chain (at least when it's NOT corrupted) that *should* allow the forwarding based on the fact the packets have been DNAT'd by the nat rule.

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination     
...
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
...

Notice it's NOT specific to any network interface, source, or destination.

If you need to access the router, which means adding rules to the INPUT chain, it also accepts DNAT'd packets, but it's based on specific protocol+port. So you couldn't rely on its presence for VPN port forwarding to the router itself.

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination     
...
1352 81120 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.1          ctstate DNAT tcp dpt:8443
...

 

[RRands]

OK - it is working - thank you so much!!

You are correct - we do not need the FORWARD rules - I deleted the whole firewall-start file, and all still works as expected. I was not totally sure what was different between the versions, but now I see you separated out the FORWARD entries into t different file, and that made it work. (Still works when firewall-start is deleted though)


A huge THANK YOU for your help on this - I know you get nothing out of it - it helped me immensely, though - not sure I would have figured it out on my own, and definitely not in the timeframe that happened with your help - I appreciate you very much!


-randy