SSH & Web Access is accessible over WAN even though this option is disabled!

[d0m]

Hello everyone,

I am running a Asus AC66U with latest Merlin (374.41) at home. Factory reset after latest firmware update.

- I have OpenVPN client configured, so that my internet traffic is routed over VPN (I am in China... )

- I have "Allow SSH Access from WAN" and "Enable Web Access from WAN" DISABLED. This works, and both is not accessible from outside if I try (and/or portscan) my normal (not the OpenVPN) IP address from outside.

However I started to see some (dropbear) log entries, indicating that someone was probing ssh from outside! Obviously I was surprised to see that my router seems to get these requests at all, because ssh should not be accessible over WAN. I did some scanning and saw that both, SSH and Webinterface are accessible over the Open VPN IP from WAN side! Is this the intended behaviour? How can I block this?

Thanks a lot in advance for any recommendation and help!
Dom

 

[xaviercharles]

i noticed this to. Have had the same issue since 374.9_em-0

 

[joegreat]

I did some scanning and saw that both, SSH and Webinterface are accessible over the Open VPN IP from WAN side! Is this the intended behaviour? How can I block this?

Hi,

I did a small check on my main router AC68U and I cannot confirm your observation: All ports are closed in my case!

But I remember an issue some time ago that enabling some "services" (maybe VPN) could enable/disable some iptables rules or trigger other services... Maybe this is the case in your setup.

Results from http://en.dnstools.ch/port-scan.html

Port status on host xx.xx.xx.xx:
21 "FTP"-Port is closed. - Will be used to transfer data through ftp.
22 "SSH"-Port is closed. - Will be used to connect a Secure Shell.
23 "Telnet"-Port is closed. - Will be used for terminal emulation.
25 "SMTP"-Port is closed. - Will be used for email delivery (see also port 465).
53 "DNS"-Port is closed. - Will be used to resolve domain names into ip addresses.
79 "Finger"-Port is closed. - Will be used to show informations about a user.
80 "HTTP"-Port is closed. - Will be used to communicate with the webserver.
110 "POP3"-Port is closed. - Will be used by clients to connect to an email server.
115 "SFTP"-Port is closed. - Will be used by "Simple File Transfer Protocol" to transfer files.
135 "RPC"-Port is closed. - Will be used by Remote Procedure Calls.
139 "NetBIOS"-Port is closed. - Will be used by Netbios (Network Basic Input Output System).
143 "IMAP"-Port is closed. - Will be used to access and manage mailboxes.
194 "IRC"-Port is closed. - Will be used to access IMAP mailboxes.
389 "LDAP"-Port is closed. - Will be used for querying and modifying directory services.
443 "HTTPS"-Port is closed. - Will be used for Hypertext Transfer Protocol over Secure Socket Layer.
445 "SMB"-Port is closed. - Will be used to provide shared access to files and printers.
465 "SMTPS"-Port is closed. - Will be used for secured mail transfer.
1433 "MS SQL"-Port is closed. - Will be used to communicate with a SQL server.
1723 "PPTP"-Port is closed. - Will be used for Point-to-Point Tunneling (VPN).
3306 "MySQL"-Port is closed. - Will be used to access MySQL databases.
3389 "Remote Desktop"-Port is closed. - Will be used by Windows Remotedesktop.
5632 "pcAnywhere"-Port is closed. - Will be used to remote access a machine through pcANYWHERE.
5900 "VNC"-Port is closed. - Will be used by Virtual Network Computing to share desktops.
6112 "Warcraft III"-Port is closed. - Will be used by Warcraft III to host network games.
8080 "HTTP-Alt"-Port is closed. - Will be used by Proxy and Caching Servers.

With kind regards
Joe

 

[d0m]

It only shows up on my VPN Wan IP. Over the normal WAN IP the ports are not accessible.

--> Portscan 'normal WAN IP'

Port status on host 114.xxx.xxx.xxx.
21 "FTP"-Port is closed.
Will be used to transfer data through ftp.
22 "SSH"-Port is closed.
Will be used to connect a Secure Shell.
23 "Telnet"-Port is closed.
Will be used for terminal emulation.

(...)

