WireGuard Archive on lore.kernel.org
 help / color / Atom feed
* IPv6 Not Getting Past Server
@ 2018-09-22 19:55 Aaron W. Swenson
  2018-09-25  5:20 ` Roman Mamedov
  0 siblings, 1 reply; 3+ messages in thread
From: Aaron W. Swenson @ 2018-09-22 19:55 UTC (permalink / raw)
  To: wireguard

[-- Attachment #1.1: Type: text/plain, Size: 4159 bytes --]

I’m going to use the official documentation IP addresses. I am using real IPv6
addresses and not using NAT66. Naturally, NAT is being used for IPv4. Here are
the definitions I’m using:

    Server Public IPv6: 2001:DB8::DEAD:F00D/64
    Server Public IPv4: 192.0.2.1
    Routed /116: 2001:DB8::BEEF:3000/116
    Server Wireguard IPv6: 2001:DB8::BEEF:3001
    Server Wireguard IPv4: 10.0.0.1
    Client Wireguard IPv6: 2001:DB8::BEEF:3002
    Client Wireguard IPv4: 10.0.0.2

I can ping the outside world through IPv4 just fine. However, with IPv6 I can
only ping the server’s IPv6 addresses (2001:DB8::BEEF:3001 and
2001:DB8::DEAD:F00D). The outside world stays out of reach. The packets are just
dropped. I’m not getting network unreachable or any other error message back.

When I enabled forwarding for IPv6 on the server, I did have to manually add
the route so that IPv6 would continue working on the server
(ip -r route add default fe80::1). I can SSH into the server, and ping the
outside world no problem. And, the outside world can reach my server via IPv6
just fine, too.

I’m running Gentoo on the server and client.


=====================================
Sysctl Settings I know to be relevant
=====================================
net.ipv6.conf.all.accept_ra = 2
net.ipv6.conf.default.accept_ra = 2
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1

==============================
Wireguard Server Configuration
==============================
[Interface]
Address = 10.0.0.1/24, 2001:DB8::BEEF:3001/116
SaveConfig = true
ListenPort = 51820
PrivateKey = ServerPrivateKey

[Peer]
PublicKey = ClientPublicKey
AllowedIPs = 10.0.0.2/32, 2001:DB8::BEEF:3002/128
Endpoint = 192.0.2.204:53132

==============================
Wireguard Client Configuration
==============================
[Interface]
Address = 10.0.0.2/32
Address = 2001:DB8::BEEF:3002
PrivateKey = ClientPrivateKey
DNS = 8.8.8.8

[Peer]
PublicKey = ServerPublicKey
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = 192.0.2.1:51820
PersistentKeepalive = 25

===============
Server Nftables
===============
flush ruleset;

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;

    # established/related connections
    ct state {established, related} accept

    # loopback interface
    iifname "lo" accept

    icmp type echo-request accept
    icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert, redirect } accept

    # TCP ports
    tcp dport {smtp, http, https, submission, imaps, irc} accept
    # ssh
    tcp dport #ssh# accept
    # Secured IRC
    tcp dport #notthatchatty# accept

    # UDP ports
    udp dport 51820 accept

    ip6 daddr 2001:DB8::BEEF:3000/116 accept
  }

  chain forward {
    type filter hook forward priority 0;

    # allow established/related connections
    ct state {established, related} accept

    # early drop of invalid connections
    ct state invalid drop

    # Allow packets to be forwarded from the VPNs to the outer world
    ip saddr 10.0.0.0/8 iifname wg0 oifname enp0s3 accept
    ip6 saddr 2001:DB8::BEEF:3000/116 iifname wg0 oifname enp0s3 accept
  }
}
# IPv4 NAT table
table ip nat {
  chain prerouting {
    type nat hook prerouting priority 0; policy accept;
  }
  chain postrouting {
    type nat hook postrouting priority 100; policy accept;
    ip saddr 10.0.0.0/8 oif "enp0s3" snat to 192.0.2.1
  }
}


====================
Client ‘ip -6 route’
====================
# ip -6 route
2001:DB8::BEEF:3002 dev wg0 proto kernel metric 256 pref medium
fe80::/64 dev enp1s0 proto kernel metric 100 pref medium


====================
Server ‘ip -6 route’
====================
2001:DB8::BEEF:3000/116 dev wg0 proto kernel metric 256 pref medium
2001:DB8::/64 dev enp0s3 proto kernel metric 256 expires 2326066sec pref medium
fe80::/64 dev enp0s3 proto kernel metric 256 pref medium
default via fe80::1 dev enp0s3 metric 1024 pref medium

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: IPv6 Not Getting Past Server
  2018-09-22 19:55 IPv6 Not Getting Past Server Aaron W. Swenson
@ 2018-09-25  5:20 ` Roman Mamedov
  2019-02-23 12:28   ` Aaron W. Swenson
  0 siblings, 1 reply; 3+ messages in thread
From: Roman Mamedov @ 2018-09-25  5:20 UTC (permalink / raw)
  To: Aaron W. Swenson; +Cc: wireguard

On Sat, 22 Sep 2018 15:55:22 -0400
"Aaron W. Swenson" <aaron@grandmasfridge.org> wrote:

> I’m going to use the official documentation IP addresses. I am using real IPv6
> addresses and not using NAT66. Naturally, NAT is being used for IPv4. Here are
> the definitions I’m using:
> 
>     Server Public IPv6: 2001:DB8::DEAD:F00D/64
>     Server Public IPv4: 192.0.2.1
>     Routed /116: 2001:DB8::BEEF:3000/116

Are you sure you have a *routed* subnet from your ISP? Moreover, does
this /116 lie within the above /64? (in your obfuscated example it does)

It could be that your provider gives you not a routed subnet, but an on-link
one instead. In which case you can use IPs from it on your server directly,
but can't route it somewhere else (because the upstream router expects all IPs
to be reachable directly on the same link that it has to your server).

One workaround is to set up ndppd, which turns an on-link subnet into routed:
https://github.com/DanielAdolfsson/ndppd
But in my experience it does not work on all ISPs/hosts.


>     Server Wireguard IPv6: 2001:DB8::BEEF:3001
>     Server Wireguard IPv4: 10.0.0.1
>     Client Wireguard IPv6: 2001:DB8::BEEF:3002
>     Client Wireguard IPv4: 10.0.0.2

You didn't post your WireGuard's AllowedIPs setting, but I tend to assume
everything is fine there. Just don't forget that to route to the outside world
AllowedIPs on the client must contain ::/0 for the server.

> I can ping the outside world through IPv4 just fine. However, with IPv6 I can
> only ping the server’s IPv6 addresses (2001:DB8::BEEF:3001 and
> 2001:DB8::DEAD:F00D). The outside world stays out of reach. The packets are just
> dropped. I’m not getting network unreachable or any other error message back.

Run tcpdump on the server both on the WG side and on the outgoing interface,
and you'll be able to say more precisely where or by whom they are dropped.

> When I enabled forwarding for IPv6 on the server, I did have to manually add
> the route so that IPv6 would continue working on the server
> (ip -r route add default fe80::1).

This is because the default behavior is such that enabling routing precludes
accepting Route Advertisements from upstream routers, so you lost the route
you were getting via those. To keep accepting them, set accept_ra to 2
(echo 2 > /proc/sys/net/ipv6/conf/ethX/accept_ra)

> I can SSH into the server, and ping the
> outside world no problem. And, the outside world can reach my server via IPv6
> just fine, too.

Try adding one of the IPs you wanted to route into WG directly to server's
uplink interface and see if it becomes pingable from the outside world. If so,
that would confirm (if a little bit) the non-routed subnet hypothesis.

-- 
With respect,
Roman
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: IPv6 Not Getting Past Server
  2018-09-25  5:20 ` Roman Mamedov
