Onnowpurbo at 03:15, 5 February 2019

2019-02-05T03:15:31Z

Onnowpurbo: Created page with "How to get through the gateway – or Come back ARP, all is forgiven So when I ping 123::789 what stops it working? The first thought is: firewall. We’re blocking it, righ..."

2019-02-05T03:07:43Z

Created page with "How to get through the gateway – or Come back ARP, all is forgiven So when I ping 123::789 what stops it working? The first thought is: firewall. We’re blocking it, righ..."

New page

How to get through the gateway – or Come back ARP, all is forgiven

So when I ping 123::789 what stops it working? The first thought is: firewall. We’re blocking it, right? A quick trip to the shorewall6 log (glad we set that up, eh?) shows us: nothing. Nowt. Zilch. Nada. Surprisingly, we’re not dropping the ping. (In fact the firewall config we set up in the first of these articles contains enough already to allow, from a firewall perspective, for this ping to succeed.)

So we now run tcpdump on eth0 to see just what is going on. Here’s an example:
From the remote host

From my remote IPv6 host I do and see:

ping6 2a01:XXX:8b25:7ea0::22
PING 2a01:XXX:8b25:7ea0::22(2a01:XXX:8b25:7ea0::22) 56 data bytes
From 2a01:XXX:8b25:7ea0::1 icmp_seq=1 Destination unreachable: Address unreachable
From 2a01:XXX:8b25:7ea0::1 icmp_seq=2 Destination unreachable: Address unreachable
From 2a01:XXX:8b25:7ea0::1 icmp_seq=3 Destination unreachable: Address unreachable
.
.
.

Which doesn’t tell me a lot.
On the gateway

On my gateway, from tcpdump, I see:

tcpdump -i eth0 -v ip6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
08:51:35.315038 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::207:cbff:fea5:XXX > ff02::1:ff00:22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:XXX:8b25:7ea0::22
source link-address option (1), length 8 (1): 00:07:cb:a5:1a:68
08:51:36.315002 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::207:cbff:fea5:XXX > ff02::1:ff00:22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:XXX:8b25:7ea0::22
source link-address option (1), length 8 (1): 00:07:cb:a5:1a:68
08:51:37.315001 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::207:cbff:fea5:XXX > ff02::1:ff00:22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:XXX:8b25:7ea0::22
source link-address option (1), length 8 (1): 00:07:cb:a5:1a:68

What does this tell me?

So the ping is reaching the gateway device alright. Sort of. Well, not really. But there’s something going on there! What we see in that tcpdump trace is the ISP’s router to which I’m connected is sending me a Neighbor Solicitation for the ::22 address (i.e. the global IPv6 address of my eth1 interface on the “far side” of my gateway which I’m trying to ping) While I’m not keen to draw too many parallels and comparisons with IPv4, it is useful to do so here: A Neighbor Solicitation is, at least as we see it here, pretty much analogous to a good ol’ ARP Request. The ISP is saying to us “I think this address is somewhere over with you – Please confirm and let me know how to reach it”. Which is great, except for the glaring fact that we appear to ignore this NS (Neighbor Solicitation) and hence the ping fails.

So you can guess we need to set something up on the gateway that tells it to reply to such a NS. (Kinda vaguely analogous to a Proxy ARP, if you’re familiar with that)
IPv6 Proxy

A couple of steps here. Firstly the system needs to be told globally to perform the required IPv6 proxying, and we then need to enable it for specific addresses.
proxy_ndp

In the /etc/sysctl.conf file add a line:

net.ipv6.conf.all.proxy_ndp = 1

To set this dynamically (without a reboot) you can also do:

sysctl -w net.ipv6.conf.all.proxy_ndp=1

Neighbor proxy

Then perform:

ip -6 neigh add proxy 2a01:XXX:8b25:7ea0::22 dev eth0

Note that here the IPv6 address is the address of the interface on the private side of the gateway (eth1 for me). The end part “…dev eth0” is to say “Proxy that address from this interface”.