80 "HTTP"-Port is closed.
Will be used to communicate with the webserver.
110 "POP3"-Port is closed.
Will be used by clients to connect to an email server.

If I use the other WAN IP (the one from the Open VPN connection) the router ports are exposed:

Port status on host 23.xxx.xxx.xxx.
21 "FTP"-Port is closed.
Will be used to transfer data through ftp.
22 "SSH"-Port is open.
Will be used to connect a Secure Shell.
23 "Telnet"-Port is closed.
Will be used for terminal emulation.

(...)

80 "HTTP"-Port is open.
Will be used to communicate with the webserver.
110 "POP3"-Port is closed.
Will be used by clients to connect to an email server.

I guess you are right that enabling the Open VPN connection messes the iptables/routing. However I can't imagine that this is the desired behaviour !?

Can I somehow manually block the ports from the VPN connection (I am not really an expert on iptables and routing..)

 

[d0m]

i noticed this to. Have had the same issue since 374.9_em-0

Were you able to fix it? Adjusting iptables/routing? I am not really comfortable to have my admin web interface and ssh exposed to the world . Anything I could do?

 

[john9527]

Just another data point....same on my system. VPN active...ports are open....stop VPN client ports are closed.

Edit: Also loaded up the latest Shibby Tomato build to check that.....same behavior.

 

[RMerlin]

Just another data point....same on my system. VPN active...ports are open....stop VPN client ports are closed.

Edit: Also loaded up the latest Shibby Tomato build to check that.....same behavior.

The VPN client creates a tunnel. So basically, it bypasses your firewall. This is the primary use for a VPN - to access a remote network, bypassing the firewall that would otherwise prevent you from accessing services located behind that firewall.

There's a firewall option on the Client page, however I never studied that part of the code so I have no idea what it does concretely.

 

[Builder71]

...

I did a small check on my main router AC68U and I cannot confirm your observation: All ports are closed in my case!

...

+1

I don't see any problem as well.

With a running OpenVPN session to my router, I tried connecting with PuTTY and IE10 on a different computer.
All timing out as expected.

Running ShieldsUp also shows all service ports Stealth. (Running on the laptop with the OpenVPN session.)

Of course I can connect to my router using it's local IP address.
That works because of the running VPN.

So, I don't understand what d0m's issue is.

 

[d0m]

+1

With a running OpenVPN session to my router, I tried connecting with PuTTY and IE10 on a different computer.
All timing out as expected.

Running ShieldsUp also shows all service ports Stealth. (Running on the laptop with the OpenVPN session.)

Of course I can connect to my router using it's local IP address.
That works because of the running VPN.

So, I don't understand what d0m's issue is.

Did you try scan/try the IP address of the Open VPN connection? Or the normal WAN IP address?

I can reproduce it on my router with those steps:

- Router is switched on. No Open VPN running. I get the WAN IP address AAA.AAA.AAA.AAA from my provider. I do a portscan on this AAA.AAA.AAA.AAA address --> all ports closed (as it should be)

- I start the OpenVPN connection. All my outgoing traffic is now sent over the VPN. I get a VPN address BBB.BBB.BBB.BBB. Thus the router has now two external IP addresses AAA.... and BBB...

- I do a portscan on AAA.AAA.AAA.AAA --> still all ports closed.

- I do a portscan on BBB.BBB.BBB.BBB --> port 80 (router web interface) and port 22 (ssh) is open and accessible from outside.


My issue is: if you do not know this behaviour and you use OpenVPN for your outgoing traffic e.g. due to privacy or censorship reasons, you are always opening access to ssh and webinterface to the outside as well. Basically I was exposing those access to the outside for months without knowing (thank god I have a strong admin password), and only stumbled upon it by accident due to the strange entries in the logfile.

 

[octopus]

Did you try scan/try the IP address of the Open VPN connection? Or the normal WAN IP address?

I can reproduce it on my router with those steps:

- Router is switched on. No Open VPN running. I get the WAN IP address AAA.AAA.AAA.AAA from my provider. I do a portscan on this AAA.AAA.AAA.AAA address --> all ports closed (as it should be)

- I start the OpenVPN connection. All my outgoing traffic is now sent over the VPN. I get a VPN address BBB.BBB.BBB.BBB. Thus the router has now two external IP addresses AAA.... and BBB...

