Port Forwarding + Policy Based VPN problems

[Keith I Allsop]

Asus RT-AC5300 running Merlin 384.12
One VPN client configured, with policy based routing to range 192.168.0.160 through 192.168.0.223.

Redirect internet traffic Policy Rules
VPN-1 192.168.0.160/27 0.0.0.0 VPN
VPN-2 192.168.0.192/27 0.0.0.0 VPN

WAN port forwarding configured to open a bunch of ports to a PC at 192.168.0.101 (outside the VPN) e.g.

VNC-http 5800:5801 192.168.0.101 TCP

Test with grc.com port scan from a PC inside the VPN IP range, 192.168.0.168, the ports are all forwarded.
Test with grc.com port scan from PC 192.168.0.101, the ports are all stealth.

I confirmed the IP's are indeed outside or inside the VPN, the VPN is working as configured. I tried disabling the firewall, and disabling NAT acceleration. No help.

The port forwarding is broken for PC's outside the VPN. Am I doing something wrong? Is this a bug?

(note: I was using a Netgear R7000 running kong firmware, with custom scripts, and that was working. Policy based VPN with killswitch, and port forwarding. I will post those scripts later today).

 

[Xentrk]

Asus RT-AC5300 running Merlin 384.12
One VPN client configured, with policy based routing to range 192.168.0.160 through 192.168.0.223.

Redirect internet traffic Policy Rules
VPN-1 192.168.0.160/27 0.0.0.0 VPN
VPN-2 192.168.0.192/27 0.0.0.0 VPN

WAN port forwarding configured to open a bunch of ports to a PC at 192.168.0.101 (outside the VPN) e.g.

VNC-http 5800:5801 192.168.0.101 TCP

Test with grc.com port scan from a PC inside the VPN IP range, 192.168.0.168, the ports are all forwarded.
Test with grc.com port scan from PC 192.168.0.101, the ports are all stealth.

I confirmed the IP's are indeed outside or inside the VPN, the VPN is working as configured. I tried disabling the firewall, and disabling NAT acceleration. No help.

The port forwarding is broken for PC's outside the VPN. Am I doing something wrong? Is this a bug?

(note: I was using a Netgear R7000 running kong firmware, with custom scripts, and that was working. Policy based VPN with killswitch, and port forwarding. I will post those scripts later today).

Welcome to SNBForums!

As you have discovered, you can't selectively route ports on the OpenVPN Client Screen. Check out the Policy Based Port Routing Wiki for instructions.

 

[ColinTaylor]

As you have discovered, you can't selectively route ports on the OpenVPN Client Screen.

That's not what he was asking about.

 

[ColinTaylor]

Test with grc.com port scan from a PC inside the VPN IP range, 192.168.0.168, the ports are all forwarded.

This would be testing the ports on your VPN provider's server, not your router. Therefore this test is meaningless.

Test with grc.com port scan from PC 192.168.0.101, the ports are all stealth.

This ought to work assuming there is a service actively listening on the relevant ports and the PC's firewall is not blocking the incoming connections. Check that the port forwarding rules are active at System Log > Port Forwarding.

 

[Keith I Allsop]

These are the rules I had in my working Netgear R7000:

iptables -I FORWARD -i br0 -s 192.168.0.160/27 -o `nvram get wan_iface` -j DROP
iptables -I FORWARD -i br0 -s 192.168.0.192/27 -o `nvram get wan_iface` -j DROP

Merlin port forwarding is shown in the System Log > Port Forwarding, e.g. for VNC:

ALL TCP 5800:5801 192.168.0.101 5800:5801 VSERVER
ALL TCP 5900:5901 192.168.0.101 5900:5901 VSERVER
ALL UDP 5900:5901 192.168.0.101 5900:5901 VSERVER

Can't connect from internet to VNC server on 192.168.0.101. All ports show as stealth. Can't help but think there is a missing setting somewhere.

 

[ColinTaylor]

The Netgear rules just appear to be ensuring that the VPN clients don't leak information. They aren't doing any port forwarding.

