Route more traffic through VPN
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
I am using openvpn
to connect to a VPN server, with the following configuration:
remote openvpn.vpn.domain.tld
port 1194
proto udp
dev tun
client
auth-user-pass login.conf
keepalive 10 60
After running openvpn /etc/openvpn/client/myconf.conf
, the output of ip route
is the following:
default via 192.168.1.1 dev wlp2s0 src 192.168.1.25 metric 303
129.31.0.0/16 via 129.31.250.1 dev tun0
129.31.250.0/24 dev tun0 proto kernel scope link src 129.31.250.111
146.169.0.0/16 via 129.31.250.1 dev tun0
146.179.0.0/16 via 129.31.250.1 dev tun0
155.198.0.0/16 via 129.31.250.1 dev tun0
172.16.0.0/12 via 129.31.250.1 dev tun0
192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.25 metric 303
This redirects some of the traffic through the VPN, which is usually enough for my purposes, but sometimes I would like to redirect all the internet traffic. I know that the option redirect gateway def1
in the openvpn
configuration does more or less that, but I would like a more flexible, manual solution. I thought that adding a default route via:
ip route add default via 129.31.250.1 dev tun0
would do that, but when I issue that command my browsers can't load websites anymore, so I suppose that something is wrong with it. Would anyone know where the problem might be coming from?
EDIT: Somehow, using 0.0.0.0/1
instead of default
seems to have fixed the problem⦠If there is a reason why, I would still be interested in learning about it.
openvpn route
add a comment |Â
up vote
0
down vote
favorite
I am using openvpn
to connect to a VPN server, with the following configuration:
remote openvpn.vpn.domain.tld
port 1194
proto udp
dev tun
client
auth-user-pass login.conf
keepalive 10 60
After running openvpn /etc/openvpn/client/myconf.conf
, the output of ip route
is the following:
default via 192.168.1.1 dev wlp2s0 src 192.168.1.25 metric 303
129.31.0.0/16 via 129.31.250.1 dev tun0
129.31.250.0/24 dev tun0 proto kernel scope link src 129.31.250.111
146.169.0.0/16 via 129.31.250.1 dev tun0
146.179.0.0/16 via 129.31.250.1 dev tun0
155.198.0.0/16 via 129.31.250.1 dev tun0
172.16.0.0/12 via 129.31.250.1 dev tun0
192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.25 metric 303
This redirects some of the traffic through the VPN, which is usually enough for my purposes, but sometimes I would like to redirect all the internet traffic. I know that the option redirect gateway def1
in the openvpn
configuration does more or less that, but I would like a more flexible, manual solution. I thought that adding a default route via:
ip route add default via 129.31.250.1 dev tun0
would do that, but when I issue that command my browsers can't load websites anymore, so I suppose that something is wrong with it. Would anyone know where the problem might be coming from?
EDIT: Somehow, using 0.0.0.0/1
instead of default
seems to have fixed the problem⦠If there is a reason why, I would still be interested in learning about it.
openvpn route
Would be nice if you answer your own question, and then set is as solution.
â davidbaumann
Jan 30 at 10:57
Thank you for the suggestion. I'll look into possible causes of this behaviour and will post an answer if I find something interesting.
â Rastapopoulos
Jan 30 at 11:16
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I am using openvpn
to connect to a VPN server, with the following configuration:
remote openvpn.vpn.domain.tld
port 1194
proto udp
dev tun
client
auth-user-pass login.conf
keepalive 10 60
After running openvpn /etc/openvpn/client/myconf.conf
, the output of ip route
is the following:
default via 192.168.1.1 dev wlp2s0 src 192.168.1.25 metric 303
129.31.0.0/16 via 129.31.250.1 dev tun0
129.31.250.0/24 dev tun0 proto kernel scope link src 129.31.250.111
146.169.0.0/16 via 129.31.250.1 dev tun0
146.179.0.0/16 via 129.31.250.1 dev tun0
155.198.0.0/16 via 129.31.250.1 dev tun0
172.16.0.0/12 via 129.31.250.1 dev tun0
192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.25 metric 303
This redirects some of the traffic through the VPN, which is usually enough for my purposes, but sometimes I would like to redirect all the internet traffic. I know that the option redirect gateway def1
in the openvpn
configuration does more or less that, but I would like a more flexible, manual solution. I thought that adding a default route via:
ip route add default via 129.31.250.1 dev tun0
would do that, but when I issue that command my browsers can't load websites anymore, so I suppose that something is wrong with it. Would anyone know where the problem might be coming from?
EDIT: Somehow, using 0.0.0.0/1
instead of default
seems to have fixed the problem⦠If there is a reason why, I would still be interested in learning about it.
openvpn route
I am using openvpn
to connect to a VPN server, with the following configuration:
remote openvpn.vpn.domain.tld
port 1194
proto udp
dev tun
client
auth-user-pass login.conf
keepalive 10 60
After running openvpn /etc/openvpn/client/myconf.conf
, the output of ip route
is the following:
default via 192.168.1.1 dev wlp2s0 src 192.168.1.25 metric 303
129.31.0.0/16 via 129.31.250.1 dev tun0
129.31.250.0/24 dev tun0 proto kernel scope link src 129.31.250.111
146.169.0.0/16 via 129.31.250.1 dev tun0
146.179.0.0/16 via 129.31.250.1 dev tun0
155.198.0.0/16 via 129.31.250.1 dev tun0
172.16.0.0/12 via 129.31.250.1 dev tun0
192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.25 metric 303
This redirects some of the traffic through the VPN, which is usually enough for my purposes, but sometimes I would like to redirect all the internet traffic. I know that the option redirect gateway def1
in the openvpn
configuration does more or less that, but I would like a more flexible, manual solution. I thought that adding a default route via:
ip route add default via 129.31.250.1 dev tun0
would do that, but when I issue that command my browsers can't load websites anymore, so I suppose that something is wrong with it. Would anyone know where the problem might be coming from?
EDIT: Somehow, using 0.0.0.0/1
instead of default
seems to have fixed the problem⦠If there is a reason why, I would still be interested in learning about it.
openvpn route
edited Apr 8 at 16:01
asked Jan 30 at 10:46
Rastapopoulos
518112
518112
Would be nice if you answer your own question, and then set is as solution.
â davidbaumann
Jan 30 at 10:57
Thank you for the suggestion. I'll look into possible causes of this behaviour and will post an answer if I find something interesting.
â Rastapopoulos
Jan 30 at 11:16
add a comment |Â
Would be nice if you answer your own question, and then set is as solution.
â davidbaumann
Jan 30 at 10:57
Thank you for the suggestion. I'll look into possible causes of this behaviour and will post an answer if I find something interesting.
â Rastapopoulos
Jan 30 at 11:16
Would be nice if you answer your own question, and then set is as solution.
â davidbaumann
Jan 30 at 10:57
Would be nice if you answer your own question, and then set is as solution.
â davidbaumann
Jan 30 at 10:57
Thank you for the suggestion. I'll look into possible causes of this behaviour and will post an answer if I find something interesting.
â Rastapopoulos
Jan 30 at 11:16
Thank you for the suggestion. I'll look into possible causes of this behaviour and will post an answer if I find something interesting.
â Rastapopoulos
Jan 30 at 11:16
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
Using "0.0.0.0/1" instead of "default" isn't fixing the problem. At best, it's hiding it.
The problem is that if you set the default route into the tunnel (without having a more specific route to then VPN's endpoint), you are also changing the route that openvpn
uses to connect to the remote endpoint of the VPN. In other words, openvpn no longer knows how to get to the remote VPN endpoint.
You need to set a static route to your remote VPN provider (openvpn.vpn.domain.tld
) to go via your original, non-VPN internet connection.
e.g., assuming that's on interface wlp2s0
:
ip route add openvpn.vpn.domain.tld dev wlp2s0
BTW, you probably also need to set a route (or routes) for your ISP's network(s) and/or any essential services they provide you (e.g. DNS, mail service) to go via that connection too. Your ISP probably only provides those services to IP addresses they own or know are downstream from them (i.e. not to some random IP address owned by some VPN provider on the other side of the world).
1
this is sometimes known (by crude people like me) as the tunnel disappearing up its own backside.
â cas
Jan 30 at 11:57
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
Using "0.0.0.0/1" instead of "default" isn't fixing the problem. At best, it's hiding it.
The problem is that if you set the default route into the tunnel (without having a more specific route to then VPN's endpoint), you are also changing the route that openvpn
uses to connect to the remote endpoint of the VPN. In other words, openvpn no longer knows how to get to the remote VPN endpoint.
You need to set a static route to your remote VPN provider (openvpn.vpn.domain.tld
) to go via your original, non-VPN internet connection.
e.g., assuming that's on interface wlp2s0
:
ip route add openvpn.vpn.domain.tld dev wlp2s0
BTW, you probably also need to set a route (or routes) for your ISP's network(s) and/or any essential services they provide you (e.g. DNS, mail service) to go via that connection too. Your ISP probably only provides those services to IP addresses they own or know are downstream from them (i.e. not to some random IP address owned by some VPN provider on the other side of the world).
1
this is sometimes known (by crude people like me) as the tunnel disappearing up its own backside.
â cas
Jan 30 at 11:57
add a comment |Â
up vote
1
down vote
accepted
Using "0.0.0.0/1" instead of "default" isn't fixing the problem. At best, it's hiding it.
The problem is that if you set the default route into the tunnel (without having a more specific route to then VPN's endpoint), you are also changing the route that openvpn
uses to connect to the remote endpoint of the VPN. In other words, openvpn no longer knows how to get to the remote VPN endpoint.
You need to set a static route to your remote VPN provider (openvpn.vpn.domain.tld
) to go via your original, non-VPN internet connection.
e.g., assuming that's on interface wlp2s0
:
ip route add openvpn.vpn.domain.tld dev wlp2s0
BTW, you probably also need to set a route (or routes) for your ISP's network(s) and/or any essential services they provide you (e.g. DNS, mail service) to go via that connection too. Your ISP probably only provides those services to IP addresses they own or know are downstream from them (i.e. not to some random IP address owned by some VPN provider on the other side of the world).
1
this is sometimes known (by crude people like me) as the tunnel disappearing up its own backside.
â cas
Jan 30 at 11:57
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
Using "0.0.0.0/1" instead of "default" isn't fixing the problem. At best, it's hiding it.
The problem is that if you set the default route into the tunnel (without having a more specific route to then VPN's endpoint), you are also changing the route that openvpn
uses to connect to the remote endpoint of the VPN. In other words, openvpn no longer knows how to get to the remote VPN endpoint.
You need to set a static route to your remote VPN provider (openvpn.vpn.domain.tld
) to go via your original, non-VPN internet connection.
e.g., assuming that's on interface wlp2s0
:
ip route add openvpn.vpn.domain.tld dev wlp2s0
BTW, you probably also need to set a route (or routes) for your ISP's network(s) and/or any essential services they provide you (e.g. DNS, mail service) to go via that connection too. Your ISP probably only provides those services to IP addresses they own or know are downstream from them (i.e. not to some random IP address owned by some VPN provider on the other side of the world).
Using "0.0.0.0/1" instead of "default" isn't fixing the problem. At best, it's hiding it.
The problem is that if you set the default route into the tunnel (without having a more specific route to then VPN's endpoint), you are also changing the route that openvpn
uses to connect to the remote endpoint of the VPN. In other words, openvpn no longer knows how to get to the remote VPN endpoint.
You need to set a static route to your remote VPN provider (openvpn.vpn.domain.tld
) to go via your original, non-VPN internet connection.
e.g., assuming that's on interface wlp2s0
:
ip route add openvpn.vpn.domain.tld dev wlp2s0
BTW, you probably also need to set a route (or routes) for your ISP's network(s) and/or any essential services they provide you (e.g. DNS, mail service) to go via that connection too. Your ISP probably only provides those services to IP addresses they own or know are downstream from them (i.e. not to some random IP address owned by some VPN provider on the other side of the world).
answered Jan 30 at 11:55
cas
37.7k44393
37.7k44393
1
this is sometimes known (by crude people like me) as the tunnel disappearing up its own backside.
â cas
Jan 30 at 11:57
add a comment |Â
1
this is sometimes known (by crude people like me) as the tunnel disappearing up its own backside.
â cas
Jan 30 at 11:57
1
1
this is sometimes known (by crude people like me) as the tunnel disappearing up its own backside.
â cas
Jan 30 at 11:57
this is sometimes known (by crude people like me) as the tunnel disappearing up its own backside.
â cas
Jan 30 at 11:57
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f420633%2froute-more-traffic-through-vpn%23new-answer', 'question_page');
);
Post as a guest
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
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
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
Would be nice if you answer your own question, and then set is as solution.
â davidbaumann
Jan 30 at 10:57
Thank you for the suggestion. I'll look into possible causes of this behaviour and will post an answer if I find something interesting.
â Rastapopoulos
Jan 30 at 11:16