CODEWITHSUNDEEP
network-programmingroutesvpnopenvpnnetwork-traffic
Cigiller
Cigiller

Reputation: 84

Routing traffic with TUN/TAP interface

I am new to network programming and try to understand managing traffic via TUN/TAP interface.

Since I have almost nonexistent system programming skills, and feel confident on Java; I use OpenVPN tun/tap driver and ready made Java binding for it. It works on TAP mode.

As an example application I am trying to imitiate no encryption, no authentication client server VPN application.

I can catch Ethernet Frame packets, but for the routing part, I failed miserably. (I can modify route/arp tables.)

  1. Do anybody know how OpenVPN send packets from client to server, and from server to target. Opening sockets from Java looks like an alternative; but I was hoping that modifying packets(change IPs and/or MAC addresses) and writing back to the virtual tap interface would be enough. Is it so?

  2. Can I inject packets to send other locations, or by default received packet moves towards application layer?

-- Edit:

Scneario

Client Tap0 _____ Server Tap0 ______ Target
       Eth0              Eth0

Target: Ping from client, move through tap interfaces, target see only server ip (anonymization)

What I achived so far.

Now I read packets from socket at server, and try to OpenVPN Tap driver's write method to move forward but I am not sure where do I fail. I see packets with tcpdump at server tap0, but they do not pass to server eth0.

My most important question is if I modify packet(ip, mac address) and call write method, is it possible that packet moves forward. (Or does it move to application layer whatever you change??)

Any help would be appreciated.

Upvotes: 0

Views: 13362

Answers (1)

Phillip
Phillip

Reputation: 13668

1. Routing is a Layer 3 (IP) problem and handled by the OS. As for the Ethernet frames on Layer 2, you have multiple options. In any case, you'll have to parse the incoming packets' headers and extract the MAC address, and decide based on the MAC where to pass the packet: To a specific client, all clients (broadcasts) or the local tap interface.

Option 1: On each client, use a tun device, and let the server use a tap device. Assign pseudo MAC addresses to each client, respond accordingly to ARP requests from the server's OS and let the OS on the server take care of the rest. Applicationwise, you'll only have to forward all incoming packets to the tap device and all outgoing packets to the client to which you assigned this MAC.

Option 2: Let the clients choose their own MAC address and forward ARP-requests through the network. The server application has to decide for incoming packets from a client whether to forward the packet to a client, or send it to the local tap device if the address matches the local device's MAC.

In both cases, clients pass all packets from their local tun/tap device to the server and vice versa.

2. You can do almost anything. A packet is only "received" when you decide to write it to the tap device, and you can of course temper with any packets, or inject new ones, ...

As a final comment, I've found that toying with tun devices is conceptually simpler, because they work on Layer 3. You'll have to open a tun device on the server for each client, but within your application you'll have to do nothing but to forward anything coming from the device to the single client, and vice versa.

Upvotes: 4

Related Questions