Router web accessibility from WAN/internet when an openvpn client is running

[janedoe]

Hello I'm fairly new with Merlin setting but I noticed that when I have an openvpn client running and having my internet traffic going through it, the router administrative log page is then accessible from the internet by http on the public ip that my vpn service has given to me. It is not quite a surprise because this IP is bind to the router by the openvpn client and then the openvpn client shortcircuit the WAN access which normally block in the Administration/System settings.

So my question are :
- does this put router vulnerability like infosvr exploitable by people theoratically not in my LAN ?
- how to prevent this router access through the openvpn client ?

- Is there a way to have a log of Merlin administration login attempts ?

Please apologize for the newbie questions.

Thank you in advance

 

[coldwizard]

Hello I'm fairly new with Merlin setting but I noticed that when I have an openvpn client running and having my internet traffic going through it, the router administrative log page is then accessible from the internet by http on the public ip that my vpn service has given to me. It is not quite a surprise because this IP is bind to the router by the openvpn client and then the openvpn client shortcircuit the WAN access which normally block in the Administration/System settings.

When on the inside network, you can connect to the router administrative page using either the it's inside or outside IP address. Since you are connected with the VPN, you are logically inside so can do anything you could from inside.

So my question are :
- does this put router vulnerability like infosvr exploitable by people theoratically not in my LAN ?

Yes, would be possible only from the VPN connected device, not the general Internet. However all current Asus, Merlin's and forked firmwares have the infosvr exploit fixed.

- how to prevent this router access through the openvpn client ?

You can specify the IP addresses of the machines that can connect to the administrative page. Look at the bottom of the adminstrative -- System tab.

- Is there a way to have a log of Merlin administration login attempts ?

Not currently possible with Asus or Merlin. John's fork does this, but only for the older routers that he supports. You did not say what router you are using. John's fork is also based on an older version of Merlin's firmware so depending on the router or features you are using may not work for you.
The fork I am talking about is on the first post of
http://www.snbforums.com/threads/fork-update-for-374-43-available.18914/

 

[janedoe]

Thank you for the reply coldwizard, in fact I can access the administrative page from the general internet using my phone on 3G (no wifi lan connection running, I swear) and sending an http request to the IP address attributed to my RT-AC68U by the VPN service. The OpenVPN client is running in TAP mode. Is it the expected Behavior ?

I'm not very familiar with IPTABLES but I ' have tried adding to firewall-start something like
iptables -I FORWARD -i tun21 -d 192.168.1.0/24 -j DROP

where 192.168.1.0 is the RT-AC68U LAN adress but thsi blocks also all outgoing traffic

 

[coldwizard]

Thank you for the reply coldwizard, in fact I can access the administrative page from the general internet using my phone on 3G (no wifi lan connection running, I swear) and sending an http request to the IP address attributed to my RT-AC68U by the VPN service. The OpenVPN client is running in TAP mode. Is it the expected Behavior ?

Maybe I was not clear. If you have the VPN client running on your phone, then it is logically inside your network via any thing that gives the phone Internet access. That could be a public WiFi or your phone's data plan. So what you observe is expected with the VPN running.

If you turn off the VPN client on the phone, and you still can access the routers web page, check the router configuration under Administration -- System tab. In Merlin's (but not Asus) firmware there is an option "Enable Web Access from WAN" which should have the button "No" selected.

I'm not very familiar with IPTABLES but I ' have tried adding to firewall-start something like
iptables -I FORWARD -i tun21 -d 192.168.1.0/24 -j DROP

where 192.168.1.0 is the RT-AC68U LAN address but this blocks also all outgoing traffic

1) Wrong chain. The chains INPUT and OUTPUT are for traffic to/from the router itself. The chain FORWARD is for traffic going between the Internet (or VPN) and your internal network.

2) The destination address you have in the rule is the private address range for the router, but you said using the public IP address. Also by default you are blocking all protocols/ports. Did you mean to block the UDP protocol for DNS access for example?

As a precaution, you should run new iptables commands manually from another file, "firewall-start.sh" for example. If you happen to get yourself locked out of the router, you can then reboot and get back to normal. Only after testing, should you rename the file to firewall-start without the .sh.

Edit to add:
Since you put the rule before the rule with "state existing,related" (from memory so not exact) you will block outgoing too since the outgoing cannot get a reply.

 

[janedoe]

Maybe I was not clear. If you have the VPN client running on your phone, then it is logically inside your network via any thing that gives the phone Internet access. That could be a public WiFi or your phone's data plan. So what you observe is expected with the VPN running.

