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. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