I'd agree there's something else that we're missing. Your Asus rules look correct. Have you tried connecting/scanning while the firewall on the VNC machine (192.168.0.101) is turned off? What VNC server software are you using?

 

[Keith I Allsop]

Yeah, the R7000 port forwarding was done through the menus, not by script. The rules set up policy based routing with a killswitch, same configuration intended as is set up with the Merlin menus.

Keep in mind the VNC server is on the same PC, nothing changed there at all, that was working with the Netgear. So I don't think there is much to doubt there. The VNC server is UltraVNC on Windows 10. Only the router has changed. But I will try your suggestion and edit this with results. EDIT - turning off firewall on the VNC server PC made no difference.

 

[Xentrk]

These are the rules I had in my working Netgear R7000:

iptables -I FORWARD -i br0 -s 192.168.0.160/27 -o `nvram get wan_iface` -j DROP
iptables -I FORWARD -i br0 -s 192.168.0.192/27 -o `nvram get wan_iface` -j DROP

Merlin port forwarding is shown in the System Log > Port Forwarding, e.g. for VNC:

ALL TCP 5800:5801 192.168.0.101 5800:5801 VSERVER
ALL TCP 5900:5901 192.168.0.101 5900:5901 VSERVER
ALL UDP 5900:5901 192.168.0.101 5900:5901 VSERVER

Can't connect from internet to VNC server on 192.168.0.101. All ports show as stealth. Can't help but think there is a missing setting somewhere.

I know the single quotes won't work. You may have to edit the nvram value for wan iface to be either wan0_ipaddr or wan0_gateway depending on your end goal.

#!/bin/sh
iptables -I FORWARD -i br0 -s 192.168.0.160/27 -o "$(nvram get wan_ipaddr)" -j DROP
iptables -I FORWARD -i br0 -s 192.168.0.192/27 -o "$(nvram get wan_ipaddr)" -j DROP

 

[ColinTaylor]

I know the single quotes won't work. You may have to edit the nvram value for wan iface to be either wan0_ipaddr or wan0_gateway depending on your end goal.

He doesn't need to do that. As he said, Merlin's firmware has a menu option for that which the Netgear didn't.

Keep in mind the VNC server is on the same PC, nothing changed there at all, that was working with the Netgear. So I don't think there is much to doubt there. The VNC server is UltraVNC on Windows 10. Only the router has changed. But I will try your suggestion and edit this with results. EDIT - turning off firewall on the VNC server PC made no difference.

Well I'm at a loss. I've just installed UltraVNC on a Windows 10 PC and after forwarding those ports in the router's GUI it worked straight away.

Presumably your router's WAN interface does have a public IP address and isn't behind some form of NAT? Your WAN IP address will change when you change the router.

Maybe try disabling the VPN clients on the router and testing again in case that is interfering with it in some way (aka a bug).

Could you post the output of the following command? It might give us a clue to what's going on.

iptables -L -vnt nat

 

[Keith I Allsop]

Thanks for helping Colin. I will report back the iptables command tonight. I put the R7000 back in for today because I need to access my PC remotely.

 

[Jack Yaz]

Thanks for helping Colin. I will report back the iptables command tonight. I put the R7000 back in for today because I need to access my PC remotely.

You could give RealVNC a spin, they have a cloud connect feature that means you don't have to port forward anything

 

[Keith I Allsop]

Don.t know what to make of this. The R7000 and RT-AC5300 have very different output from the iptables command. The RT-AC5300 doesn't have any entries that match the WAN IP.

