[eduVPN-deploy] NDP problems using public IPv6

Tue Sep 13 14:23:46 CEST 2022

Hi François,

hmm, I'm still not convinced how it could help me.

The eduvpn server has indeed several network interfaces :
- eth0 : the default public interface (public IP in v4 and v6) routed
to the Internet;
- eth1 : the VLAN interface connected to customer's router through our
backbone;
- eth2: a management interface (not in use for the moment );
- tunX: the various logical tun devices for the VPN.

And the routing accross all the interfaces on the server looks correct
to me, and works, IPv6 aside.

In IPv4, it works fine since proxy_arp is enabled; thus, finding the
Ethernet address of the VPN clients is properly done via the proxy_arp
module.

In IPv6, as ARP concept doesn't exist as is, it relies on ICMPv6
discovery packets to find the local link addresses, and that doesn't
work as the neighbor solicitation packets never reach the VPN clients.
(thus traffic coming from IPv6 local link addresses ~ fe80::/10 ==>
ff02:: to discover the locla link address)

Here is a tcpdump extract (on the client vpn host (= IPv6
2001:6a8:2100:136::2:a) I'm pinging in v6 2001:6a8:2100:500::3 which is
a host in the customer network not publicly available) :

root at eduvpn-uhasselt:~# tcpdump -i eth1 -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol
decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144
bytes
13:31:09.520902 IP6 2001:6a8:2100:136::2:a > 2001:6a8:2100:500::3:
ICMP6, echo request, id 14, seq 1, length 64
13:31:09.523940 IP6 fe80::20d:b4ff:fe0a:8700 > ff02::1:ff02:a: ICMP6,
neighbor solicitation, who has 2001:6a8:2100:136::2:a, length 32
13:31:10.524342 IP6 fe80::20d:b4ff:fe0a:8700 > ff02::1:ff02:a: ICMP6,
neighbor solicitation, who has 2001:6a8:2100:136::2:a, length 32
13:31:10.527612 IP6 2001:6a8:2100:136::2:a > 2001:6a8:2100:500::3:
ICMP6, echo request, id 14, seq 2, length 64
13:31:11.525085 IP6 fe80::20d:b4ff:fe0a:8700 > ff02::1:ff02:a: ICMP6,
neighbor solicitation, who has 2001:6a8:2100:136::2:a, length 32
...

Thus, I see well the ICMPv6 echo packets coming and sent via the VLAN
link to customer's network.
Right after, I see a packet from the host I'm trying to ping6 sending
an ICMPv6 neighbor solicitation to find the link of the vpn
client 2001:6a8:2100:136::2:a. 
But this packet will never reach the vpn client, and it will thus never
get a neigbor advertisement in return.

But if I use the proxy ndp module and setup it to proxy the address of
the vpn host on the eduvpn server, it works :

root at eduvpn-uhasselt:~# ip -6 neigh add proxy 2001:6a8:2100:136::2:a
dev eth1

root at eduvpn-uhasselt:~# tcpdump -i eth1 -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol
decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144
bytes
14:15:39.939854 IP6 2001:6a8:2100:136::2:a > 2001:6a8:2100:500::3:
ICMP6, echo request, id 15, seq 1, length 64
14:15:39.943774 IP6 fe80::20d:b4ff:fe0a:8700 > ff02::1:ff02:a: ICMP6,
neighbor solicitation, who has 2001:6a8:2100:136::2:a, length 32
14:15:40.246520 IP6 fe80::fc87:6aff:feb5:d959 >
fe80::20d:b4ff:fe0a:8700: ICMP6, neighbor advertisement, tgt is
2001:6a8:2100:136::2:a, length 32
14:15:40.249188 IP6 2001:6a8:2100:500::3 > 2001:6a8:2100:136::2:a:
ICMP6, echo reply, id 15, seq 1, length 64
14:15:40.765755 ARP, Reply 10.231.0.1 is-at 00:0d:b4:0a:87:00, length
42
14:15:40.940029 IP6 2001:6a8:2100:136::2:a > 2001:6a8:2100:500::3:
ICMP6, echo request, id 15, seq 2, length 64
14:15:40.942673 IP6 2001:6a8:2100:500::3 > 2001:6a8:2100:136::2:a:
ICMP6, echo reply, id 15, seq 2, length 64

...and then we are back to my initial question, how to dynamically
setup ndp proxy for IPv6 vpn clients addresses ?

If you say that I could use source routing' stuff to make it work, I'm
probably too dumb to see how to set it up. ;-)

Pascal

