How does an OpenVPN tune in all the traffic going into tun0?
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
First of all, I understand that the kernel routing table makes all the outbound traffic forwarded to tun0. However, they're NOT going to the IP address that the local tun0 interface has (e.g., 10.13.10.6), rather to the destination address (e.g., 10.13.10.5). In this case, how does an OpenVPN hook into all the traffic going to tun0? As I heard, something called a raw socket is involved, but I want to understand how specifically it ensures this behavior.
networking routing openvpn vpn socket
asked Jul 12 at 13:52
b1sub
1033
add a comment |Â
up vote
0
down vote
favorite
First of all, I understand that the kernel routing table makes all the outbound traffic forwarded to tun0. However, they're NOT going to the IP address that the local tun0 interface has (e.g., 10.13.10.6), rather to the destination address (e.g., 10.13.10.5). In this case, how does an OpenVPN hook into all the traffic going to tun0? As I heard, something called a raw socket is involved, but I want to understand how specifically it ensures this behavior.
networking routing openvpn vpn socket
asked Jul 12 at 13:52
b1sub
1033
1
How is routing packets viatun0different from routing any packets via e.g.eth0? These will usually also not have an IP on that interface as destination address. So what exactly confuses you? Did you read up on how TUN devices work?
– ecdsa
Jul 12 at 14:27
@ecdsa I wonder in which method an OpenVPN can suck in all the traffic going totun0. My kernel routing table shows that all outbound traffic goes to10.13.10.5, but mytun0's IP address is10.13.10.6. In short, I'm curious how an OpenVPN can intercepts all the packets going to the another IP address.
– b1sub
Jul 12 at 14:40
1
As I already suggested, you should read up on how TUN/TAP devices work. Maybe that clears things up.
– ecdsa
Jul 12 at 15:43
@ecdsa Thank you for the link. As you already expected, not completely understanding how tun/tap interfaces work was the source of my confusion. Have a nice day!
– b1sub
Jul 12 at 16:05
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
First of all, I understand that the kernel routing table makes all the outbound traffic forwarded to tun0. However, they're NOT going to the IP address that the local tun0 interface has (e.g., 10.13.10.6), rather to the destination address (e.g., 10.13.10.5). In this case, how does an OpenVPN hook into all the traffic going to tun0? As I heard, something called a raw socket is involved, but I want to understand how specifically it ensures this behavior.
networking routing openvpn vpn socket
asked Jul 12 at 13:52
b1sub
1033
First of all, I understand that the kernel routing table makes all the outbound traffic forwarded to tun0. However, they're NOT going to the IP address that the local tun0 interface has (e.g., 10.13.10.6), rather to the destination address (e.g., 10.13.10.5). In this case, how does an OpenVPN hook into all the traffic going to tun0? As I heard, something called a raw socket is involved, but I want to understand how specifically it ensures this behavior.
networking routing openvpn vpn socket
asked Jul 12 at 13:52
b1sub
1033
asked Jul 12 at 13:52
b1sub
1033
asked Jul 12 at 13:52
b1sub
1033
asked Jul 12 at 13:52
b1sub
1033
1033
1
How is routing packets viatun0different from routing any packets via e.g.eth0? These will usually also not have an IP on that interface as destination address. So what exactly confuses you? Did you read up on how TUN devices work?
– ecdsa
Jul 12 at 14:27
@ecdsa I wonder in which method an OpenVPN can suck in all the traffic going totun0. My kernel routing table shows that all outbound traffic goes to10.13.10.5, but mytun0's IP address is10.13.10.6. In short, I'm curious how an OpenVPN can intercepts all the packets going to the another IP address.
– b1sub
Jul 12 at 14:40
1
As I already suggested, you should read up on how TUN/TAP devices work. Maybe that clears things up.
– ecdsa
Jul 12 at 15:43
@ecdsa Thank you for the link. As you already expected, not completely understanding how tun/tap interfaces work was the source of my confusion. Have a nice day!
– b1sub
Jul 12 at 16:05
add a comment |Â
1
How is routing packets viatun0different from routing any packets via e.g.eth0? These will usually also not have an IP on that interface as destination address. So what exactly confuses you? Did you read up on how TUN devices work?
– ecdsa
Jul 12 at 14:27
@ecdsa I wonder in which method an OpenVPN can suck in all the traffic going totun0. My kernel routing table shows that all outbound traffic goes to10.13.10.5, but mytun0's IP address is10.13.10.6. In short, I'm curious how an OpenVPN can intercepts all the packets going to the another IP address.
– b1sub
Jul 12 at 14:40
1
As I already suggested, you should read up on how TUN/TAP devices work. Maybe that clears things up.
– ecdsa
Jul 12 at 15:43
@ecdsa Thank you for the link. As you already expected, not completely understanding how tun/tap interfaces work was the source of my confusion. Have a nice day!
– b1sub
Jul 12 at 16:05
1
1
How is routing packets via
tun0 different from routing any packets via e.g. eth0? These will usually also not have an IP on that interface as destination address. So what exactly confuses you? Did you read up on how TUN devices work?– ecdsa
Jul 12 at 14:27
How is routing packets via
tun0 different from routing any packets via e.g. eth0? These will usually also not have an IP on that interface as destination address. So what exactly confuses you? Did you read up on how TUN devices work?– ecdsa
Jul 12 at 14:27
@ecdsa I wonder in which method an OpenVPN can suck in all the traffic going to
tun0. My kernel routing table shows that all outbound traffic goes to 10.13.10.5, but my tun0's IP address is 10.13.10.6. In short, I'm curious how an OpenVPN can intercepts all the packets going to the another IP address.– b1sub
Jul 12 at 14:40
@ecdsa I wonder in which method an OpenVPN can suck in all the traffic going to
tun0. My kernel routing table shows that all outbound traffic goes to 10.13.10.5, but my tun0's IP address is 10.13.10.6. In short, I'm curious how an OpenVPN can intercepts all the packets going to the another IP address.– b1sub
Jul 12 at 14:40
1
1
As I already suggested, you should read up on how TUN/TAP devices work. Maybe that clears things up.
– ecdsa
Jul 12 at 15:43
As I already suggested, you should read up on how TUN/TAP devices work. Maybe that clears things up.
– ecdsa
Jul 12 at 15:43
@ecdsa Thank you for the link. As you already expected, not completely understanding how tun/tap interfaces work was the source of my confusion. Have a nice day!
– b1sub
Jul 12 at 16:05
@ecdsa Thank you for the link. As you already expected, not completely understanding how tun/tap interfaces work was the source of my confusion. Have a nice day!
– b1sub
Jul 12 at 16:05
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
Look again at the routing table (ip route). You'll notice there's either a default route to 10.13.10.5, or a pair of 0.0.0.0/1/128.0.0.0/1 routes to 10.13.10.5 (which is just a trick that allows OpenVPN to keep the default route, though it becomes inactive), and this route goes via tun0.
It doesn't matter what IP tun0 has, what matters is the gateway IP, which happens to be 10.13.10.5 and is on the other side of tun0.
So how does OpenVPN make all traffic go into tun0? By providing routes, just like without OpenVPN all traffic goes to eth0 (or wlan0, or whateever the default route says).
OpenVPN doesn't do anything special. In particular, it doesn't use a raw socket, it creates a tun/tap interface.
Edit
OpenVPN doesn't "listen for traffic bound to the other end".
When the Linux kernel sees a network packet, it consults the routing table to decide what to do with the packet. If the routing table says "send all packets to gateway 10.13.10.5 via tun0", then that's what the Linux kernel does. OpenVPN is not involved in any way in this.
Now OpenVPN has created tun0, so what happens when the kernel puts a packet into tun0 is that OpenVPN can read this packet. That's what a tun/tap interface does: It allows an application to read packets put into this interface (by the kernel), and also to write packets which will get emitted from this interface (which will also be handled like the kernel, just as if the packet came from a real network card).
No promiscous mode involved. Is the problem that you don't understand how the tun/tap interface works?
answered Jul 12 at 15:25
dirkt
13.8k2930
Thank you for the edit. Yes. I was not completely sure how exactly tun/tap interfaces work. I sort of expected it to behave like a normal Ethernet interface. Thanks to the comments by @ecdsa and your answer, I got the idea and I should certainly look into the tun/tap documentation.
– b1sub
Jul 12 at 15:59
Well, tun/tap sort of behaves like a normal Ethernet interface - the only difference is that instead of the packet getting handed down to the kernel driver, which talks to the hardware and tells it to send out the packet on the LAN/WLAN, the packet will be handed to OpenVPN (or whatever application created the tun/tap interface).
– dirkt
Jul 12 at 19:24
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
Look again at the routing table (ip route). You'll notice there's either a default route to 10.13.10.5, or a pair of 0.0.0.0/1/128.0.0.0/1 routes to 10.13.10.5 (which is just a trick that allows OpenVPN to keep the default route, though it becomes inactive), and this route goes via tun0.
It doesn't matter what IP tun0 has, what matters is the gateway IP, which happens to be 10.13.10.5 and is on the other side of tun0.
So how does OpenVPN make all traffic go into tun0? By providing routes, just like without OpenVPN all traffic goes to eth0 (or wlan0, or whateever the default route says).
OpenVPN doesn't do anything special. In particular, it doesn't use a raw socket, it creates a tun/tap interface.
Edit
OpenVPN doesn't "listen for traffic bound to the other end".
When the Linux kernel sees a network packet, it consults the routing table to decide what to do with the packet. If the routing table says "send all packets to gateway 10.13.10.5 via tun0", then that's what the Linux kernel does. OpenVPN is not involved in any way in this.
Now OpenVPN has created tun0, so what happens when the kernel puts a packet into tun0 is that OpenVPN can read this packet. That's what a tun/tap interface does: It allows an application to read packets put into this interface (by the kernel), and also to write packets which will get emitted from this interface (which will also be handled like the kernel, just as if the packet came from a real network card).
No promiscous mode involved. Is the problem that you don't understand how the tun/tap interface works?
answered Jul 12 at 15:25
dirkt
13.8k2930
Thank you for the edit. Yes. I was not completely sure how exactly tun/tap interfaces work. I sort of expected it to behave like a normal Ethernet interface. Thanks to the comments by @ecdsa and your answer, I got the idea and I should certainly look into the tun/tap documentation.
– b1sub
Jul 12 at 15:59
Well, tun/tap sort of behaves like a normal Ethernet interface - the only difference is that instead of the packet getting handed down to the kernel driver, which talks to the hardware and tells it to send out the packet on the LAN/WLAN, the packet will be handed to OpenVPN (or whatever application created the tun/tap interface).
– dirkt
Jul 12 at 19:24
add a comment |Â
up vote
1
down vote
accepted
Look again at the routing table (ip route). You'll notice there's either a default route to 10.13.10.5, or a pair of 0.0.0.0/1/128.0.0.0/1 routes to 10.13.10.5 (which is just a trick that allows OpenVPN to keep the default route, though it becomes inactive), and this route goes via tun0.
It doesn't matter what IP tun0 has, what matters is the gateway IP, which happens to be 10.13.10.5 and is on the other side of tun0.
So how does OpenVPN make all traffic go into tun0? By providing routes, just like without OpenVPN all traffic goes to eth0 (or wlan0, or whateever the default route says).
OpenVPN doesn't do anything special. In particular, it doesn't use a raw socket, it creates a tun/tap interface.
Edit
OpenVPN doesn't "listen for traffic bound to the other end".
When the Linux kernel sees a network packet, it consults the routing table to decide what to do with the packet. If the routing table says "send all packets to gateway 10.13.10.5 via tun0", then that's what the Linux kernel does. OpenVPN is not involved in any way in this.
Now OpenVPN has created tun0, so what happens when the kernel puts a packet into tun0 is that OpenVPN can read this packet. That's what a tun/tap interface does: It allows an application to read packets put into this interface (by the kernel), and also to write packets which will get emitted from this interface (which will also be handled like the kernel, just as if the packet came from a real network card).
No promiscous mode involved. Is the problem that you don't understand how the tun/tap interface works?
answered Jul 12 at 15:25
dirkt
13.8k2930
Thank you for the edit. Yes. I was not completely sure how exactly tun/tap interfaces work. I sort of expected it to behave like a normal Ethernet interface. Thanks to the comments by @ecdsa and your answer, I got the idea and I should certainly look into the tun/tap documentation.
– b1sub
Jul 12 at 15:59
Well, tun/tap sort of behaves like a normal Ethernet interface - the only difference is that instead of the packet getting handed down to the kernel driver, which talks to the hardware and tells it to send out the packet on the LAN/WLAN, the packet will be handed to OpenVPN (or whatever application created the tun/tap interface).
– dirkt
Jul 12 at 19:24
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
Look again at the routing table (ip route). You'll notice there's either a default route to 10.13.10.5, or a pair of 0.0.0.0/1/128.0.0.0/1 routes to 10.13.10.5 (which is just a trick that allows OpenVPN to keep the default route, though it becomes inactive), and this route goes via tun0.
It doesn't matter what IP tun0 has, what matters is the gateway IP, which happens to be 10.13.10.5 and is on the other side of tun0.
So how does OpenVPN make all traffic go into tun0? By providing routes, just like without OpenVPN all traffic goes to eth0 (or wlan0, or whateever the default route says).
OpenVPN doesn't do anything special. In particular, it doesn't use a raw socket, it creates a tun/tap interface.
Edit
OpenVPN doesn't "listen for traffic bound to the other end".
When the Linux kernel sees a network packet, it consults the routing table to decide what to do with the packet. If the routing table says "send all packets to gateway 10.13.10.5 via tun0", then that's what the Linux kernel does. OpenVPN is not involved in any way in this.
Now OpenVPN has created tun0, so what happens when the kernel puts a packet into tun0 is that OpenVPN can read this packet. That's what a tun/tap interface does: It allows an application to read packets put into this interface (by the kernel), and also to write packets which will get emitted from this interface (which will also be handled like the kernel, just as if the packet came from a real network card).
No promiscous mode involved. Is the problem that you don't understand how the tun/tap interface works?
answered Jul 12 at 15:25
dirkt
13.8k2930
Look again at the routing table (ip route). You'll notice there's either a default route to 10.13.10.5, or a pair of 0.0.0.0/1/128.0.0.0/1 routes to 10.13.10.5 (which is just a trick that allows OpenVPN to keep the default route, though it becomes inactive), and this route goes via tun0.
It doesn't matter what IP tun0 has, what matters is the gateway IP, which happens to be 10.13.10.5 and is on the other side of tun0.
So how does OpenVPN make all traffic go into tun0? By providing routes, just like without OpenVPN all traffic goes to eth0 (or wlan0, or whateever the default route says).
OpenVPN doesn't do anything special. In particular, it doesn't use a raw socket, it creates a tun/tap interface.
Edit
OpenVPN doesn't "listen for traffic bound to the other end".
When the Linux kernel sees a network packet, it consults the routing table to decide what to do with the packet. If the routing table says "send all packets to gateway 10.13.10.5 via tun0", then that's what the Linux kernel does. OpenVPN is not involved in any way in this.
Now OpenVPN has created tun0, so what happens when the kernel puts a packet into tun0 is that OpenVPN can read this packet. That's what a tun/tap interface does: It allows an application to read packets put into this interface (by the kernel), and also to write packets which will get emitted from this interface (which will also be handled like the kernel, just as if the packet came from a real network card).
No promiscous mode involved. Is the problem that you don't understand how the tun/tap interface works?
answered Jul 12 at 15:25
dirkt
13.8k2930
edited Jul 12 at 15:53
answered Jul 12 at 15:25
dirkt
13.8k2930
answered Jul 12 at 15:25
dirkt
13.8k2930
answered Jul 12 at 15:25
dirkt
13.8k2930
13.8k2930
Thank you for the edit. Yes. I was not completely sure how exactly tun/tap interfaces work. I sort of expected it to behave like a normal Ethernet interface. Thanks to the comments by @ecdsa and your answer, I got the idea and I should certainly look into the tun/tap documentation.
– b1sub
Jul 12 at 15:59
Well, tun/tap sort of behaves like a normal Ethernet interface - the only difference is that instead of the packet getting handed down to the kernel driver, which talks to the hardware and tells it to send out the packet on the LAN/WLAN, the packet will be handed to OpenVPN (or whatever application created the tun/tap interface).
– dirkt
Jul 12 at 19:24
add a comment |Â
Thank you for the edit. Yes. I was not completely sure how exactly tun/tap interfaces work. I sort of expected it to behave like a normal Ethernet interface. Thanks to the comments by @ecdsa and your answer, I got the idea and I should certainly look into the tun/tap documentation.
– b1sub
Jul 12 at 15:59
Well, tun/tap sort of behaves like a normal Ethernet interface - the only difference is that instead of the packet getting handed down to the kernel driver, which talks to the hardware and tells it to send out the packet on the LAN/WLAN, the packet will be handed to OpenVPN (or whatever application created the tun/tap interface).
– dirkt
Jul 12 at 19:24
Thank you for the edit. Yes. I was not completely sure how exactly tun/tap interfaces work. I sort of expected it to behave like a normal Ethernet interface. Thanks to the comments by @ecdsa and your answer, I got the idea and I should certainly look into the tun/tap documentation.
– b1sub
Jul 12 at 15:59
Thank you for the edit. Yes. I was not completely sure how exactly tun/tap interfaces work. I sort of expected it to behave like a normal Ethernet interface. Thanks to the comments by @ecdsa and your answer, I got the idea and I should certainly look into the tun/tap documentation.
– b1sub
Jul 12 at 15:59
Well, tun/tap sort of behaves like a normal Ethernet interface - the only difference is that instead of the packet getting handed down to the kernel driver, which talks to the hardware and tells it to send out the packet on the LAN/WLAN, the packet will be handed to OpenVPN (or whatever application created the tun/tap interface).
– dirkt
Jul 12 at 19:24
Well, tun/tap sort of behaves like a normal Ethernet interface - the only difference is that instead of the packet getting handed down to the kernel driver, which talks to the hardware and tells it to send out the packet on the LAN/WLAN, the packet will be handed to OpenVPN (or whatever application created the tun/tap interface).
– dirkt
Jul 12 at 19:24
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%2f454904%2fhow-does-an-openvpn-tune-in-all-the-traffic-going-into-tun0%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
1
How is routing packets via
tun0different from routing any packets via e.g.eth0? These will usually also not have an IP on that interface as destination address. So what exactly confuses you? Did you read up on how TUN devices work?– ecdsa
Jul 12 at 14:27
@ecdsa I wonder in which method an OpenVPN can suck in all the traffic going to
tun0. My kernel routing table shows that all outbound traffic goes to10.13.10.5, but mytun0's IP address is10.13.10.6. In short, I'm curious how an OpenVPN can intercepts all the packets going to the another IP address.– b1sub
Jul 12 at 14:40
1
As I already suggested, you should read up on how TUN/TAP devices work. Maybe that clears things up.
– ecdsa
Jul 12 at 15:43
@ecdsa Thank you for the link. As you already expected, not completely understanding how tun/tap interfaces work was the source of my confusion. Have a nice day!
– b1sub
Jul 12 at 16:05