@ 2019-02-23 12:28   ` Aaron W. Swenson
  0 siblings, 0 replies; 3+ messages in thread
From: Aaron W. Swenson @ 2019-02-23 12:28 UTC (permalink / raw)
  To: Roman Mamedov; +Cc: wireguard

On 2018-09-25 01:20, Roman Mamedov wrote:
> On Sat, 22 Sep 2018 15:55:22 -0400
> "Aaron W. Swenson" <aaron@grandmasfridge.org> wrote:
> 
>> I’m going to use the official documentation IP addresses. I am using 
>> real IPv6
>> addresses and not using NAT66. Naturally, NAT is being used for IPv4. 
>> Here are
>> the definitions I’m using:
>> 
>>     Server Public IPv6: 2001:DB8::DEAD:F00D/64
>>     Server Public IPv4: 192.0.2.1
>>     Routed /116: 2001:DB8::BEEF:3000/116
> 
> Are you sure you have a *routed* subnet from your ISP? Moreover, does
> this /116 lie within the above /64? (in your obfuscated example it 
> does)

Took me a little while to follow up, I know, but this was the issue 
precisely.

I requested a /64 to replace the /116, and now everything is working 
beautifully. I made no other changes besides updating the IPv6 
addresses.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-22 19:55 IPv6 Not Getting Past Server Aaron W. Swenson
2018-09-25  5:20 ` Roman Mamedov
2019-02-23 12:28   ` Aaron W. Swenson

WireGuard Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://lore.kernel.org/wireguard \
		wireguard@lists.zx2c4.com zx2c4-wireguard@archiver.kernel.org
	public-inbox-index wireguard


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.zx2c4.lists.wireguard


AGPL code for this site: git clone https://public-inbox.org/ public-inbox