Le Monday 12 September 2022 à 23:52 +0200, François Kooman a écrit :
> Hi Pascal,
> 
> Ah! You have two interfaces with public addresses. You probably have
> to 
> do "source routing":
> 
> https://github.com/eduvpn/documentation/blob/v3/SOURCE_ROUTING.md
> 
> The "Making it permanent" still needs to be updated for Debian,
> didn't 
> get around to that yet. If you find out how to do that, please me me
> know :)
> 
> Regards,
> François
> 
> 
> On 12.09.22 13:49, Pascal Panneels wrote:
> > Hi François,
> > 
> > > > net.ipv4.ip_forward = 1
> > > > net.ipv4.conf.all.proxy_arp = 1
> > > > net.ipv6.conf.all.forwarding = 1
> > > > net.ipv6.conf.all.proxy_ndp = 1
> > > 
> > > All that should be needed is the sysctl options that are already
> > > set in
> > > /etc/sysctl.d/70-vpn.conf (by default).
> > 
> > Yes that 's the content of the file (btw, I've added 
> > net.ipv6.conf.all.proxy_ndp = 1 as it is not defined there as
> > standard 
> > if I remember well)
> > 
> > > Do you have a "non-standard" IPv6 deployment on that site?
> > > 
> > > The configuration assumes that (just like it would be with IPv4)
> > > the
> > > IPv6 prefix that is to be assigned to the VPN clients is routed
> > > to the
> > > public IPv6 address of the VPN server by the first router in the
> > > path
> > > (and allow egress from this prefix as well arriving from the VPN
> > > server's public IPv6 address).
> > 
> > As you may remember, we are hosting (and managing) VM servers for
> > our 
> > customers; the servers are in our premises and the link with the 
> > customer's networks is (currently) done via a dedicated VLAN that 
> > travels from cusrtomer's router through the BB and terminates on
> > the 
> > eduvpn server. IPv4 and Ipv6 addresses are assigned to each end of
> > the 
> > VLAN, one being on the eduvpn server.
> > Customer gave us a public IPv6 subrange (a /64) from his assigned
> > range.
> > I've splitted his range into several /111, each assigned to a
> > couple of 
> > vpn profiles.
> > 
> > 
> > > Of course, this all assumes that you use a *static* IPv6 address
> > > on the
> > > VPN server and have the routing properly configured in your
> > > router.
> > 
> > Static IPv6 addresses are used.
> > the /64 is routed by the server into the dedicated ethernet
> > interface 
> > where the VLAN ends (eth1 in the attached file).
> > 
> > > Make sure you update the VPN server firewall to allow the
> > > forwarding
> > > to/from the correct IP ranges and disable NAT there. Even without
> > > *any*
> > > firewall rules on the VPN server it should work, so you can
> > > temporary
> > > disable the entire firewall to see if that helps
> > 
> > NAT is well disabled (not nat table rules defined)
> > 
> > I've also tested by setting ACCEPT as default policy and ip6tables 
> > flushed (no rule) without any success so far.
> > 
> > The only way I've found to make it work is to issue following
> > command 
> > (for example):
> > 
> > ip -6 neigh add proxy 2001:6a8:2100:136::2:3 dev eth1
> > 
> > After that, 2001:6a8:2100:136::2:3 (=an ipv6 assigned to a VPN
> > client) 
> > can use the IPv6 network and ping or use any allowed trafic to
> > internal 
> > servers... but I cannot use the new script feature to apply it to 
> > connections being setup. (back to the purpose of my initial mail :-
> > ) )
> > 
> > > Can you provide the output of `ip6tables -S` and `ip6tables -S -t
> > > nat`
> > > and `ip -6 addr show`
> > 
> > see attached.
> > 
> > -- 
> > 
> > *Pascal Panneels*
> > *System Architect*
> > *Belnet - Services*
> > WTC III
> > Simon Bolivarlaan 30 Boulevard Simon Bolivar
> > Brussel 1000 Bruxelles
> > België - Belgique
> > T: +32 2 790 33 33
> > *https://www.belnet.be* <http://www.belnet.be>
> > 

-- 
Pascal Panneels
System Architect
Belnet - Services
WTC III
Simon Bolivarlaan 30 Boulevard Simon Bolivar
Brussel 1000 Bruxelles
België - Belgique
T: +32 2 790 33 33
https://www.belnet.be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://list.surfnet.nl/pipermail/eduvpn-deploy/attachments/20220913/845d3c11/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: face-wink.png
Type: image/png
Size: 856 bytes
Desc: not available
URL: <https://list.surfnet.nl/pipermail/eduvpn-deploy/attachments/20220913/845d3c11/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5842 bytes
Desc: not available
URL: <https://list.surfnet.nl/pipermail/eduvpn-deploy/attachments/20220913/845d3c11/attachment-0001.p7s>