You also, of course, will need to make such configuration permanent. Numerous approaches to that: I settled upon adding this from the interface-up scripts in /etc/network/if-up.d/ but there are so many other methods too. Pick yours.

(Interestingly, I have yet to discover any way at all to display the list of proxied neighbors added in this manner! I’ve looked pretty hard, but there appears to be no way I can find to have them listed. There must be a way, but I can’t find it.)

==Pranala Menarik==

* [[IPv6]]

@@ Line 1: / Line 1: @@
-How to get through the gateway –  or Come back ARP, all is forgiven
+Skenario yang ada, upstream provider memberikan satu block IPv6 address, misalnya, 2a01:XXX:8b25:7ea0::/64 (eth0), dengan gateway (tun0) di sisi kita 2a01:XXX:8b25:7ea0::1. Salah satu client mencoba ping6 tapi tidak berhasil,
-So when I ping 123::789 what stops it working? The first thought is: firewall. We’re blocking it, right? A quick trip to the shorewall6 log (glad we set that up, eh?) shows us: nothing. Nowt. Zilch. Nada. Surprisingly, we’re not dropping the ping. (In fact the firewall config we set up in the first of these articles contains enough already to allow, from a firewall perspective, for this ping to succeed.)
+ ping6 2a01:XXX:8b25:7ea0::22
-So we now run tcpdump on eth0 to see just what is going on. Here’s an example:
+==Aktifkan ndp==
-From my remote IPv6 host I do and see:
+Salah satu solusi yang ampuh adalah menggunakan Neighbor Discovery Proxy (ndp). Yang sudah built in di kernel dan dapat di aktifkan dengan mudah. Di gateway, aktifkan ndp proxy menggunakan perintah
-    ping6 2a01:XXX:8b25:7ea0::22
+Edit /etc/sysctl.conf tambahkan
-Which doesn’t tell me a lot.
+ net.ipv6.conf.all.proxy_ndp = 1
-On my gateway, from tcpdump, I see:
+atau
-    tcpdump -i eth0 -v ip6
+ sysctl -w net.ipv6.conf.all.proxy_ndp=1
-What does this tell me?
+atau
-So the ping is reaching the gateway device alright. Sort of. Well, not really. But there’s something going on there! What we see in that tcpdump trace is the ISP’s router to which I’m connected is sending me a Neighbor Solicitation for the ::22 address (i.e. the global IPv6 address of my eth1 interface on the “far side” of my gateway which I’m trying to ping) While I’m not keen to draw too many parallels and comparisons with IPv4, it is useful to do so here: A Neighbor Solicitation is, at least as we see it here, pretty much analogous to a good ol’ ARP Request. The ISP is saying to us “I think this address is somewhere over with you – Please confirm and let me know how to reach it”. Which is great, except for the glaring fact that we appear to ignore this NS (Neighbor Solicitation) and hence the ping fails.
+ echo 1 > /proc/sys/net/ipv6/conf/all/proxy_ndp
-So you can guess we need to set something up on the gateway that tells it to reply to such a NS. (Kinda vaguely analogous to a Proxy ARP, if you’re familiar with that)
+Lakukan proxy ke masing2 IPv6 client, misalnya
-A couple of steps here. Firstly the system needs to be told globally to perform the required IPv6 proxying, and we then need to enable it for specific addresses.
+ ip -6 neigh add proxy 2a01:XXX:8b25:7ea0::22 dev tun0
-In the /etc/sysctl.conf file add a line:
+Dimana
-    net.ipv6.conf.all.proxy_ndp = 1
+a01:XXX:8b25:7ea0::22 - IPv6 client tersambung via LAN

IPv6: Menggunakan Neighbor Discovery Proxy ndp - Revision history

Onnowpurbo at 03:15, 5 February 2019

Onnowpurbo: Created page with "How to get through the gateway – or Come back ARP, all is forgiven So when I ping 123::789 what stops it working? The first thought is: firewall. We’re blocking it, righ..."