Amit S's questions

I am using UDP over ipv6 as communication stack.

I have network client running on secondary virtual interface tap0. It generates messages for server which is supposed to run on the same interface but different link-scope ipv6 address. I can see proper messages generated by the client on the wireshark.
For now I don't have the server code ready but I am using netcat as a replacement for server to test receive the messages, which I have done as follows:

nc -l -6 -vvv -u fe80::d4b2:dcff:fe59:6d2%tap0 61616

fe80::d4b2:dcff:fe59:6d2 is the server side link-scope ipv6 address. Wireshark traces on tap0 clearly shows the packets generated are for above mentioned ipv6 address and port but the netcat is NOT able to receive any packets. ifconfig shows that I have the above IP assigned to tap0. Moreover, if I execute the following command, I am able to receive the packets at the netcat(server).

nc -6 -vvv -u fe80::d4b2:dcff:fe59:6d2%tap0 61616 < raw_message_file

Strangely, the sending of the above netcat "raw_message_file" is not captured by the wireshark running on tap0. Following ping is also not captured by the wireshark.

ping6 -I tap0 fe80::d4b2:dcff:fe59:6d2

How could be possible that even when explicitly specifying the interface for netcat and ping, the packet are not received/sent on that interface?

PS1: Virtual interface tap0 is opened by the client code. After some time it sends the message to the server which is supposed to be listening on that interface with some different but fixed IPv6.
PS2: I think my description is bit confusing; please ask questions, if you have any?

EDIT: tcpdump on localhost showed that the netcat and ping are going through the localhost interface. My question is, why?

I have the following setup:

Box1 [server]:
eth0 with ip 192.168.2.18 is in the internal network with webserver running on port 80.

Box2 [gateway]:
eth0 with ip gw.gw.gw.gw with some port exposed to internet e.g. port number 3000.
eth1 with ip 192.168.2.3 is for the internal network

Box3 [client]:
eth0 with ip cl.cl.cl.cl

Goal is to redirect the traffic from gw.gw.gw.gw:3000 to 192.168.2.18:80. It looks like simple DNAT rule would work but the problem is that gateway gw.gw.gw.gw is filtered by some other firewall(black-box) so that only established sessions are accepted in the output chain of the black-box. In other words, if I am listening to port 4000 at cl.cl.cl.cl, I won't be able to connect to cl.cl.cl.cl:4000 from gw.gw.gw.gw but the other way is possible i.e. I can connect from cl.cl.cl.cl to gw.gw.gw.gw:3000. Currently, I have following rules in the gateway:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 3000 -j DNAT --to 192.168.2.18:80
iptables -A POSTROUTING -t nat -j MASQUERADE -o eth0
iptables -A FORWARD -p tcp -i eth0 -o eth1 -d 192.168.2.18 --dport 3000 -j ACCEPT

sysctl -w net.ipv4.conf.eth0.forwarding=1    #to enable forwarding by kernel.

tcpdump show that gateway is sending response packets to the client but the client is not able to receive any. My best guess is that this is somehow related to session being lost at the iptables but I not a pro in iptables rules. Any clue as to what I could be missing here?

I have a packet inside a packet a.k.a tunneling. So essentially it's of the following form:
[IP HEADER 1][IP HEADER 2][PAYLOAD]
After reading the first header(done by a library) I will get the packet:
[IP HEADER 2][PAYLOAD]
at the INPUT chain of the iptables. I want to re-inject the packet to the starting of the iptables i.e. in the PREROUTING chain. Ultimate aim is to forward the packet to a remote host (that's why I want the packet to be in the PREROUTING chain). I have read something about the libipq but I am not really sure that it is the best way to do it. Any wild suggestion would also help.

I have already posted this question in 'stackoverflow' but since there were no replies, so I thought it is better suited for 'serverfault'.

I have read a few tutorials on setting up an encrypted file system using cryptsetup. They all start with the following creation of a random file

dd if=/dev/urandom of=/etc/cryptfile bs=1M count=10

This file would be further used to create a loopback device. The reason given for the randomising the file is generally given that the attacker won't be able to find what parts of the file are used to write and what parts are empty. My question is that since the loop back device is any way going to be formatted when we write the file system on it then why would we care about randomizing it in the first place?