Hi,
Consider me a novice to ipv6 domain. I have prepared RHEL based DNS64 / NAT64 server using ecdysis solution.
DNS64 and NAT64 works perfectly fine for ping6 request to ipv4 only sites, when the ping6 is generated on machine hosting DNS64 / NAT64 but not if the ping6 is generated from client machine ( 64 bit freeBsd) using DNS64 / NAT64 sever.
My objective is to use use this machine as DNS64 / NAT64 server for different client machines.
1. Following is the config of machine hosting DNS64 / NAT64 :
[root@csapi-qa-zab-01 ecdysis-nf-nat64-20101117]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:50:56:A9:33:52
inet addr:10.217.71.140 Bcast:10.217.71.255 Mask:255.255.248.0
inet6 addr: fe80::250:56ff:fea9:3352/64 Scope:Link
inet6 addr: 2001:db8:0:f101::3/96 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6951811 errors:0 dropped:0 overruns:0 frame:0
TX packets:52922 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:622107203 (593.2 MiB) TX bytes:6799148 (6.4 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
inet6 addr: 2001:db8:0:f101::21/96 Scope:Global
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1957 errors:0 dropped:0 overruns:0 frame:0
TX packets:1957 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:283427 (276.7 KiB) TX bytes:283427 (276.7 KiB)
nat64 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
virbr0 Link encap:Ethernet HWaddr 52:54:00:0C:5F:30
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:2532 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:119304 (116.5 KiB)
[root@csapi-qa-zab-01 ecdysis-nf-nat64-20101117]# route -n -A inet6
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
64:ff9b::/96 :: U 1024 0 0 nat64
2001:503:ba3e::2:30/128 2001:503:ba3e::2:30 UC 0 1 0 eth1
2001:db8:0:f101::/96 :: U 256 0 0 eth1
2001:dc3::35/128 2001:dc3::35 UC 0 1 2 eth1
fe80::/64 :: U 256 0 0 eth1
fe80::/64 :: U 256 0 0 virbr0
::/0 :: U 1024 0 0 eth1
::1/128 :: U 0 110 1 lo
2001:db8:0:f101::/128 :: U 0 0 1 lo
2001:db8:0:f101::/128 :: U 0 0 1 lo
2001:db8:0:f101::3/128 :: U 0 3604 1 lo
2001:db8:0:f101::21/128 :: U 0 3882 1 lo
fe80::/128 :: U 0 0 1 lo
fe80::250:56ff:fea9:3352/128 :: U 0 99 1 lo
ff02::1/128 ff02::1 UC 0 1 0 eth1
ff00::/8 :: U 256 0 0 eth1
ff00::/8 :: U 256 0 0 virbr0
[root@csapi-qa-zab-01 ecdysis-nf-nat64-20101117]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
10.217.64.0 0.0.0.0 255.255.248.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth1
0.0.0.0 10.217.64.1 0.0.0.0 UG 0 0 0 eth1
2. Following is the nat64_config.sh setting
IPV4_ADDR="10.217.71.140"
PREFIX_ADDR="64:ff9b::"
PREFIX_LEN="96"
3. The ping6 yahoo.com onto server machine itself gets successful
i) For ping6 -I eth1 yahoo.com
ii) Following is the tcpdump at eth1 interface
tcpdump -uvi eth1 icmp6
11:27:43.719453 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:0:f101::3 > ff02::1:ff37:48b7: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 64:ff9b::4137:48b7
source link-address option (1), length 8 (1): 00:50:56:a9:33:52
11:27:43.891464 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:0:f101::3 > ff02::1:ff00:1: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:7fd::1
iii) Following is the tcpdump at nat64 interface
tcpdump -nvi nat64 icmp6
tcpdump: WARNING: nat64: no IPv4 address assigned
tcpdump: listening on nat64, link-type RAW (Raw IP), capture size 65535 bytes
11:31:05.949960 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:db8:0:f101::21 > 64:ff9b::4137:4887: [icmp6 sum ok] ICMP6, echo request, length 64, seq 5
11:31:06.205672 IP6 (hlim 235, next-header ICMPv6 (58) payload length: 64) 64:ff9b::4137:4887 > 2001:db8:0:f101::21: [icmp6 sum ok] ICMP6, echo reply, length 64, seq 5
4. Following is the configuration at client machine ( freebsd machine)
snpqa-FB# ifconfig
bce0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=c01bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
ether 18:03:73:f0:f3:cb
inet 10.217.71.126 netmask 0xfffff800 broadcast 10.217.71.255
inet6 fe80::1a03:73ff:fef0:f3cb%bce0 prefixlen 64 scopeid 0x1
inet6 2001:db8:0:f101::2 prefixlen 96
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
bce1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=c01bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
ether 18:03:73:f0:f3:cd
media: Ethernet autoselect (none)
status: no carrier
bce2: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=c01bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
ether 18:03:73:f0:f3:cf
media: Ethernet autoselect (none)
status: no carrier
bce3: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=c01bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
ether 18:03:73:f0:f3:d1
media: Ethernet autoselect (none)
status: no carrier
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=3<RXCSUM,TXCSUM>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
snpqa-FB# netstat -r
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 10.217.71.140 UGS 0 2 bce0
10.217.64.0/21 link#1 U 1 3072 bce0
snpqa-FB link#1 UHS 0 0 lo0
10.217.109.54 10.217.64.1 UGHD 1 209 bce0
localhost link#5 UH 0 214 lo0
Internet6:
Destination Gateway Flags Netif Expire
:: localhost UGRS lo0 =>
default 2001:db8:0:f101::3 UGS bce0
localhost localhost UH lo0
::ffff:0.0.0.0 localhost UGRS lo0
2001:db8:0:f101:: link#1 U bce0
2001:db8:0:f101::2 link#1 UHS lo0
fe80:: localhost UGRS lo0
fe80::%bce0 link#1 U bce0
fe80::1a03:73ff:fe link#1 UHS lo0
fe80::%lo0 link#5 U lo0
fe80::1%lo0 link#5 UHS lo0
ff01:1:: fe80::1a03:73ff:fe U bce0
ff01:5:: localhost U lo0
ff02:: localhost UGRS lo0
ff02::%bce0 fe80::1a03:73ff:fe U bce0
ff02::%lo0 localhost U lo0
5. ISSUE : ping6 at client machine gets stucked ( no message on console)
snpqa-FB# ping6 yahoo.com
PING6(56=40+8+8 bytes) 2001:db8:0:f101::2 --> 64:ff9b::d1bf:7a46
above message shows that it has successfully resolved the name using DNS64
6. Following is the tcpdump for eth1 interface at DNS64 / NAT64 server machine
[root@csapi-qa-zab-01 ~]# tcpdump -nvi eth1 icmp6
11:39:51.541113 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 0
11:39:51.947264 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::baac:6fff:fe83:7fe4 > ff02::1:ff00:3: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fec0:0:0:ffff::3
source link-address option (1), length 8 (1): b8:ac:6f:83:7f:e4
11:39:52.541157 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 1
11:39:52.947223 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::baac:6fff:fe83:7fe4 > ff02::1:ff00:3: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fec0:0:0:ffff::3
source link-address option (1), length 8 (1): b8:ac:6f:83:7f:e4
11:39:53.540129 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 2
11:39:54.540122 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 3
11:39:55.540136 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 4
11:39:56.540151 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 5
11:39:56.540151 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:0:f101::2 > 2001:db8:0:f101::3: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8:0:f101::3
source link-address option (1), length 8 (1): 18:03:73:f0:f3:cb
11:39:56.540206 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) 2001:db8:0:f101::3 > 2001:db8:0:f101::2: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is 2001:db8:0:f101::3, Flags [router, solicited]
11:39:57.540141 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 6
11:39:58.540126 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 7
7. Request not getting forwarded to nat64 interface as tcpdump at nat64 interface doesn'r show up any message
Kindly suggest if I am missing out some route mapping to get the ping6 request from remote machine forwarded to nat64 interface
Regards
Rohit
Have you enabled forwarding of both IPv4 and IPv6 packets on the NAT64 server?
Quote from: kasperd on August 01, 2012, 02:57:22 AM
Have you enabled forwarding of both IPv4 and IPv6 packets on the NAT64 server?
Yes ipv6 forwarding is enabled:
Following is the proc/sys file values in NAT64 server machine
[root@csapi-qa-zab-01 ~]# cat /proc/sys/net/ipv6/conf/all/forwarding
1
[root@csapi-qa-zab-01 ~]# cat /proc/sys/net/ipv6/conf/all/autoconf
1
[root@csapi-qa-zab-01 ~]# cat /proc/sys/net/ipv6/conf/eth1/forwarding
1
[root@csapi-qa-zab-01 ~]# cat /proc/sys/net/ipv6/conf/eth1/autoconf
1
I thought I'd read ping doesnt work when using ecdysis....I went with tayga for nat64 anyway, didnt require kernel modification.
Quote from: kriteknetworks on August 01, 2012, 05:28:39 AM
I thought I'd read ping doesnt work when using ecdysis....I went with tayga for nat64 anyway, didnt require kernel modification.
ping6 perfectly works with ecdysis because when I am doing ping6 yahoo.com onto server machine hosting DNS64 / NAT64, it gets successfully resolved.
I just realized you have no public IPv4 address on that machine. Though multiple layers of NAT can work in principle, it is not a good idea to do so. I don't know if that is related to your problem or not. You didn't include the necessary packet dumps to see what happens to the IPv4 packets.
Quote from: kasperd on August 01, 2012, 06:50:17 AM
I just realized you have no public IPv4 address on that machine. Though multiple layers of NAT can work in principle, it is not a good idea to do so. I don't know if that is related to your problem or not. You didn't include the necessary packet dumps to see what happens to the IPv4 packets.
IPv4 ping command gets succesfully executed:
1. Following is the snapshot of ping yahoo.com from client machine. routing table on client machine is set to forward the IPv4 packet to NAT64/DNS64 server machine as default rule:
snpqa-FB# ping yahoo.com
PING yahoo.com (72.30.38.140): 56 data bytes
92 bytes from 10.217.71.140: Redirect Host(New addr: 10.217.64.1)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 01ad 0 0000 3f 01 b8fb 10.217.71.126 72.30.38.140
64 bytes from 72.30.38.140: icmp_seq=0 ttl=44 time=281.713 ms
64 bytes from 72.30.38.140: icmp_seq=1 ttl=44 time=283.519 ms
64 bytes from 72.30.38.140: icmp_seq=2 ttl=44 time=277.960 ms
64 bytes from 72.30.38.140: icmp_seq=3 ttl=44 time=321.895 ms
64 bytes from 72.30.38.140: icmp_seq=4 ttl=44 time=294.657 ms
2. Following is the tcpdump onto server machine eth1 interface for request originating from src as client machine ip :
[root@csapi-qa-zab-01 ecdysis-nf-nat64-20101117]# tcpdump -uvi eth1 src host 10.217.71.126
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
13:55:41.527133 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.217.71.126 is-at 18:03:73:f0:f3:cb (oui Unknown), length 46
13:55:49.703368 IP (tos 0x0, ttl 64, id 295, offset 0, flags [none], proto UDP (17), length 55)
10.217.71.126.54901 > 10.217.71.140.domain: 57089+ A? yahoo.com. (27)
13:55:49.703786 IP (tos 0x0, ttl 64, id 296, offset 0, flags [none], proto ICMP (1), length 84)
10.217.71.126 > ir2.fp.vip.bf1.yahoo.com: ICMP echo request, id 43781, seq 0, length 64
13:55:49.703825 IP (tos 0x0, ttl 63, id 296, offset 0, flags [none], proto ICMP (1), length 84)
10.217.71.126 > ir2.fp.vip.bf1.yahoo.com: ICMP echo request, id 43781, seq 0, length 64
13:55:49.704211 IP (tos 0x0, ttl 64, id 298, offset 0, flags [none], proto UDP (17), length 72)
10.217.71.126.43800 > 10.217.71.140.domain: 57090+ PTR? 140.71.217.10.in-addr.arpa. (44)
13:56:53.044827 IP (tos 0x0, ttl 64, id 428, offset 0, flags [none], proto UDP (17), length 55)
Quote from: rohit7855 on August 02, 2012, 01:52:40 AM2. Following is the tcpdump onto server machine eth1 interface for request originating from src as client machine ip :
[root@csapi-qa-zab-01 ecdysis-nf-nat64-20101117]# tcpdump -uvi eth1 src host 10.217.71.126
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
13:55:41.527133 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.217.71.126 is-at 18:03:73:f0:f3:cb (oui Unknown), length 46
13:55:49.703368 IP (tos 0x0, ttl 64, id 295, offset 0, flags [none], proto UDP (17), length 55)
10.217.71.126.54901 > 10.217.71.140.domain: 57089+ A? yahoo.com. (27)
13:55:49.703786 IP (tos 0x0, ttl 64, id 296, offset 0, flags [none], proto ICMP (1), length 84)
10.217.71.126 > ir2.fp.vip.bf1.yahoo.com: ICMP echo request, id 43781, seq 0, length 64
13:55:49.703825 IP (tos 0x0, ttl 63, id 296, offset 0, flags [none], proto ICMP (1), length 84)
10.217.71.126 > ir2.fp.vip.bf1.yahoo.com: ICMP echo request, id 43781, seq 0, length 64
13:55:49.704211 IP (tos 0x0, ttl 64, id 298, offset 0, flags [none], proto UDP (17), length 72)
10.217.71.126.43800 > 10.217.71.140.domain: 57090+ PTR? 140.71.217.10.in-addr.arpa. (44)
13:56:53.044827 IP (tos 0x0, ttl 64, id 428, offset 0, flags [none], proto UDP (17), length 55)
So the echo requests are translated and send, but you do not receive any reply. Why do you think this is a problem with the NAT64?
You should verify that those echo requests have correct checksums. I don't know if you can do that with tcpdump. You can verify the checksum by writing the full packets to a file with tcpdump (e.g. -s 0 -Uw filename), and then load the file in wireshark (you may need to right click on the checksums to enable verification).
Still the packets are leaving your NAT with private addresses. Do you have another layer of NAT? You are going to get better reliability if you use only one layer of NAT.
Quote from: kasperd on August 02, 2012, 02:30:12 AM
Quote from: rohit7855 on August 02, 2012, 01:52:40 AM2. Following is the tcpdump onto server machine eth1 interface for request originating from src as client machine ip :
[root@csapi-qa-zab-01 ecdysis-nf-nat64-20101117]# tcpdump -uvi eth1 src host 10.217.71.126
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
13:55:41.527133 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.217.71.126 is-at 18:03:73:f0:f3:cb (oui Unknown), length 46
13:55:49.703368 IP (tos 0x0, ttl 64, id 295, offset 0, flags [none], proto UDP (17), length 55)
10.217.71.126.54901 > 10.217.71.140.domain: 57089+ A? yahoo.com. (27)
13:55:49.703786 IP (tos 0x0, ttl 64, id 296, offset 0, flags [none], proto ICMP (1), length 84)
10.217.71.126 > ir2.fp.vip.bf1.yahoo.com: ICMP echo request, id 43781, seq 0, length 64
13:55:49.703825 IP (tos 0x0, ttl 63, id 296, offset 0, flags [none], proto ICMP (1), length 84)
10.217.71.126 > ir2.fp.vip.bf1.yahoo.com: ICMP echo request, id 43781, seq 0, length 64
13:55:49.704211 IP (tos 0x0, ttl 64, id 298, offset 0, flags [none], proto UDP (17), length 72)
10.217.71.126.43800 > 10.217.71.140.domain: 57090+ PTR? 140.71.217.10.in-addr.arpa. (44)
13:56:53.044827 IP (tos 0x0, ttl 64, id 428, offset 0, flags [none], proto UDP (17), length 55)
So the echo requests are translated and send, but you do not receive any reply. Why do you think this is a problem with the NAT64?
You should verify that those echo requests have correct checksums. I don't know if you can do that with tcpdump. You can verify the checksum by writing the full packets to a file with tcpdump (e.g. -s 0 -Uw filename), and then load the file in wireshark (you may need to right click on the checksums to enable verification).
Still the packets are leaving your NAT with private addresses. Do you have another layer of NAT? You are going to get better reliability if you use only one layer of NAT.
In case of Pv4 ping request from client the NAT doesn't comes into picture. As per the server machine IPv4 routing table the IPv4 requests are directly forwarded to gateway machine 10.217.64.1 , bypassing the nat64 interface.
The problem comes for IPv6 ping request from client. As per server machine IPv6 routing table all the the packets with destination 64:ff9b:: should get forwarded to nat64 interface for NAT translation, which is not happening in actual and creating the issue.
Quote from: rohit7855 on August 02, 2012, 03:03:06 AMThe problem comes for IPv6 ping request from client. As per server machine IPv6 routing table all the the packets with destination 64:ff9b:: should get forwarded to nat64 interface for NAT translation, which is not happening in actual and creating the issue.
According to the tcpdump output you posted, the packet was never send from the client to the server. Instead the client was sending a bogus neighbor solicitation packet asking for the MAC address of 64:ff9b::4137:48b7.
That means the routing table on the client must be incorrect.The routing table you posted from the client is not any use in debugging the problem since all the prefixes are listed without a length.
So find a way to view the actual routing table on the client and post that. Then I'll try to explain what is wrong with the routing table.On a closer look that spurious neighbor solicitation appears to be from the server rather than from the client. That's even more weird. Because that implies the server send the neighbor solicitation without first receiving the packet. Additionally the routing table you posted from the server shouldn't cause this.
The routing table on the server does have a bogus entry
Quote from: rohit7855 on July 31, 2012, 10:53:20 PM::/0 :: U 1024 0 0 eth1
If that was the one matching the packet, then it would indeed cause the spurious neighbor solicitation because that routing table entry is missing a next hop. However the packet should have matched a different entry in the routing table
Quote from: rohit7855 on July 31, 2012, 10:53:20 PM64:ff9b::/96 :: U 1024 0 0 nat64
And that entry looks correct to me. I'd still fix the incorrect routing table entry.