loopback between tun and eth

loopback between tun and eth

[Al Grant]

Hi All,

I have a QNAP NAS which I have setup as a OpenVPN server. The NAS is
behind a modem/router which is also the gateway to the internet.

I have a routed OpenVPN connection to the QNAP NAS.

The QNAP subnet is 10.1.1.0
The OpenVPN subnet is 10.8.0.0
My LAN (client) is 192.168.150.0

In the router on the VPN server LAN I have a static route for 10.8.0.0
to 10.1.1.2 (QNAP NAS IP and also OpenVPN IP) - so there is a return
path so to speak for clients on the remote lan when accessed by VPN
clients.

The strange issue is that when I connect to the remote LAN I can
connect to all remote clients using the remote LAN subnet addresses
(10.1.1.0) *except* for the QNAP iteself (10.1.1.2).

Apparently this behavious is due to no loopback connection between the
tun and eth (someone suggested QNAP did this by design, but I dont
know why).

Anyway, the question is - is there a way using iptables I can fix this
loopback problem so I can access the QNAP/OpenVPN server on its remote
LAN IP? (10.1.1.2)

Cheers



--
"Beat it punk!"
- Clint Eastwood

Re: loopback between tun and eth

[Pascal Hambourg]

Hello,

Al Grant a écrit :
> 
> I have a QNAP NAS which I have setup as a OpenVPN server. The NAS is
> behind a modem/router which is also the gateway to the internet.
> 
> I have a routed OpenVPN connection to the QNAP NAS.
> 
> The QNAP subnet is 10.1.1.0
> The OpenVPN subnet is 10.8.0.0
> My LAN (client) is 192.168.150.0
> 
> In the router on the VPN server LAN I have a static route for 10.8.0.0
> to 10.1.1.2 (QNAP NAS IP and also OpenVPN IP) - so there is a return
> path so to speak for clients on the remote lan when accessed by VPN
> clients.
> 
> The strange issue is that when I connect to the remote LAN I can
> connect to all remote clients using the remote LAN subnet addresses
> (10.1.1.0) *except* for the QNAP iteself (10.1.1.2).

Maybe the filtering rules in the INPUT chain on the NAS do no allow
packets received on the tun interface with a destination address other
than the address of the tun interface.

> Apparently this behavious is due to no loopback connection between the
> tun and eth (someone suggested QNAP did this by design, but I dont
> know why).

Sounds like bullshit. There is no such thing as a "loopback connection"
between network interfaces in the Linux kernel.

> Anyway, the question is - is there a way using iptables I can fix this
> loopback problem so I can access the QNAP/OpenVPN server on its remote
> LAN IP? (10.1.1.2)

Please post the iptables ruleset on the NAS, preferably with
iptables-save or iptables -S if the former is not available.

Re: loopback between tun and eth

[Al Grant]

Hi,

Thanks for the reply. regardless of it "sounding like bullshit" I
still cant access the OpenVPN server on its own LAN IP.

Output of iptables-save is:
[~] # iptables-save
# Generated by iptables-save v1.4.10 on Sun May 19 14:58:57 2013
*filter
:INPUT ACCEPT [206619196:283302919588]
:FORWARD ACCEPT [6447:1950301]
:OUTPUT ACCEPT [41216751:46792057328]
COMMIT
# Completed on Sun May 19 14:58:57 2013
# Generated by iptables-save v1.4.10 on Sun May 19 14:58:57 2013
*nat
:PREROUTING ACCEPT [288171:51079831]
:POSTROUTING ACCEPT [21331:5215305]
:OUTPUT ACCEPT [21201:5208385]
COMMIT
# Completed on Sun May 19 14:58:57 2013
[~] #
Does this help at all? Looks empty to me!

Cheers

-Al



On Fri, May 10, 2013 at 9:28 PM, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> Hello,
>
> Al Grant a écrit :
>>
>> I have a QNAP NAS which I have setup as a OpenVPN server. The NAS is
>> behind a modem/router which is also the gateway to the internet.
>>
>> I have a routed OpenVPN connection to the QNAP NAS.
>>
>> The QNAP subnet is 10.1.1.0
>> The OpenVPN subnet is 10.8.0.0
>> My LAN (client) is 192.168.150.0
>>
>> In the router on the VPN server LAN I have a static route for 10.8.0.0
>> to 10.1.1.2 (QNAP NAS IP and also OpenVPN IP) - so there is a return
>> path so to speak for clients on the remote lan when accessed by VPN
>> clients.
>>
>> The strange issue is that when I connect to the remote LAN I can
>> connect to all remote clients using the remote LAN subnet addresses
>> (10.1.1.0) *except* for the QNAP iteself (10.1.1.2).
>
> Maybe the filtering rules in the INPUT chain on the NAS do no allow
> packets received on the tun interface with a destination address other
> than the address of the tun interface.
>
>> Apparently this behavious is due to no loopback connection between the
>> tun and eth (someone suggested QNAP did this by design, but I dont
>> know why).
>
> Sounds like bullshit. There is no such thing as a "loopback connection"
> between network interfaces in the Linux kernel.
>
>> Anyway, the question is - is there a way using iptables I can fix this
>> loopback problem so I can access the QNAP/OpenVPN server on its remote
>> LAN IP? (10.1.1.2)
>
> Please post the iptables ruleset on the NAS, preferably with
> iptables-save or iptables -S if the former is not available.



-- 
"Beat it punk!"
- Clint Eastwood