* loopback between tun and eth
@ 2013-05-09 6:12 Al Grant
2013-05-10 9:28 ` Pascal Hambourg
0 siblings, 1 reply; 3+ messages in thread
From: Al Grant @ 2013-05-09 6:12 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: loopback between tun and eth
2013-05-09 6:12 loopback between tun and eth Al Grant
@ 2013-05-10 9:28 ` Pascal Hambourg
2013-05-19 2:59 ` Al Grant
0 siblings, 1 reply; 3+ messages in thread
From: Pascal Hambourg @ 2013-05-10 9:28 UTC (permalink / raw)
To: Al Grant; +Cc: netfilter
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: loopback between tun and eth
2013-05-10 9:28 ` Pascal Hambourg
@ 2013-05-19 2:59 ` Al Grant
0 siblings, 0 replies; 3+ messages in thread
From: Al Grant @ 2013-05-19 2:59 UTC (permalink / raw)
To: Pascal Hambourg; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-05-19 2:59 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-09 6:12 loopback between tun and eth Al Grant
2013-05-10 9:28 ` Pascal Hambourg
2013-05-19 2:59 ` Al Grant
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.