How to enable LAN access to OpenVPN clients
up vote
0
down vote
favorite
I have a server with 2 real NIC and 1 virtual NIC (tun0) created by OpenVPN.
eth0 is LAN - IP 192.168.2.1
eth1 is Internet - IP is public internet IP
tun0 is created by openvpn
What I need is that clients that connect to VPN server over eth1 will also get access to eth0 network, eg. will be able to connect to 192.168.2.21
This used to work in past until I rebooted the server and routing info got reset :/ I configured this couple years ago and forgot how I did that.
Routing table now looks like this:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default public gw 0.0.0.0 UG 0 0 0 eth1
public ip * 255.255.255.0 U 0 0 0 eth1
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
192.168.8.0 192.168.8.2 255.255.255.0 UG 0 0 0 tun0
192.168.8.2 * 255.255.255.255 UH 0 0 0 tun0
When I launch OpenVPN it tries to add route
Tue Oct 11 19:29:58 2016 /sbin/ip route add 192.168.2.0/24 via 192.168.8.2
RTNETLINK answers: File exists
Tue Oct 11 19:29:58 2016 ERROR: Linux route add command failed: external program exited with error status: 2
It however doesn't seem to be possible because it already exists. When I remove this route openVPN succeeds in adding but it's no longer possible for server to reach 192.168.2.0/24 network.
How can I make it work?
EDIT: yes, I have both IPv4 and IPv6 forwarding enabled
networking openvpn
asked Oct 11 '16 at 17:54
Petr
66621326
add a comment |
up vote
0
down vote
favorite
I have a server with 2 real NIC and 1 virtual NIC (tun0) created by OpenVPN.
eth0 is LAN - IP 192.168.2.1
eth1 is Internet - IP is public internet IP
tun0 is created by openvpn
What I need is that clients that connect to VPN server over eth1 will also get access to eth0 network, eg. will be able to connect to 192.168.2.21
This used to work in past until I rebooted the server and routing info got reset :/ I configured this couple years ago and forgot how I did that.
Routing table now looks like this:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default public gw 0.0.0.0 UG 0 0 0 eth1
public ip * 255.255.255.0 U 0 0 0 eth1
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
192.168.8.0 192.168.8.2 255.255.255.0 UG 0 0 0 tun0
192.168.8.2 * 255.255.255.255 UH 0 0 0 tun0
When I launch OpenVPN it tries to add route
Tue Oct 11 19:29:58 2016 /sbin/ip route add 192.168.2.0/24 via 192.168.8.2
RTNETLINK answers: File exists
Tue Oct 11 19:29:58 2016 ERROR: Linux route add command failed: external program exited with error status: 2
It however doesn't seem to be possible because it already exists. When I remove this route openVPN succeeds in adding but it's no longer possible for server to reach 192.168.2.0/24 network.
How can I make it work?
EDIT: yes, I have both IPv4 and IPv6 forwarding enabled
networking openvpn
asked Oct 11 '16 at 17:54
Petr
66621326
Your question isn’t entirely clear on what happens where: VPN server or client. Please clarify. Also, for this to work, all machines on the192.168.2.0/24network need to know that192.168.8.0/24(the VPN subnet, I assume) is reachable via192.168.2.1. If192.168.2.1is not the default gateway, you should set up a route on the default gateway.
– Daniel B
Oct 12 '16 at 8:31
@DanielB this what I describe here is server, which is also a gateway itself, it's DNS, DHCP and router for LAN and it also hosts that 192.168.8.0 subnet for VPN. This all used to work until I rebooted it, so there is no problem on client side. VPN client already pushes route to client, the problem is that the VPN server doesn't seem to allow machines from 192.168.8.0 to access 192.168.2.0 network
– Petr
Oct 12 '16 at 11:14
You misunderstand: A route needs to exist both ways for packets to go through both ways. You can easily verify whether packets are received using Wireshark. // Also, you automatically get a route to the subnet of an adapter’s IP address. Always.
– Daniel B
Oct 12 '16 at 13:49
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have a server with 2 real NIC and 1 virtual NIC (tun0) created by OpenVPN.
eth0 is LAN - IP 192.168.2.1
eth1 is Internet - IP is public internet IP
tun0 is created by openvpn
What I need is that clients that connect to VPN server over eth1 will also get access to eth0 network, eg. will be able to connect to 192.168.2.21
This used to work in past until I rebooted the server and routing info got reset :/ I configured this couple years ago and forgot how I did that.
Routing table now looks like this:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default public gw 0.0.0.0 UG 0 0 0 eth1
public ip * 255.255.255.0 U 0 0 0 eth1
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
192.168.8.0 192.168.8.2 255.255.255.0 UG 0 0 0 tun0
192.168.8.2 * 255.255.255.255 UH 0 0 0 tun0
When I launch OpenVPN it tries to add route
Tue Oct 11 19:29:58 2016 /sbin/ip route add 192.168.2.0/24 via 192.168.8.2
RTNETLINK answers: File exists
Tue Oct 11 19:29:58 2016 ERROR: Linux route add command failed: external program exited with error status: 2
It however doesn't seem to be possible because it already exists. When I remove this route openVPN succeeds in adding but it's no longer possible for server to reach 192.168.2.0/24 network.
How can I make it work?
EDIT: yes, I have both IPv4 and IPv6 forwarding enabled
networking openvpn
asked Oct 11 '16 at 17:54
Petr
66621326
I have a server with 2 real NIC and 1 virtual NIC (tun0) created by OpenVPN.
eth0 is LAN - IP 192.168.2.1
eth1 is Internet - IP is public internet IP
tun0 is created by openvpn
What I need is that clients that connect to VPN server over eth1 will also get access to eth0 network, eg. will be able to connect to 192.168.2.21
This used to work in past until I rebooted the server and routing info got reset :/ I configured this couple years ago and forgot how I did that.
Routing table now looks like this:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default public gw 0.0.0.0 UG 0 0 0 eth1
public ip * 255.255.255.0 U 0 0 0 eth1
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
192.168.8.0 192.168.8.2 255.255.255.0 UG 0 0 0 tun0
192.168.8.2 * 255.255.255.255 UH 0 0 0 tun0
When I launch OpenVPN it tries to add route
Tue Oct 11 19:29:58 2016 /sbin/ip route add 192.168.2.0/24 via 192.168.8.2
RTNETLINK answers: File exists
Tue Oct 11 19:29:58 2016 ERROR: Linux route add command failed: external program exited with error status: 2
It however doesn't seem to be possible because it already exists. When I remove this route openVPN succeeds in adding but it's no longer possible for server to reach 192.168.2.0/24 network.
How can I make it work?
EDIT: yes, I have both IPv4 and IPv6 forwarding enabled
networking openvpn
networking openvpn
asked Oct 11 '16 at 17:54
Petr
66621326
asked Oct 11 '16 at 17:54
Petr
66621326
edited Oct 12 '16 at 8:09
asked Oct 11 '16 at 17:54
Petr
66621326
asked Oct 11 '16 at 17:54
Petr
66621326
asked Oct 11 '16 at 17:54
Petr
66621326
66621326
Your question isn’t entirely clear on what happens where: VPN server or client. Please clarify. Also, for this to work, all machines on the192.168.2.0/24network need to know that192.168.8.0/24(the VPN subnet, I assume) is reachable via192.168.2.1. If192.168.2.1is not the default gateway, you should set up a route on the default gateway.
– Daniel B
Oct 12 '16 at 8:31
@DanielB this what I describe here is server, which is also a gateway itself, it's DNS, DHCP and router for LAN and it also hosts that 192.168.8.0 subnet for VPN. This all used to work until I rebooted it, so there is no problem on client side. VPN client already pushes route to client, the problem is that the VPN server doesn't seem to allow machines from 192.168.8.0 to access 192.168.2.0 network
– Petr
Oct 12 '16 at 11:14
You misunderstand: A route needs to exist both ways for packets to go through both ways. You can easily verify whether packets are received using Wireshark. // Also, you automatically get a route to the subnet of an adapter’s IP address. Always.
– Daniel B
Oct 12 '16 at 13:49
add a comment |
Your question isn’t entirely clear on what happens where: VPN server or client. Please clarify. Also, for this to work, all machines on the192.168.2.0/24network need to know that192.168.8.0/24(the VPN subnet, I assume) is reachable via192.168.2.1. If192.168.2.1is not the default gateway, you should set up a route on the default gateway.
– Daniel B
Oct 12 '16 at 8:31
@DanielB this what I describe here is server, which is also a gateway itself, it's DNS, DHCP and router for LAN and it also hosts that 192.168.8.0 subnet for VPN. This all used to work until I rebooted it, so there is no problem on client side. VPN client already pushes route to client, the problem is that the VPN server doesn't seem to allow machines from 192.168.8.0 to access 192.168.2.0 network
– Petr
Oct 12 '16 at 11:14
You misunderstand: A route needs to exist both ways for packets to go through both ways. You can easily verify whether packets are received using Wireshark. // Also, you automatically get a route to the subnet of an adapter’s IP address. Always.
– Daniel B
Oct 12 '16 at 13:49
Your question isn’t entirely clear on what happens where: VPN server or client. Please clarify. Also, for this to work, all machines on the
192.168.2.0/24 network need to know that 192.168.8.0/24 (the VPN subnet, I assume) is reachable via 192.168.2.1. If 192.168.2.1 is not the default gateway, you should set up a route on the default gateway.– Daniel B
Oct 12 '16 at 8:31
Your question isn’t entirely clear on what happens where: VPN server or client. Please clarify. Also, for this to work, all machines on the
192.168.2.0/24 network need to know that 192.168.8.0/24 (the VPN subnet, I assume) is reachable via 192.168.2.1. If 192.168.2.1 is not the default gateway, you should set up a route on the default gateway.– Daniel B
Oct 12 '16 at 8:31
@DanielB this what I describe here is server, which is also a gateway itself, it's DNS, DHCP and router for LAN and it also hosts that 192.168.8.0 subnet for VPN. This all used to work until I rebooted it, so there is no problem on client side. VPN client already pushes route to client, the problem is that the VPN server doesn't seem to allow machines from 192.168.8.0 to access 192.168.2.0 network
– Petr
Oct 12 '16 at 11:14
@DanielB this what I describe here is server, which is also a gateway itself, it's DNS, DHCP and router for LAN and it also hosts that 192.168.8.0 subnet for VPN. This all used to work until I rebooted it, so there is no problem on client side. VPN client already pushes route to client, the problem is that the VPN server doesn't seem to allow machines from 192.168.8.0 to access 192.168.2.0 network
– Petr
Oct 12 '16 at 11:14
You misunderstand: A route needs to exist both ways for packets to go through both ways. You can easily verify whether packets are received using Wireshark. // Also, you automatically get a route to the subnet of an adapter’s IP address. Always.
– Daniel B
Oct 12 '16 at 13:49
You misunderstand: A route needs to exist both ways for packets to go through both ways. You can easily verify whether packets are received using Wireshark. // Also, you automatically get a route to the subnet of an adapter’s IP address. Always.
– Daniel B
Oct 12 '16 at 13:49
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
you'll need ip_forward set in the sysctl, and an accept line in the FORWARD table in iptables (which often defaults to ACCEPT anyhow)
http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/
answered Oct 11 '16 at 20:07
Sirex
9,68343252
I already have that, that isn't the issue here.
– Petr
Oct 12 '16 at 8:08
yeah, you'll also need the masquerade line from that link.
– Sirex
Oct 12 '16 at 18:45
MASQUERADEis only needed when a fully routed setup is not possible. It is possible, so it shouldn’t be used.
– Daniel B
Oct 13 '16 at 11:23
add a comment |
up vote
0
down vote
First, the necessary routes:
- VPN clients need a route to
192.168.2.0/24, via your VPN gateway (presumably at192.168.8.1inside the virtual network) - Devices in
192.168.2.0/24need a route to192.168.8.0/24– because it appears your VPN server resides on the default gateway, additional configuration is not required.
Then, the configuration. The specifics depend on the topology (net30/p2p or subnet), but it’s like this in general:
topology net30
server 192.168.8.0 255.255.255.0
push "route 192.168.2.0 255.255.255.0"
I omitted all irrelevant (but nonetheless mandatory) options here. Do note however that the route is only pushed to clients. It must not be set on the server.
Since the client receives all necessary settings via push, no special configuration is needed.
answered Oct 13 '16 at 18:08
Daniel B
32.9k75986
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
you'll need ip_forward set in the sysctl, and an accept line in the FORWARD table in iptables (which often defaults to ACCEPT anyhow)
http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/
answered Oct 11 '16 at 20:07
Sirex
9,68343252
I already have that, that isn't the issue here.
– Petr
Oct 12 '16 at 8:08
yeah, you'll also need the masquerade line from that link.
– Sirex
Oct 12 '16 at 18:45
MASQUERADEis only needed when a fully routed setup is not possible. It is possible, so it shouldn’t be used.
– Daniel B
Oct 13 '16 at 11:23
add a comment |
up vote
0
down vote
you'll need ip_forward set in the sysctl, and an accept line in the FORWARD table in iptables (which often defaults to ACCEPT anyhow)
http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/
answered Oct 11 '16 at 20:07
Sirex
9,68343252
I already have that, that isn't the issue here.
– Petr
Oct 12 '16 at 8:08
yeah, you'll also need the masquerade line from that link.
– Sirex
Oct 12 '16 at 18:45
MASQUERADEis only needed when a fully routed setup is not possible. It is possible, so it shouldn’t be used.
– Daniel B
Oct 13 '16 at 11:23
add a comment |
up vote
0
down vote
up vote
0
down vote
you'll need ip_forward set in the sysctl, and an accept line in the FORWARD table in iptables (which often defaults to ACCEPT anyhow)
http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/
answered Oct 11 '16 at 20:07
Sirex
9,68343252
you'll need ip_forward set in the sysctl, and an accept line in the FORWARD table in iptables (which often defaults to ACCEPT anyhow)
http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/
answered Oct 11 '16 at 20:07
Sirex
9,68343252
answered Oct 11 '16 at 20:07
Sirex
9,68343252
answered Oct 11 '16 at 20:07
Sirex
9,68343252
answered Oct 11 '16 at 20:07
Sirex
9,68343252
9,68343252
I already have that, that isn't the issue here.
– Petr
Oct 12 '16 at 8:08
yeah, you'll also need the masquerade line from that link.
– Sirex
Oct 12 '16 at 18:45
MASQUERADEis only needed when a fully routed setup is not possible. It is possible, so it shouldn’t be used.
– Daniel B
Oct 13 '16 at 11:23
add a comment |
I already have that, that isn't the issue here.
– Petr
Oct 12 '16 at 8:08
yeah, you'll also need the masquerade line from that link.
– Sirex
Oct 12 '16 at 18:45
MASQUERADEis only needed when a fully routed setup is not possible. It is possible, so it shouldn’t be used.
– Daniel B
Oct 13 '16 at 11:23
I already have that, that isn't the issue here.
– Petr
Oct 12 '16 at 8:08
I already have that, that isn't the issue here.
– Petr
Oct 12 '16 at 8:08
yeah, you'll also need the masquerade line from that link.
– Sirex
Oct 12 '16 at 18:45
yeah, you'll also need the masquerade line from that link.
– Sirex
Oct 12 '16 at 18:45
MASQUERADE is only needed when a fully routed setup is not possible. It is possible, so it shouldn’t be used.– Daniel B
Oct 13 '16 at 11:23
MASQUERADE is only needed when a fully routed setup is not possible. It is possible, so it shouldn’t be used.– Daniel B
Oct 13 '16 at 11:23
add a comment |
up vote
0
down vote
First, the necessary routes:
- VPN clients need a route to
192.168.2.0/24, via your VPN gateway (presumably at192.168.8.1inside the virtual network) - Devices in
192.168.2.0/24need a route to192.168.8.0/24– because it appears your VPN server resides on the default gateway, additional configuration is not required.
Then, the configuration. The specifics depend on the topology (net30/p2p or subnet), but it’s like this in general:
topology net30
server 192.168.8.0 255.255.255.0
push "route 192.168.2.0 255.255.255.0"
I omitted all irrelevant (but nonetheless mandatory) options here. Do note however that the route is only pushed to clients. It must not be set on the server.
Since the client receives all necessary settings via push, no special configuration is needed.
answered Oct 13 '16 at 18:08
Daniel B
32.9k75986
add a comment |
up vote
0
down vote
First, the necessary routes:
- VPN clients need a route to
192.168.2.0/24, via your VPN gateway (presumably at192.168.8.1inside the virtual network) - Devices in
192.168.2.0/24need a route to192.168.8.0/24– because it appears your VPN server resides on the default gateway, additional configuration is not required.
Then, the configuration. The specifics depend on the topology (net30/p2p or subnet), but it’s like this in general:
topology net30
server 192.168.8.0 255.255.255.0
push "route 192.168.2.0 255.255.255.0"
I omitted all irrelevant (but nonetheless mandatory) options here. Do note however that the route is only pushed to clients. It must not be set on the server.
Since the client receives all necessary settings via push, no special configuration is needed.
answered Oct 13 '16 at 18:08
Daniel B
32.9k75986
add a comment |
up vote
0
down vote
up vote
0
down vote
First, the necessary routes:
- VPN clients need a route to
192.168.2.0/24, via your VPN gateway (presumably at192.168.8.1inside the virtual network) - Devices in
192.168.2.0/24need a route to192.168.8.0/24– because it appears your VPN server resides on the default gateway, additional configuration is not required.
Then, the configuration. The specifics depend on the topology (net30/p2p or subnet), but it’s like this in general:
topology net30
server 192.168.8.0 255.255.255.0
push "route 192.168.2.0 255.255.255.0"
I omitted all irrelevant (but nonetheless mandatory) options here. Do note however that the route is only pushed to clients. It must not be set on the server.
Since the client receives all necessary settings via push, no special configuration is needed.
answered Oct 13 '16 at 18:08
Daniel B
32.9k75986
First, the necessary routes:
- VPN clients need a route to
192.168.2.0/24, via your VPN gateway (presumably at192.168.8.1inside the virtual network) - Devices in
192.168.2.0/24need a route to192.168.8.0/24– because it appears your VPN server resides on the default gateway, additional configuration is not required.
Then, the configuration. The specifics depend on the topology (net30/p2p or subnet), but it’s like this in general:
topology net30
server 192.168.8.0 255.255.255.0
push "route 192.168.2.0 255.255.255.0"
I omitted all irrelevant (but nonetheless mandatory) options here. Do note however that the route is only pushed to clients. It must not be set on the server.
Since the client receives all necessary settings via push, no special configuration is needed.
answered Oct 13 '16 at 18:08
Daniel B
32.9k75986
answered Oct 13 '16 at 18:08
Daniel B
32.9k75986
answered Oct 13 '16 at 18:08
Daniel B
32.9k75986
answered Oct 13 '16 at 18:08
Daniel B
32.9k75986
32.9k75986
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1133752%2fhow-to-enable-lan-access-to-openvpn-clients%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Your question isn’t entirely clear on what happens where: VPN server or client. Please clarify. Also, for this to work, all machines on the
192.168.2.0/24network need to know that192.168.8.0/24(the VPN subnet, I assume) is reachable via192.168.2.1. If192.168.2.1is not the default gateway, you should set up a route on the default gateway.– Daniel B
Oct 12 '16 at 8:31
@DanielB this what I describe here is server, which is also a gateway itself, it's DNS, DHCP and router for LAN and it also hosts that 192.168.8.0 subnet for VPN. This all used to work until I rebooted it, so there is no problem on client side. VPN client already pushes route to client, the problem is that the VPN server doesn't seem to allow machines from 192.168.8.0 to access 192.168.2.0 network
– Petr
Oct 12 '16 at 11:14
You misunderstand: A route needs to exist both ways for packets to go through both ways. You can easily verify whether packets are received using Wireshark. // Also, you automatically get a route to the subnet of an adapter’s IP address. Always.
– Daniel B
Oct 12 '16 at 13:49