R7000:
root@Netgear_R7000:~# iptables -L -vnt nat
Chain PREROUTING (policy ACCEPT 47026 packets, 13M bytes)
pkts bytes target prot opt in out source destination
348 19536 DNAT tcp -- * * 0.0.0.0/0 32.xxWAN-IPx tcp dpt:23 to:192.168.0.1:23
3 106 DNAT icmp -- * * 0.0.0.0/0 32.xxWAN-IPx to:192.168.0.1
10 460 DNAT tcp -- * * 0.0.0.0/0 32.xxWAN-IPx tcp dpt:80 to:192.168.0.101:80
5 204 DNAT tcp -- * * 0.0.0.0/0 32.xxWAN-IPx tcp dpt:443 to:192.168.0.101:443
0 0 DNAT tcp -- * * 0.0.0.0/0 32.xxWAN-IPx tcp dpt:20 to:192.168.0.101:20
0 0 DNAT tcp -- * * 0.0.0.0/0 32.xxWAN-IPx tcp dpt:21 to:192.168.0.101:21
0 0 DNAT tcp -- * * 0.0.0.0/0 32.xxWAN-IPx tcp dpt:5060 to:192.168.0.112:5060
6 2622 DNAT udp -- * * 0.0.0.0/0 32.xxWAN-IPx udp dpt:5060 to:192.168.0.112:5060
0 0 DNAT tcp -- * * 0.0.0.0/0 32.xxWAN-IPx tcp dpt:5061 to:192.168.0.112:5061
0 0 DNAT tcp -- * * 0.0.0.0/0 32.xxWAN-IPx tcp dpt:32400 to:192.168.0.101:32400
0 0 DNAT udp -- * * 0.0.0.0/0 32.xxWAN-IPx udp dpt:32400 to:192.168.0.101:32400
0 0 DNAT tcp -- * * 0.0.0.0/0 32.xxWAN-IPx tcp dpt:8081 to:192.168.0.101:8081
0 0 DNAT udp -- * * 0.0.0.0/0 32.xxWAN-IPx udp dpt:8081 to:192.168.0.101:8081
0 0 DNAT tcp -- * * 0.0.0.0/0 32.xxWAN-IPx tcp dpt:23 to:192.168.0.1:23
0 0 DNAT tcp -- * * 0.0.0.0/0 32.xxWAN-IPx tcp dpts:5800:5801 to:192.168.0.101
1707 88932 DNAT tcp -- * * 0.0.0.0/0 32.xxWAN-IPx tcp dpts:5900:5901 to:192.168.0.101
0 0 DNAT udp -- * * 0.0.0.0/0 32.xxWAN-IPx udp dpts:5900:5901 to:192.168.0.101
0 0 DNAT tcp -- * * 0.0.0.0/0 32.xxWAN-IPx tcp dpts:65500:65535 to:192.168.0.101
597 54642 TRIGGER 0 -- * * 0.0.0.0/0 32.xxWAN-IPx TRIGGER type:dnat match:0 relate:0
Chain INPUT (policy ACCEPT 3234 packets, 293K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 121 packets, 13630 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 1849 packets, 106K bytes)
pkts bytes target prot opt in out source destination
6675 549K MASQUERADE 0 -- * tun1 0.0.0.0/0 0.0.0.0/0
14891 2885K SNAT 0 -- * vlan2 192.168.0.0/24 0.0.0.0/0 to:32.xxWAN-IPx
0 0 MASQUERADE 0 -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x80000000/0x80000000
0 0 SNAT 0 -- * vlan2 192.168.1.0/24 0.0.0.0/0 to:32.xxWAN-IPx

