FTP WAN Setting Disregarded For VPN Client IP - Major Security Flaw

[xendi]

This is a disaster. I have the FTP Share enabled with anonymous login, which should be no problem because I have "Enable WAN Access" disabled. Out of curiosity, I ran nmap on my WAN's IP address. The results:

PORT     STATE SERVICE
21/tcp   open  ftp
8200/tcp open  trivnet1 (The DLNA server)

I thought "This can't be happening." So I fired up filezilla and connected to my public IP via my asuscomm DDNS address. It connected to the anonymous account! What's even worse, it not only exposes my media server but also my tertiary entware/swap drive. I also happen to be using the policy-based VPN client so it's not like the router should be letting this IP access the FTP server. Let's test that anyway.

I logged into a remote server and tried to connect to the IP via FTP. It didn't work. I ran nmap from the server and it didn't show any open ports. This is suspicious though because I do have the ovpn server running. My idea now is that the router is (For some reason) blocking my remote server altogether. That seems unlikely though so I fired up my local VPN client.

I connected to a VPN server in a far away land (Bulgaria). No FTP connection possible from that IP. I switched to a closer location (One city away in case some geo-blocking was happening, however unlikely). No connection to FTP possible.

Conclusions:

The FTP server is allowing connections from anyone who has the same IP address that my VPN Client is assigned by my VPN provider. This means that anyone who is using the same VPN service as I am can access protected resources on my LAN. I suspect this affects more than just the FTP server given that port scan result. What to do?

 

[Jack Yaz]

This is a disaster. I have the FTP Share enabled with anonymous login, which should be no problem because I have "Enable WAN Access" disabled. Out of curiosity, I ran nmap on my WAN's IP address. The results:

PORT     STATE SERVICE
21/tcp   open  ftp
8200/tcp open  trivnet1 (The DLNA server)

I thought "This can't be happening." So I fired up filezilla and connected to my public IP via my asuscomm DDNS address. It connected to the anonymous account! What's even worse, it not only exposes my media server but also my tertiary entware/swap drive. I also happen to be using the policy-based VPN client so it's not like the router should be letting this IP access the FTP server. Let's test that anyway.

I logged into a remote server and tried to connect to the IP via FTP. It didn't work. I ran nmap from the server and it didn't show any open ports. This is suspicious though because I do have the ovpn server running. My idea now is that the router is (For some reason) blocking my remote server altogether. That seems unlikely though so I fired up my local VPN client.

I connected to a VPN server in a far away land (Bulgaria). No FTP connection possible from that IP. I switched to a closer location (One city away in case some geo-blocking was happening, however unlikely). No connection to FTP possible.

Conclusions:

The FTP server is allowing connections from anyone who has the same IP address that my VPN Client is assigned by my VPN provider. This means that anyone who is using the same VPN service as I am can access protected resources on my LAN. I suspect this affects more than just the FTP server given that port scan result. What to do?

Does enabling the firewall (should be enabled by default) on the VPN client config prevent this?

When you connected via your public IP/DDNS, were you still on the same network as the router?

 

[ColinTaylor]

There is no security issue. You are connecting from inside your LAN via NAT loopback.

EDIT: Strictly speaking this would only be classed as NAT loopback (aka NAT hairpinning) for services that had a forwarding rule from the WAN to a LAN address. Everything else is simply routing with RPDB.

 

[xendi]

Does enabling the firewall (should be enabled by default) on the VPN client config prevent this?

When you connected via your public IP/DDNS, were you still on the same network as the router?

My settings there are...

Create NAT on tunnel: Yes
Inbound firewall: Block

There is no security issue. You are connecting from inside your LAN via NAT loopback.

Consider that if my WAN IP is 174.48.91.15 and I'm using a VPN client and the public IP of my machine is now 82.100.23.130, my FTP client is now in this situation:

FTP Client -> 82.100.23.130 (VPN) -> 174.48.91.15 (WAN IP)

You're saying that the FTP connection does not go through the VPN? Let's do a traceroute:

1?: [LOCALHOST]                      pmtu 1500
 1:  xxx.myisp.net                   0.476ms reached
     Resume: pmtu 1500 hops 1 back 1

Wow I feel pretty ignorant for not knowing that would happen. Obviously the WAN IP is part of the route. Apparently there are some things I don't know about IP routing. I expected it to dumbly route it through the VPN first.