If you turn off the VPN client on the phone, and you still can access the routers web page, check the router configuration under Administration -- System tab. In Merlin's (but not Asus) firmware there is an option "Enable Web Access from WAN" which should have the button "No" selected.

Probably I was not clear at all :
- The RT-AC68U with Asus merlin is running an openvn client which connect to an external vpn service which does not not firewall anything have all ports open and attribute a unique ip to each client.

- The Asus merlin "Enable Web Access from WAN" is selected to NO

- My phone has no vpn running on it, it just connect on the internet via 3G and I could use any device connected to the internet for this purpose.

With this settings, Administrative Web access from the wild internet is open by sending a request to that unique ip attributed by the external vpn service. May be this is the expected behavior, but then it is quite dangerous.


The only thing that could prevent this is, as you said, by specifying the IP addresses of the machines that can connect to the administrative page via the system tab, but I don't like it so much as I would like to be able to access the administrative page from any machine in my LAN.

Besides thanks for the tip on IPTABLES and firewall-start.sh, very usefull. I'm new to this and I'm trying to figure out what are the rules I should use to prevent this administrative access. By the way I mistype the rule I used, indeed the interface is not tun21 but tap11

 

[coldwizard]

I was thinking the VPN server was on the Router.
Now I understand you are connecting to a external VPN server with the router as the client.
Normally that would be used to connect to another site owned by the same company, but in your case the VPN is to the Internet!

You are correct that you have identified a security problem with your use of the client VPN. I suspect that not only is the router's web page open to the Internet, but also any service the router is providing to the internal network like the FTP server if you have it enabled, the Samba share, etc.

I would suggest that you put the rule you were testing without the destination part in to the chain INPUT after the RELATED,ESTABLISHED rule.

iptables -I INPUT xx -i tap11 -j DROP

where xx is the number where you want the rule inserted.

You don't need the destination, since the INPUT chain in only for traffic coming into the router itself via any of it's IP addresses. You put it after the established rule so that outgoing traffic can work. You don't need the protocol or port since you don't want anything from the VPN side to start any type of connection.

If you have IPV6 enabled, you also need the same rule in ip6tables.

 

[janedoe]

I was thinking the VPN server was on the Router.
Now I understand you are connecting to a external VPN server with the router as the client.
Normally that would be used to connect to another site owned by the same company, but in your case the VPN is to the Internet!

You are correct that you have identified a security problem with your use of the client VPN. I suspect that not only is the router's web page open to the Internet, but also any service the router is providing to the internal network like the FTP server if you have it enabled, the Samba share, etc.

I would suggest that you put the rule you were testing without the destination part in to the chain INPUT after the RELATED,ESTABLISHED rule.

iptables -I INPUT xx -i tap11 -j DROP

where xx is the number where you want the rule inserted.

Thank you coldwizard, at least now I'm I have an issue. By the way a lot of VPN service advise to set asus merlin openvpn client this way, see for instance https://support.hidemyass.com/hc/en...AsusWRT-OpenVPN-Client-Setup-Merlin-firmware-
so in case they are not firewalling at their isp level this could be a common security problem.

Now I tried the rule you suggest inserting in as you said it seems it does not work as expected as I still have the problem. Here is what I get for INPUT and FORWARD Chains when I do an iptables -L -v

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
65 7321 ACCEPT all -- tap11 any anywhere anywhere
0 0 DROP udp -- any any anywhere anywhere udp dpt:9999
0 0 DROP all -- any any anywhere anywhere state INVALID
719 376K ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
0 0 DROP all -- tap11 any anywhere anywhere
17 3417 ACCEPT all -- lo any anywhere anywhere state NEW
260 36319 ACCEPT all -- br0 any anywhere anywhere state NEW
0 0 ACCEPT udp -- any any anywhere anywhere udp spt:bootps dpt:bootpc
78 8190 DROP all -- any any anywhere anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
6 418 DROP all -- br0 eth0 anywhere anywhere
331 302K ACCEPT all -- tap11 any anywhere anywhere
224 24671 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
0 0 DROP all -- !br0 eth0 anywhere anywhere
0 0 DROP all -- any any anywhere anywhere state INVALID
0 0 ACCEPT all -- br0 br0 anywhere anywhere
0 0 DROP icmp -- eth0 any anywhere anywhere
0 0 ACCEPT all -- any any anywhere anywhere ctstate DNAT
17 1045 ACCEPT all -- br0 any anywhere anywhere

 