- I do a portscan on AAA.AAA.AAA.AAA --> still all ports closed.

- I do a portscan on BBB.BBB.BBB.BBB --> port 80 (router web interface) and port 22 (ssh) is open and accessible from outside.


My issue is: if you do not know this behaviour and you use OpenVPN for your outgoing traffic e.g. due to privacy or censorship reasons, you are always opening access to ssh and webinterface to the outside as well. Basically I was exposing those access to the outside for months without knowing (thank god I have a strong admin password), and only stumbled upon it by accident due to the strange entries in the logfile.

How many from outside can do BBBB vpn tunnel ?

 

[Builder71]

I think we use a different configuration.
On my router the OpenVPN SERVER is running.
I use this to connect from the office to my home network.

It seems you use the OpenVPN CLIENT on your router.
To connect from home to a VPN provider. Correct?

If this is the case I'm not able to test your situation.

 

[d0m]

I think we use a different configuration.
On my router the OpenVPN SERVER is running.
I use this to connect from the office to my home network.

It seems you use the OpenVPN CLIENT on your router.
To connect from home to a VPN provider. Correct?

If this is the case I'm not able to test your situation.

Yes, that is correct. I use OpenVPN client to route my internet traffic over VPN. I currently live in China and use that to circumvent the Great Firewall .

 

[Builder71]

Yes, that is correct. I use OpenVPN client to route my internet traffic over VPN. I currently live in China and use that to circumvent the Great Firewall .

You should my friend!
Don't let anyone else decide what's good for you.

Sorry I can't help with your issue.

 

[sveinan]

I do not really see a problem with this behavior. Pretty certain we do not have a security problem.

How I try to think about it:
- [Internet Devices] <-> (WAN-side)[ASUS-Router](internal-side) <-> [Local Devices]

Now. The settings we are talking about are the "... access from WAN" side, which we have set to (*)No. Lets say the ASUS-Router has the following two IP's assigned:
- WAN-IP: 123.234.123.234
- Internal-IP: 192.168.0.1

Ignore OpenVPN for a moment. Normally you would think about this as being: If using the WAN-IP (123.234.123.234), then no access. That is NOT the case (as I understand it). The "... access from WAN" settings is access originating from the physical WAN-side, independent of WAN-IP or Internal-IP being used as address. So if you are 'hitting' the ASUS-Router from the internal-side, you will get access, even if using the WAN-IP (internal ASUS-Router routing, knows its own WAN-IP). Because your traffic is not originating from the WAN-side, you are on the internal-side.

With this in mind, the behaviour of OpenVPN should be logical. When you have a OpenVPN tunnel/connection to your ASUS-Router, all your traffic (unless split-tunneling) goes through the tunnel, and out again from the internal-side, out on the internet. So if you, with OpenVPN, try to access the WAN-IP (123.234.123.234). You get access, your traffic, seen from the ASUS-Router, is from internal-side. Turn off OpenVPN, try the same operation against WAN-IP (123.234.123.234), no access. You are 'hitting' the ASUS-Router from the WAN-side.

Everyone else, who do not have physical access to an ethernet port on your ASUS-Router (or wireless), and no OpenVPN login info. Will always 'hit' the ASUS-Router from the WAN-side. And no access is given because "... access from WAN" is set to (*)No.

Hope this matches your situation, or else I have to rethink my assumptions, too much work

 

[sinshiva]

i think i understand the problem. It sounds like your VPN provider gives you a unique WAN IP which is then 1:1 NAT to the internal IP your router gets from the VPN provider. the VPN provider doesn't firewall your VPN WAN IP, so you need to firewall the tun interface because SSH and the WEBUI listen on everything by default.

So, you should figure out the exact interface used for VPN on the router via 'ifconfig', should be something like tun21 or tun22. (not sure what the client defaults to)

then, you could add a firewall rule like;

iptables -I INPUT -i tun21 -j DROP

(not sure if this might need to be on the PREROUTING chain rather than INPUT)

which would need to be added to a start script on JFFS.

 

[d0m]

I do not really see a problem with this behavior. Pretty certain we do not have a security problem.

