IP leakage from a device behind GL-MT300N-V2 while the GL-MT300N-V2 is reconnectiong to VPN

Technical Support for Routers
1

The firmware version of my GL-MT300N-V2 is 3.025.

The GL.iNet Admin Panel says:

If you enabled VPN but the VPN cannot connect to its server, there will be NO Internet.
When you change server while VPN is connected, VPN will not be leaked.

I’ve made a following script on a Raspberry PI sitting behind the GL-MT300N-V2 (on the LAN side of it):

while :; do date ; curl ifconfig.me ; printf "\n"; sleep 1; done |tee /home/pi/iplog

The output shows that while the GL-MT300N-V2 lost its VPN connection three curl requests (one second from another each) from the Raspberry PI to ifconfig.me have shown my actual provider’s IP before new VPN IPs got showing again.

2

I am now starting to think it’s because I’ve set Forward: accept as a general setting on /cgi-bin/luci/admin/network/firewall

However otherwise the PI would not mount an SMB share on the WAN side of the GL.

How do I set up zones correctly so that the SMB share on the WAN side would be accessible (at least while the VPN is connected), but the IP would not leak when VPN disconnects? Forward is set on accept in the LAN=>WAN rule in the defaults, but it doesn’t seam to work when the general rule is drop.

3

You should not change the firewall rules manually. I think it broken the rules causing IP leak.

You can try to enable “share on wan” in the UI.

4

I am not talking about sharing from GL on its WAN. I am talking of accessing a share on a 3rd device which is on the GL’s WAN from a device on the GL’s LAN.

5

You should not change the firewall rules manually. I think it broken the rules causing IP leak.

ok

I’ve reverted the firmware to stock 3.025.

Didn’t mess with LUCI at all and only configured the port forwarding and the VPN client in the GL.iNet Admin Panel.

Now activated the said script on my Raspberry PI behind the MT300N again: will report tomorrow if there were any IP leaks over the night.

However I now again have the problem with not being able to access ( “Host is down” message) the SMB share which is on a device on the same side with the GL’s WAN from behind the GL’s LAN while the VPN client is connected. Not even able to ping any device from over the GL’s NAT; even though the Internet IPs - that’s over the double NAT (trippple NAT if you count the VPN) do get pinged.

If the last paragraph looks too complicated: I need to access the devices from my main LAN which is the GL’s WAN from the GL’s LAN however the GL seems to be blocking that as long as there is an established VPN connection.

6

If you use vpn, then you should not use local server behind the mini router. Although this could be done by complicated firewall rules, it is not easy with the UI.

7

Maybe I could reshare the SMB share from my main LAN via the GL itself for the GL’s LAN then? Would it be easier to do? In fact, it even doesn’t need to be reshared via SMB - NFS or SSHFS would do!

8

Juhuh! Resharing it via GL did work!

Simply amended /etc/config/samba on the GL with

config 'sambashare'
  option 'name' 'HDD1'
  option 'path' '/mnt/HDD1'
  option 'create_mask' '0700'
  option 'dir_mask' '0700'
  option read_only 'no'

Restarted the Samba on the GL.

Then changed the IP in /etc/fstab on the PI to the GL’s and it did fly!

P.S. I will keep this thread open to report there was no IP leakage after a little observation.

9

Ah… Didn’t exactly fly yet: can’t write on the GL’s share from the PI. (The writable option is on in the GL ADMIN PANEL)

Here is the mount output of the PI:
//192.168.8.1/HDD1 on /mnt/HDD1 type cifs (rw,relatime,vers=1.0,sec=none,cache=strict,uid=1000,forceuid,gid=0,noforcegid,addr=192.168.8.1,soft,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)

Changing the config ‘sambashare’ on the GL to 0777 and chmodding /mnt/HDD1 to 777 doesn’t help,

10

You need to add

 option guest_ok yes
11

Already tried that, but it didn’t work out. However I had luck with (manually) mounting via SSHFS.

12

The said log run on stock 3.025 without changing the firewall rules in LUCI now shows no leakage.