[coldwizard]

...
Now I tried the rule you suggest inserting in as you said it seems it does not work as expected as I still have the problem. Here is what I get for INPUT and FORWARD Chains when I do an iptables -L -v

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
65 7321 ACCEPT all -- tap11 any anywhere anywhere
0 0 DROP udp -- any any anywhere anywhere udp dpt:9999
0 0 DROP all -- any any anywhere anywhere state INVALID
719 376K ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
0 0 DROP all -- tap11 any anywhere anywhere
17 3417 ACCEPT all -- lo any anywhere anywhere state NEW
260 36319 ACCEPT all -- br0 any anywhere anywhere state NEW
0 0 ACCEPT udp -- any any anywhere anywhere udp spt:bootps dpt:bootpc
78 8190 DROP all -- any any anywhere anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
6 418 DROP all -- br0 eth0 anywhere anywhere
331 302K ACCEPT all -- tap11 any anywhere anywhere
224 24671 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
0 0 DROP all -- !br0 eth0 anywhere anywhere
0 0 DROP all -- any any anywhere anywhere state INVALID
0 0 ACCEPT all -- br0 br0 anywhere anywhere
0 0 DROP icmp -- eth0 any anywhere anywhere
0 0 ACCEPT all -- any any anywhere anywhere ctstate DNAT
17 1045 ACCEPT all -- br0 any anywhere anywhere

The bold/underlined rules are causing your problem.
The rules are processed first to last, and first rule that has a jump to accept/drop and matches ends the processing. When a rule is used, it's packet count increases.
On the INPUT chain for example, you have left a rule #1 which accepted 65 of the packets. The rule for tap11 later in the rules has a count of 0, so was never used.
On the forward chain:
1) most rules like this one should be after the related,established rule.
2)do you really want outside to initiate connections with inside? The related,established rule handles the returning traffic from an outgoing initiated connection.

Two useful commands when working with iptables are

To list with line numbers use
iptables -nvL INPUT --lin

To delete a rule #xx (note the numbers reorder after each delete, so list just before each delete)
iptables -D INPUT xx

 

[coldwizard]

A virtual private network (VPN) is a network that uses a public telecommunication infrastructure, such as the Internet, to provide remote offices or individual users with secure access to their organization's network.

The key words are private and their organization. You are using it to connect to a public network. It was not designed for that purpose and that is why the security is wrong for you.

Many sites say to make this or that work, set the file protection with
chmod 777 filename
Would you do that?

Most of what I find on the Internet has little concern for security.

Sorry, just my rant for the day.

 

[janedoe]

A virtual private network (VPN) is a network that uses a public telecommunication infrastructure, such as the Internet, to provide remote offices or individual users with secure access to their organization's network.

The key words are private and their organization. You are using it to connect to a public network. It was not designed for that purpose and that is why the security is wrong for you.

Many sites say to make this or that work, set the file protection with
chmod 777 filename
Would you do that?

Most of what I find on the Internet has little concern for security.

Sorry, just my rant for the day.

You are probably right about VPN and for what usage it was designed originally, but you know that nowadays there is a lot of commercial services offering internet access through a VPN in order to circumvent access limitation by their ISP or country policy. So using a VPN for accessing the internet is quite common. But well I could not agree more on the little concern for security, as soon as it works and people can sell their service, unfortunately it's often considered as enough.

Now thank you again for the IPATABLES tips. I'm trying to figure out how those lines you mentionned have been included in the iptables and by what process, may be the openvpn sever has the ability to push some iptables setting to the client ?

 

[coldwizard]

...
Now thank you again for the IPATABLES tips. I'm trying to figure out how those lines you mentionned have been included in the iptables and by what process, may be the openvpn sever has the ability to push some iptables setting to the client ?

The rules may be created by the configuration of the VPN on the router based on it's expected use.

Lets just concentrate on getting a set of rules that works, and protects the router and network for the configuration you are using.
To that end, manually delete the existing tap11 rule #1 in the INPUT chain. Insert the new tap11 rule as you have done. Don't make any changes to the FORWARD chain.
Then test that (1) VPN still works as expected and (2) the GUI interface access to the router is blocked from outside.

If that works, then proceed to delete the tap11 rule from the FORWARD chain. I expect the last rule for br0 will handle the outgoing traffic, and the established rule will handle the returning traffic.
Test again that the VPN works as expected.

 

[janedoe]

