On 14/06/17 12:25, Jan Just Keijser wrote: > Hi Pippin, > > On 14/06/17 11:08, Pippin1st wrote: >> >> Hello, >> >> > Same I said would apply to packets coming in: when going from >> > OpenVPN to tun0 they would not be subject to routing/iptables. >> > Basically the idea is that OpenVPN and the tun0 interface are >> > directly attached, so I/O between the two is direct. >> Ok, modified attached diagram 3a, looking at SERVER side, >> -A FORWARD -s 10.180.0.4 -d 10.180.0.11 -j ACCEPT >> -A FORWARD -s 10.180.0.11 -d 10.180.0.4 -j ACCEPT >> -I INPUT -i tun+ -j DROP >> would still apply. >> And reading the backreference article, >> > "You see each packet twice (but note the decremented TTL), >> > meaning that it really goes out and then back into tun0" >> seems to confirm. In diagram 3a traffic would first >> come out then go back in. >> >> Hope it`s more correct now or still missing something ?:)
This looks correct to me. You can actually think of "OpenVPN" and the tun/tap device as one entity. A tun/tap adapter may only be used by a single process. OpenVPN have a file descriptor to its tun/tap adapter which it reads from and writes to. That data is sent to the kernel's networking stack. This might be clearer if you consider the server or client having more eth devices, or consider how --redirect-gateway would interact. > for client-to-server traffic this looks correct ; client-to-client > traffic is another matter. Yes, good point. But that traffic never hits the tun/tap interface (unless the destination IP is a broadcast address; and IIRC, OpenVPN treats multicast as unicast traffic). And of course, the mysterious and well hidden packet filter in OpenVPN is also somewhere after the decompression and before the compression. -- kind regards, David Sommerseth OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
