UCS not accessible via Ipv6 (1 out of 3)

bitboy0 · July 26, 2019, 5:44am

I have three UCS servers running in my network on one VMWARE. Since we only have one IPv4, I was able to reach exactly one from the outside. That was the one Kopano is running on.

All are running 4.4-1

Since we now also got IPv6, I could now assign an address to each of the servers via SLAAC.

ifconfig also shows me the addresses on eth0. The addresses are reachable via ping or tracert. Internally as well as externally.

But on one machine I can’t reach apache via ipv6, neither externally nor internally. The firewall rules on the pfsense are the same for all three machines (except of course the target ip.) I have checked the addresses several times and am sure that I have no error in the IP.
Interestingly, Let’s Encrypt can easily order a certificate, so ports 443 and 80 must be accessible from the outside.

Even if I bypass the DNS and enter the ipv6 from the internal network directly into the browser, there is no answer from Apache … but i can ping it. in the internal network there is an any2any-allow rule for ipv6, so at least it should work there.

What can be the problem?

https://core.wedia.de only ipv4 seems to work internaly. no external ipv4
https://mannheim.wedia.de ipv4 and ipv6 both working internally and externaly
https://smb.wedia.de only ipv6 externaly available and working fine. ipv4 internaly also okay.

here my tracert from home to the “core” …

tracert core.wedia.de

Routenverfolgung zu core.wedia.de [2a00:1e80:71:0:250:56ff:fea6:592]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms p200300C387159000464E6DFFFE5EB215.dip0.t-ipconnect.de [2003:c3:8715:9000:464e:6dff:fe5e:b215]
2 4 ms 3 ms 3 ms 2003:0:8300:7800::1
3 6 ms 5 ms 6 ms 2003:0:1309:4017::1
4 6 ms 5 ms 5 ms 2003:0:1309:4017::2
5 6 ms 5 ms 5 ms lo-0-v6.ear2.Frankfurt1.Level3.net [2001:1900:2::3:111]
6 6 ms 5 ms 5 ms MANET-GMBH.edge3.Frankfurt1.Level3.net [2001:1900:5:2:2::a2]
7 8 ms 7 ms 7 ms 2a00:1e80:8:13::2
8 8 ms 7 ms 7 ms 2a00:1e80:8:3::2
9 8 ms 8 ms 8 ms 2a00:1e80:6:13::5
10 9 ms 8 ms 7 ms 2a00:1e80:71:0:250:56ff:fea6:592

Ablaufverfolgung beendet.

Translated with www.DeepL.com/Translator

Moritz_Bunkus · July 26, 2019, 7:26am

Hey,

first of all: if you’re running servers, you usually do not want to use SLAAC for address assignment, for several reasons:

On Linux the user space doesn’t get notified when an address is assigned via SLAAC (unlike DHCP where there’s a user-space DHCP client doing all the address handling, for SLAAC all work is done in the kernel). This in turn means that UCS’s own tools aren’t made aware of address changes and cannot update the corresponding configuration/LDAP entries automatically.
Changing the machine hardware (e.g. moving to another virtual machine, going hardware…) changes the MAC which in turn changes the address generated via SLAAC, and then you’ll have to update your DNS records.

SLAAC is generally meant to make it easier to for clients to access the network.

Not saying that you cannot use SLAAC for servers, just that it isn’t best practice.

That being said, on to your actual issue.

Your traceroute seems to suggest that the server is reachable from the internet, and I can confirm that I can ping it, which is good. Nevertheless, try ping -6 www.google.com from the shell on core.wedia.de, please, just to make sure that the server does actually have internet connectivity. This makes sure it’s actually the core server that replies to the externally-sent pings.

Next see if there’s something listening on port 443. Again from the shell of core.wedia.de, run lsof -PniTCP:443 which should show several apache2 processes. This makes sure that our assumptions (a web server should answer when trying to connect to that port) are correct.

Now try connecting to core.wedia.de port 443 from any of the other servers you’ve mentioned, e.g. run the following on smb.wedia.de: telnet core.wedia.de 443. If telnet shows something like Connected to…, the connection works, which in turn means that the firewall on core is configured correctly.

If all of those steps succeed, the only culprit left is the firewall between the internet and your server core, meaning that pfsense device you talked about.

m.

bitboy0 · July 26, 2019, 10:53am

ping6 google.de
PING google.de(fra15s28-in-x03.1e100.net (2a00:1450:4001:80b::2003)) 56 data bytes
64 bytes from fra15s28-in-x03.1e100.net (2a00:1450:4001:80b::2003): icmp_seq=1 ttl=56 time=2.62 ms
64 bytes from fra15s28-in-x03.1e100.net (2a00:1450:4001:80b::2003): icmp_seq=2 ttl=56 time=2.59 ms
64 bytes from fra15s28-in-x03.1e100.net (2a00:1450:4001:80b::2003): icmp_seq=3 ttl=56 time=2.54 ms
64 bytes from fra15s28-in-x03.1e100.net (2a00:1450:4001:80b::2003): icmp_seq=4 ttl=56 time=2.58 ms
64 bytes from fra15s28-in-x03.1e100.net (2a00:1450:4001:80b::2003): icmp_seq=5 ttl=56 time=2.57 ms
64 bytes from fra15s28-in-x03.1e100.net (2a00:1450:4001:80b::2003): icmp_seq=6 ttl=56 time=2.63 ms

So that does look good too.
With SLAAC I got your point … At the moment this is not the Problem, but it could be in the future.

root@smb:~# telnet core.wedia.de 443
Trying 2a00:1e80:71:0:250:56ff:fea6:592…
Connected to core.wedia.de.
Escape character is ‘^]’.

It’s pretty strange …

the server has IPv6 and when I’m physically in the company network I get to all three servers with IPv6

When I’m in over VPN I get an address from a /64 subnet in our /48 network and can access the corporate network without restriction, except the address of this one server.

So I suspect the error in the firewall configuration somewhere … I go on the search and thank you already times up to here for the tips.

If I don’t find any error there, I don’t know any more …
Then I must let there probably times a professional over it look.

Translated with www.DeepL.com/Translator

Moritz_Bunkus · July 26, 2019, 11:00am

Yeah, this surely looks like a firewall issue between your host & the server (not on the server, obviously, as the telnet test succeeds). Maybe it’s as simple as a typo in the IPv6 address.

bitboy0 · July 31, 2019, 7:06am

It’s not a typo … sometimes it just works finde. sometimes it doesn’t work at all. I’m on the search.

bitboy0 · January 16, 2020, 12:00pm

The problem is found and fixed.
Actually, there were two problems:

The firewall was not configured properly. This caused sometimes packets to take a wrong route. We fixed that then. But even then it was only running via SLAAC.
The IPv6 setup is inconsistent with IPv4. While IPv4 uses the classic network mask (e.g. 255.255.255.0 for a /24 network), IPv6 is different. Where you have to enter the IPv6 prefix you do NOT have to enter the prefix, but the prefix length. So in our case 64, and after that “default” must be entered in the much too small text field. Both are not mentioned in the manual and in my opinion neither is consistent nor self-explanatory.

Since the firewall is configured correctly AND the data for IPv6 is entered correctly everything works.

Translated with www.DeepL.com/Translator (free version)