The rules may be created by the configuration of the VPN on the router based on it's expected use.

Lets just concentrate on getting a set of rules that works, and protects the router and network for the configuration you are using.
To that end, manually delete the existing tap11 rule #1 in the INPUT chain. Insert the new tap11 rule as you have done. Don't make any changes to the FORWARD chain.
Then test that (1) VPN still works as expected and (2) the GUI interface access to the router is blocked from outside.

If that works, then proceed to delete the tap11 rule from the FORWARD chain. I expect the last rule for br0 will handle the outgoing traffic, and the established rule will handle the returning traffic.
Test again that the VPN works as expected.

Hello coldwizard, I just test those rules so here are the results :

- after manually deleting the existing tap11 rule #1 in the INPUT chain, things works fine the GUI interface access from outside is blocked and all ports appear as stealth when tested through https://www.grc.com

- then after manually deleting the tap11 rule in the FORWARD chain things are still going fine (by the way what was the effect of that rule ? )

Now when the openvpn client restart ( because the connection is lost or whatever reason) then those bad rules we tried to delete ar back in the Iptables and the GUI port is open again from outside

I need to find a good tutorial on those iptables....

 

[coldwizard]

...
Now when the openvpn client restart ( because the connection is lost or whatever reason) then those bad rules we tried to delete ar back in the Iptables and the GUI port is open again from outside
...

I suspect that the VPN connection is timing out with no activity.
I will write a script to modify the rules for you. But first I need a little information. Here is some code that I want you to place into a file call it /jffs/scripts/openvpn-event.sh.

#!/bin/sh
# set -v
# set -x
#
# explore script for
# /jffs/scripts/openvpn-event

logger -t $0 "args $1 $2 $3 $4 $5"
logger -t $0 "script_type=$script_type, trusted_port=$trusted_port"
set >/tmp/$(basename $0)-starting-set.txt

The code does nothing to your configuration, but puts a few log entries into the router's log and creates a .txt file in /tmp.
Test it manually by running the /jffs/scripts/openvpn-event.sh to see if there are any error messages and that it does not hang.
Now copy the file
to /jffs/scripts/openvpn-event
and again
to /jffs/scripts/firewall-start
Remember to make the files executable
chmod 700 *
Reboot, and run your vpn (with the manual changes to the rules), wait for it to timeout and and break the connection. Reconnect the VPN.

Now what I want to see is the output from the router's log file.
If you
cat /tmp/syslog.log | grep -i "/jffs/scripts"
you will get the lines I want to see.

I don't need the /tmp file at this time.

Once I have that, I will write a script to set up your configuration that will I hope survive the VPN reconnection.

Edit:
The rule you are deleting form the FORWARD chain was to allow access to all machines on your internal network from the private network of the VPN server. Not to worry as since your network is using private IP addresses, they could not be easily accessed from the Internet since the Internet ISPs do not route those addresses.

 

[coldwizard]

Attached is a script to do what you are doing now.

I have added one more rule that might keep the VPN connection open. It allows UDP port 1194 to be open to the Internet.

Also added a new chain (sickbird) to get a sample log of the packets dropped from the VPN.
The script is designed to be run manually multiple times without generating multiple duplicate rules.

I still would like the output requested in my last post.
Rename the attached .txt file to a .sh type, and run it manually.

 

[janedoe]

Hello coldwizard, I apologize for the late reply but I was far from home this week. So I tried what you suggest and here is the lines I got from the log. The connection is fairly stable so I had to close the vpn client connection and restart it through the Merlin web interface. Also for security reasons I had to modify the ip assigned to me by the vpn server but you will see a first assigned ip on reboot ans another one on Vpn client restart.

Thank you very much for the effort.

Apr 17 09:31:05 /jffs/scripts/openvpn-event: args tap11 1500 1574 71.122.148.133 255.255.255.224
Apr 17 09:31:05 /jffs/scripts/openvpn-event: script_type=up, trusted_port=21003
Apr 17 09:32:53 /jffs/scripts/openvpn-event: args tap11 1500 1574 71.122.148.133 255.255.255.224
Apr 17 09:32:53 /jffs/scripts/openvpn-event: script_type=down, trusted_port=21003
Apr 17 09:33:16 /jffs/scripts/openvpn-event: args tap11 1500 1574 71.122.148.126 255.255.255.224
Apr 17 09:33:16 /jffs/scripts/openvpn-event: script_type=up, trusted_port=21003

 

[coldwizard]

