1

I've a virtual NIC of type NAT on my Ubuntu 20.04 virtual machine which connects it to the internet via host. For some processing, I need to route all incoming and outgoing packets via a program I've to write. For example, assume that I've to drop some packets and don't let them go out of the VM.

For this, I created a dummy interface with the following:

modprobe dummy
ip link add tun0 type dummy
ifconfig tun0 up

For all traffics not to go directly through the NIC, I added:

ip route add default dev tun0

Now everything is ok. For example when I

ping 4.2.2.4

, I see that the ping is not answered when my program is not running and is answered properly when it's running. The program works like a bridge between enp0s3 and tun0 for now. The whole traffic is routing through my program. Just a problem exists, name resolution. That's when I

ping google.com

, the name can't be resolved. The route table now is as follows:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0
0.0.0.0         10.0.2.2        0.0.0.0         UG    20100  0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp0s3

Of couse if I

sudo route del default

, the name resolution takes place via the NAT adapter through the host properly. Please let me know what's wrong with the name resolution in this situation.

Update

Look at these images:

1

Here I see that pings has had no response. Source and destination IP's are correct. Please concentrate on DNS packets. This is when I've changed the default route table to route all traffic from tun0.

2

Here I see that pings has had responses. The same source and destination IP's are used for DNS packets.

The only note I could find in the packets in the former situation is that source and destination MAC addresses are the same! We need just to find out why ping has generated such DNS packets?! Something seems to be wrong in the system configuration of the VM.

Have any idea?

hamidi
  • 21
  • 5
  • How the name resolution in the system is configured? (Please, add `cat /etc/resolv.conf`.) Also, how it's possible for ping to work in the first place? The program itself should be not able to reach the Internet because its own packets also should be "looped" to `tun0`. Please better show `ip route` instead of just `route` (and get a habit to always do that). – Nikita Kipriyanov Mar 21 '21 at 19:16
  • Can you show packet capture also on the `tun0` interface, which is used for forwarding the packets? – Tero Kilkanen Mar 21 '21 at 21:27

1 Answers1

0

For name resolution to work, you need to always allow TCP and UDP port 53.

With your approach, it is not possible to filter on the protocol level.

You should implement your program using IPTables NFQUEUE feature, which allows you to send packets to user-space for evaluation, and user-space program can then set a verdict for the packet (ACCEPT, REPEAT and DROP).

Tero Kilkanen
  • 36,796
  • 3
  • 41
  • 63
  • I didn't filter any traffic, say UDP on port 53. There's a complete bridge between two interfaces, so why doesn't responses arrive? Since I need to do some processing on the packets in user space, I can't use iptables. I need to manipulates all packets in my program. – hamidi Mar 21 '21 at 12:58
  • 1
    "you need to allow UDP port 53 traffic always." and TCP as well. No need to single out UDP, as DNS uses UDP and TCP, there is no reason to discriminate between them. – Patrick Mevzek Mar 21 '21 at 17:46
  • Thanks Patrick, I always forget it. For @hamidi, to me it looks you are filtering based on IP addresses. If you filter the traffic from / to DNS server, then you won't get DNS responses. Also, the `NFQUEUE` is the interface in iptables where you can handle packets in user space, especially designed for your user case. – Tero Kilkanen Mar 21 '21 at 18:00
  • I've updated the question. Please take a look. – hamidi Mar 21 '21 at 19:59