knownPlayer last edited by
currently I am working on a packet filter, which receives packets from one interface and sends them out on another via OpenVPN. The program utilizes the libpcap library for C and is used for packet inspection. When the data is sent over the VPN, the ethernet header is removed and four bytes are added instead (02 00 00 00), I guess this is the address family number? Without my filter program in between, this works perfectly fine. But, when I try to filter and send the packets using the filter, those four bytes always get changed to (1f 00 00 00) and the packets do not arrive.
My program works in every other scenario not including OpenVPN. I can see, that the program sends the correct data, but the first byte gets changed after it has been sent.
Does anyone know why this happens?
Thanks in advance
JKnott last edited by
If your VPN is in tunnel mode, then the Ethernet frames are always removed, as is always the case when passing through a router. OpenVPN works by carrying the encrypted IP packets in a UDP packet. Regardless, the whole point of an encrypted VPN is to hide everything about a packet.
TmKBlackWolf last edited by
I've looked into the meaning of this header and as far as I can tell, the 02 00 00 00 header is used by BSD on the loopback interface in order to indicate the type of package transmitted. 02 00 00 00 indicates an IPv4 package. However, when directly piping onto the virtual interface used for OpenVPN, the family seems get changed. Looking at the Wireshark dump of my OpenVPN tunnel, I can see the four header bytes, you are talking about. However, I do not know, why the manual redirection of packages should cause a change. The only thing I could find, is the following from http://www.tcpdump.org/linktypes.html
BSD loopback encapsulation; the link layer header is a 4-byte field, in host byte order, containing a value of 2 for IPv4 packets, a value of either 24, 28, or 30 for IPv6 packets, a value of 7 for OSI packets, or a value of 23 for IPX packets. All of the IPv6 values correspond to IPv6 packets; code reading files should check for all of them.
host byte order'' is the byte order of the machine on which the packets are captured; if a live capture is being done,host byte order'' is the byte order of the machine capturing the packets, but if a ``savefile'' is being read, the byte order is not necessarily that of the machine reading the capture file.
Maybe, this gives you a starting point.