Hello coldwizard, I apologize for the late reply but I was far from home this week. So I tried what you suggest and here is the lines I got from the log. The connection is fairly stable so I had to close the vpn client connection and restart it through the Merlin web interface. Also for security reasons I had to modify the ip assigned to me by the vpn server but you will see a first assigned ip on reboot ans another one on Vpn client restart.

Thank you very much for the effort.

Apr 17 09:31:05 /jffs/scripts/openvpn-event: args tap11 1500 1574
Apr 17 09:31:05 /jffs/scripts/openvpn-event: script_type=up, trusted_port=21003
Apr 17 09:32:53 /jffs/scripts/openvpn-event: args tap11 1500 1574
Apr 17 09:32:53 /jffs/scripts/openvpn-event: script_type=down, trusted_port=21003
Apr 17 09:33:16 /jffs/scripts/openvpn-event: args tap11 1500 1574
Apr 17 09:33:16 /jffs/scripts/openvpn-event: script_type=up, trusted_port=21003

I would like two more items from your syslog file.
Did the firewall-start script happen before or after the the openvpn-event script_type=up at boot time?
Did the firewall-start script happen again between the down and up of the vpn?

 

[janedoe]

I would like two more items from your syslog file.
Did the firewall-start script happen before or after the the openvpn-event script_type=up at boot time?
Did the firewall-start script happen again between the down and up of the vpn?

Hello coldwizard
From the syslog.log file I can see that :
the firewall-start script happen before the openvpn-event script_type=up at boot time
the firewall-start script does not happen again between the down and up of the vpn

Also I have tested your openvpn-event B file and it seems to work very nicely. The only surprising thing is that the UDP port that you keep open appear to be open from outside when tested with http://www.base64online.com/port-check.php but I don't how reliable are those online test as other online tester showed this port as closed.

One last thing, I tried to forward a port from my WAN to some device in my LAN. For this I had to use an iprange excluding the IP of the device (192.168.2.254) in the corresponding line inside the firewall-start file :
iptables -I FORWARD -i br0 -m iprange --src-range 192.168.2.1-192.168.2.253 -o eth0 -j DROP

it works well when the openvpn client is not running, but when the openvpn client is running I cannot reach the forwarded port from the internet. This is occuring with your script running or not. I guess I missed something and the openvpn client route all the packet from the lan through the VPN.

 

[coldwizard]

Hello coldwizard
From the syslog.log file I can see that :
the firewall-start script happen before the openvpn-event script_type=up at boot time
the firewall-start script does not happen again between the down and up of the vpn

Also I have tested your openvpn-event B file and it seems to work very nicely. The only surprising thing is that the UDP port that you keep open appear to be open from outside when tested with http://www.base64online.com/port-check.php but I don't how reliable are those online test as other online tester showed this port as closed.

One last thing, I tried to forward a port from my WAN to some device in my LAN. For this I had to use an iprange excluding the IP of the device (192.168.2.254) in the corresponding line inside the firewall-start file :
iptables -I FORWARD -i br0 -m iprange --src-range 192.168.2.1-192.168.2.253 -o eth0 -j DROP

it works well when the openvpn client is not running, but when the openvpn client is running I cannot reach the forwarded port from the internet. This is occuring with your script running or not. I guess I missed something and the openvpn client route all the packet from the lan through the VPN.

Attached is a script to secure your VPN to a public server.
You can NOT run it manually. It picks up the VPNdevice for the argument to the script, so should work if you decide to change your VPN to from tap to tun mode.
It puts one line into the syslog file to inform you that security is set on the VPN device.
Copy this file to /jffs/scripts/openvpn-event and you can remove the /jffs/scripts/firewall-start that I sent you before.
Remember to make the file executable
chmod 700 *

Reboot and check your security.

As for your port forwarding you can set that feature from the GUI WAN section I believe. If you need help with your port forwarding, please start a new thread.


Edit - oops I forgot the file will put it in next post.
Edit - got it attached to this post.

 

[janedoe]

One thousand Thank You coldwizard, your script is working very well and it should be useful to anyone using a VPN service as a secondery ISP. By reading several threads here I'm sure it is a quite common usage, may be people are not aware that their LAN port are then exposed.

Moreover by studying your script I learned things about iptables so thank you again!

 

[primitivo]

@coldwizard, I tried to use your script openvpn-event-C.txt. It works great when I call it manually. The problem is it does not auto-start with VPN connection. I did set chmod and followed all instructions carefully. Any idea why?