How I try to think about it:
- [Internet Devices] <-> (WAN-side)[ASUS-Router](internal-side) <-> [Local Devices]

Now. The settings we are talking about are the "... access from WAN" side, which we have set to (*)No. Lets say the ASUS-Router has the following two IP's assigned:
- WAN-IP: 123.234.123.234
- Internal-IP: 192.168.0.1

Ignore OpenVPN for a moment. Normally you would think about this as being: If using the WAN-IP (123.234.123.234), then no access. That is NOT the case (as I understand it). The "... access from WAN" settings is access originating from the physical WAN-side, independent of WAN-IP or Internal-IP being used as address. So if you are 'hitting' the ASUS-Router from the internal-side, you will get access, even if using the WAN-IP (internal ASUS-Router routing, knows its own WAN-IP). Because your traffic is not originating from the WAN-side, you are on the internal-side.

With this in mind, the behaviour of OpenVPN should be logical. When you have a OpenVPN tunnel/connection to your ASUS-Router, all your traffic (unless split-tunneling) goes through the tunnel, and out again from the internal-side, out on the internet. So if you, with OpenVPN, try to access the WAN-IP (123.234.123.234). You get access, your traffic, seen from the ASUS-Router, is from internal-side. Turn off OpenVPN, try the same operation against WAN-IP (123.234.123.234), no access. You are 'hitting' the ASUS-Router from the WAN-side.

Everyone else, who do not have physical access to an ethernet port on your ASUS-Router (or wireless), and no OpenVPN login info. Will always 'hit' the ASUS-Router from the WAN-side. And no access is given because "... access from WAN" is set to (*)No.

Hope this matches your situation, or else I have to rethink my assumptions, too much work

Haha, thanks for your your thoughts on that issue! Yes, first I thought it only happens if I try my OpenVPN Wan IP am inside my own network.
However it really is open to the outside from everywhere. Thus even if I use for example my phone with 3G and I type in my WAN IP (the Open VPN one ), I can access my router. Thus everyone who knows my external IP can potentially access.

 

[d0m]

i think i understand the problem. It sounds like your VPN provider gives you a unique WAN IP which is then 1:1 NAT to the internal IP your router gets from the VPN provider. the VPN provider doesn't firewall your VPN WAN IP, so you need to firewall the tun interface because SSH and the WEBUI listen on everything by default.

So, you should figure out the exact interface used for VPN on the router via 'ifconfig', should be something like tun21 or tun22. (not sure what the client defaults to)

then, you could add a firewall rule like;

iptables -I INPUT -i tun21 -j DROP

(not sure if this might need to be on the PREROUTING chain rather than INPUT)

which would need to be added to a start script on JFFS.

Yes, exactly! My VPN Provider gives me a unique WAN IP and does not NAT/Firewall me. Thanks a lot for the hint with the iptables. I will try that tonight and see whether this helps.

 

[sveinan]

Haha, thanks for your your thoughts on that issue! Yes, first I thought it only happens if I try my OpenVPN Wan IP am inside my own network.
However it really is open to the outside from everywhere. Thus even if I use for example my phone with 3G and I type in my WAN IP (the Open VPN one ), I can access my router. Thus everyone who knows my external IP can potentially access.

Aaah. Sorry, I didn't read your posts good enough You have an ASUS Router that is using it's built-in VPN client to dial-out. I though it was the other way round, OpenVPN server on ASUS Router, dial-in.

Think the guy above is onto something, hope you find a solution that works

 

[Builder71]

... I will try that tonight and see whether this helps.

Keep us posted!

 

[d0m]

then, you could add a firewall rule like;

iptables -I INPUT -i tun21 -j DROP

(not sure if this might need to be on the PREROUTING chain rather than INPUT)

which would need to be added to a start script on JFFS.

I tried the iptables command (with my corresponding VPN tun interface number) and it definitely does something, i.e. blocks the ports. However at the same time the router gets completely unresponsive until all traffic stops. I can then only reboot the router to fix it. I guess it creates a loop somewhere or filters too much... I am not really familiar with iptables #newb

But the general direction is right I guess. I just have to find the right iptables setting to block the ports and add that then to the right trigger script. Or maybe I should just let it be and simply use a super complex password instead...