RT-AC5300:
admin@RT-AC5300:/tmp/home/root# iptables -L -vnt nat
Chain PREROUTING (policy ACCEPT 4686 packets, 1022K bytes)
pkts bytes target prot opt in out source destination
0 0 VSERVER all -- * * 0.0.0.0/0 192.168.254.11
Chain INPUT (policy ACCEPT 1585 packets, 626K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 310 packets, 49153 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 229 packets, 23492 bytes)
pkts bytes target prot opt in out source destination
1395 127K MASQUERADE all -- * tun11 192.168.0.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 192.168.0.0/24 0.0.0.0/0 policy match dir out pol ipsec
1945 299K PUPNP all -- * eth0 0.0.0.0/0 0.0.0.0/0
1740 286K MASQUERADE all -- * eth0 !192.168.254.11 0.0.0.0/0
88 27076 MASQUERADE all -- * br0 192.168.0.0/24 192.168.0.0/24
Chain DNSFILTER (0 references)
pkts bytes target prot opt in out source destination
Chain DNSVPN1 (0 references)
pkts bytes target prot opt in out source destination
Chain LOCALSRV (0 references)
pkts bytes target prot opt in out source destination
Chain PCREDIRECT (0 references)
pkts bytes target prot opt in out source destination
Chain PUPNP (1 references)
pkts bytes target prot opt in out source destination
Chain VSERVER (1 references)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:192.168.0.101
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:20 to:192.168.0.101
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 to:192.168.0.101
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5060 to:192.168.0.112
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 to:192.168.0.112
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5061 to:192.168.0.112
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:32400 to:192.168.0.101
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:32400 to:192.168.0.101
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5080 to:192.168.0.112
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5080 to:192.168.0.112
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23 to:192.168.0.101
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:5800:5801 to:192.168.0.101
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:5900:5901 to:192.168.0.101
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:5900:5901 to:192.168.0.101
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:65500:65535 to:192.168.0.101
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 to:192.168.0.101
0 0 VUPNP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain VUPNP (1 references)
pkts bytes target prot opt in out source destination

 

[ColinTaylor]

The problem is that your RT-AC5300 doesn't have a public IP address for its WAN interface. Its IP address is 192.168.254.11. Does that IP address match what you see in the Asus' main web interface?

P.S. If you paste any terminal output into a CODE block it will retain the formatting and make it much easier to read.

 

[Keith I Allsop]

Indeed, the web page says WAN IP: 192.168.254.11

Which setting will fix that? The router is configured for DDNS using dnsomatic, and the correct WAN IP gets sent. (method to retrieve WAN IP = external). Just a guess - if that = internal it will pick up the 192.xxx IP address.

 

[ColinTaylor]

In the router's GUI, under WAN, what is the WAN Connection Type?

What is your router's WAN interface connected to? A cable modem?

 

[Keith I Allsop]

WAN connection type = Automatic IP. The provider is Frontier (formerly AT&T UVerse), so yes, it's their modem.

 

[ColinTaylor]

I'm assuming that the cable modem is bridged? So this looks like a provisioning issue with your ISP. The router will just be picking up whatever IP address your ISP gives it.

Quite often you have to completely disconnect the cable modem for about 30 minutes for it free up the connection to your ISP's network. Then when you plug it back in with your new router it gets a new public IP address. In other cases you need to talk to the ISP to get them to "reset" the connection.

There is a common workaround for this problem. The IP address is tied to the MAC address of your router's WAN interface. So if you find the WAN MAC address of your existing (working) router you can clone it on the Asus. Put it in the "MAC Address" field under WAN > Special Requirement from ISP.

 

[ColinTaylor]

The router is configured for DDNS using dnsomatic, and the correct WAN IP gets sent. (method to retrieve WAN IP = external). Just a guess - if that = internal it will pick up the 192.xxx IP address.

I've just seen that you added this.

If this DDNS update really is working as you say then that would imply that your modem isn't bridged and is in "router mode". I suspect that the DDNS address is just an old one from your previous router?

 

[Keith I Allsop]

DDNS is working, the router sends the correct 32.xxx IP but ONLY if set to = external. If set to = internal, DDNS sends the 192.xxx address. I think the modem has a web page for config, not sure, it's been years since I looked at that.

EDIT - found the modem at 192.168.254.254. It shows Netgear R7000 and its MAC address in its info screen. I'll try spoofing/cloning that into the Asus router and report back.

EDIT - after cloning, everything works. Thank you so much for the time and effort to help me out. I'm not sure I'd have got to the solution any time soon by myself.

 

[ColinTaylor]

I'm not familiar with American cable modems but I've read that some of them have something called DMZplus mode. Maybe it's something to do with that.

https://www.att.com/esupport/article.html#!/smb-internet/KM1188700?gsi=td79at

Looking at the link above my guess is that your modem is setup in DHCPS-fixed mode, whereas DHCPS-dynamic would probably be a better choice if there's only one device (the router) connected to it.