networking - Limit UDP outbound traffic to loopback (localhost) instead of eth0

06
2013-08

Johnatan

Atm i'm testing it on Ubuntu Server at VMware Workstation + Windows 7 local host with bridged connection. Later this has to go to live server.

I have VLC streaming video file on Ubuntu with

cvlc -vvv /home/user/file.avi --loop --sout '#rtp{access=udp,mux=ts,dst=239.1.1.1,port=32321,caching=10000}'

later this stream is picked by udpxy as

udpxy -a lo -m eth0 -p 7777 &

Basically everything works well but my hosting provider is counting the UDP traffic as outbound though i dont need it anywhere outside. My idea is to block multicast UDP outbound traffic.

I've tried to use

route add -net 239.0.0.0/8 dev lo

the traffic is limited (cannot access it outside) but the

dumprtp 239.1.1.1 32321

on same server is not working neither.

Also i've tried creating new loopback interface for multicast addresses in /etc/network/interfaces like this

auto lo lo:udp
iface lo inet loopback

iface lo:udp inet static
    address 239.1.1.1
    netmask 255.0.0.0
    network 239.0.0.0

I was just trying to get it work, but it does not.

So basically i want the multicast udp traffic stay inside server without going out to the exterior network. And it should be multicast udp (stream is also picked by storage system and stream quality tests).

Thanks.

Answers

Johnatan

The solution was:

Add new option --miface=lo to VLC: cvlc -vvv /home/user/file.avi --loop --sout '#rtp{access=udp,mux=ts,dst=239.1.1.1,port=32321,caching=10000}' --miface=lo
Add route to lo for multicas addresses: route add -net 239.1.1.0 netmask 255.255.255.0 dev lo

2a. To make route persistent we have to add it to /etc/network/interfaces with prefix up. Like this: up route add -net 239.1.1.0 netmask 255.255.255.0 dev lo

That's it. Now VLC is streaming to lo interface and not to eth0. Also any application that wants to subscribe for 239.1.1.1 - 239.1.1.254 gonna do it through lo interface.

Hopefully this gonna help someone solve streaming issue.

Related Answers

Chris

This small guide tells you how to send UDP traffic via SSH using tools that come standard (ssh,nc,mkfifo) with most UNIX-like operating systems.

Performing UDP tunneling through an SSH connection

Step by step Open a TCP forward port with your SSH connection

On your local machine (local), connect to the distant machine (server) by SSH, with the additional -L option so that SSH with TCP port-forward:

local# ssh -L 6667:localhost:6667 server.foo.com

This will allow TCP connections on the port number 6667 of your local machine to be forwarded to the port number 6667 on server.foo.com through the secure channel. Setup the TCP to UDP forward on the server

On the server, we open a listener on the TCP port 6667 which will forward data to UDP port 53 of a specified IP. If you want to do DNS forwarding like me, you can take the first nameserver's IP you will find in /etc/resolv.conf. But first, we need to create a fifo. The fifo is necessary to have two-way communications between the two channels. A simple shell pipe would only communicate left process' standard output to right process' standard input.

server# mkfifo /tmp/fifo
server# nc -l -p 6667 < /tmp/fifo | nc -u 192.168.1.1 53 > /tmp/fifo

This will allow TCP traffic on server's port 6667 to be forwarded to UDP traffic on 192.168.1.1's port 53, and responses to come back. Setup the UDP to TCP forward on your machine

Now, we need to do the opposite of what was done upper on the local machine. You need priviledged access to bind the UDP port 53.

local# mkfifo /tmp/fifo
local# sudo nc -l -u -p 53 < /tmp/fifo | nc localhost 6667 > /tmp/fifo

This will allow UDP traffic on local machine's port 53 to be forwarded to TCP traffic on local machine's port 6667. Enjoy your local DNS server :)

As you've probably guessed it now, when a DNS query will be performed on the local machine, e.g. on local UDP port 53, it will be forwarded to local TCP port 6667, then to server's TCP port 6667, then to server's DNS server, UDP port 53 of 192.168.1.1. To enjoy DNS services on your local machine, put the following line as first nameserver in your /etc/resolv.conf:

nameserver 127.0.0.1

grawity

SSH (at least OpenSSH) has support for simple VPNs. Using the -w or Tunnel option in the ssh client, you can create a tun device at both ends, which can be used to forward any kind of IP traffic. (See also Tunnel in the manual page of ssh_config(5).) Note that this requires OpenSSH (and probably root privileges) at both ends.

nik

This example (I think John's answer points the the same thing at a different place), describes how to access another machine's UDP/DNS services over an TCP/SSH connection.

We will forward local UDP/53 traffic to TCP, then TCP traffic with the port-forwarding mechanism of SSH to the other machine, then TCP to UDP/53 on the other end.
Typically, you can do it with openvpn.
But here, we'll do it with simpler tools, only openssh and netcat.

At the end of that page, is another comment with a reference to 'socat',
The same UDP/DNS access is made with,

Server side: socat tcp4-listen:5353,reuseaddr,fork UDP:nameserver:53
Client side: socat udp4-listen:53,reuseaddr,fork tcp:localhost:5353

Refer socat examples for more.

slhck

A VPN is a better solution if you have access to an UDP port.

If you only have access to the TCP SSH port, then an SSH tunnel is as good as a VPN, at least for ping and packet backtracking.

Teddy

I'm sorry to give a non-answer, but you really don't want to do that. What about ICMP? SCTP? What you want is a real encrypted connection, either using real IPsec or some special VPN thing.

Home

networking - Limit UDP outbound traffic to loopback (localhost) instead of eth0