top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

DNAT IPv4 to IPv6 using nftables?

+2 votes
816 views

I would like to DNAT IPv4 to IPv6. Is this currently possible maybe with nftables?
I'm looking for something similiar to:

iptables -t nat -A PREROUTING -p tcp --dport 4001 -d 1.2.3.4 -j DNAT --to '[fd00::fffa:1]:22'
posted Dec 17, 2013 by Garima Jain

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button
As far as I know, you cannot. IPv4 and IPv6 are totally different and incompatible protocols. You would have as much luck NATting IPv4 to Appletalk, NetWare or X.25.

Similar Questions
+3 votes

I want to use network ranges and host IP's in named maps. Using them in anonymous maps works:

# nft add rule filter output ip daddr vmap {192.168.0.0/24 : drop, 192.168.0.1 : accept}

However, in named maps it failes:

# nft -i
nft> add map filter verdict_map { type ipv4_address : verdict; }
nft> add element filter verdict_map { 1.2.3.5 : drop}
nft> add element filter verdict_map { 1.2.3.4/16 : accept}
BUG: invalid data expression type prefix

How do i use ranges or more complex expressions like IP + Port in maps?

+2 votes

Can someone help on how to replace the next iptables rule with nft:

iptables -t raw -A PREROUTING -i eth0 -j CT --notrack

Is this possible with nft or not?

+2 votes

From the docs on netfilter queues:

nfq_set_mode(qh, NFQNL_COPY_PACKET, 0xffff);
...
fd = nfq_fd(h);
while ((rv = recv(fd, buf, sizeof(buf), 0)) >= 0)
{
 printf("pkt receivedn");
 nfq_handle_packet(h, buf, rv);
}

When the CPU hits the printf()....what exactly has been read from fd?

Looking at a hex dump of the bytes read, it doesn't look like L2+L3, etc... But I think I'm seeing L3 about 58 bytes into the buffer. So what are the first 58 bytes?

Which is what nfq_get_payload() returns as well.

Is there significance to those first 58 or so bytes? If I subtract 14 from nfq_get_payload(), it doesn't seem to be L2.

+1 vote

I'm looking at a strange phenomenon that occurs on an iptables firewall. There is a DNAT rule configured that maps a public IP to a private one where a web serve is listening. Normal request operate as expected that is the destination ip is modified to the private one when the request arrives at the firewall and on the response packet the private ip is mapped back to the public one.
What I noticed though is that for some response packets the source ip is *not* mapped back to the public ip and instead tcpdump shows that the packets are sent out with the private source ip. The thing all these packets have in common is that they have the RST flag set.

What could be the reason for this? Is there some particular iptables behavior that could explain this?

+1 vote

After testing and looking at the kernel source, I realize that this mapping:

iptables -t nat -I PREROUTING -p tcp -m tcp --dport 30000:40000 -j DNAT --to [local_ip]:10000-2000

Doesn't do a one-to-one port mapping
e.g.:

100.0.0.1:30000 > 192.168.0.5:10000
100.0.0.1.30001 > 192.168.0.5:10001
100.0.0.1.30002 > 192.168.0.5:10002

I was wondering if it was possible to do the 1:1 port range forwarding to different port ranges or if you have to use individual rules.

...