IPv6 issues on service networking restart

I am trying to set up IPv6 on my VPS using the guides for my host (OVH). I have edited my interfaces.d/xxx.cfg file correctly but when I try to use:

service networking restart

I get a failure with this message:

Job for networking.service failed because the control process exited with error code.
See “systemctl status networking.service” and “journalctl -xe” for details.
root@xerxes:/etc/network# systemctl status networking.service
networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2020-05-16 08:42:20 CEST; 11s ago
Docs: man:interfaces(5)
Process: 21154 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
Main PID: 21154 (code=exited, status=1/FAILURE)
May 16 08:42:20 xerxes ifup[21154]: ifup: failed to bring up eth0
May 16 08:42:20 xerxes ifup[21154]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_sender_restrictions
May 16 08:42:20 xerxes ifup[21154]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_client_restrictions
May 16 08:42:20 xerxes ifup[21154]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_helo_restrictions
May 16 08:42:20 xerxes ifup[21154]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_sender_restrictions
May 16 08:42:20 xerxes ifup[21154]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_client_restrictions
May 16 08:42:20 xerxes ifup[21154]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_helo_restrictions
May 16 08:42:20 xerxes systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
May 16 08:42:20 xerxes systemd[1]: networking.service: Failed with result ‘exit-code’.
May 16 08:42:20 xerxes systemd[1]: Failed to start Raise network interfaces.

When I look at /etc/postfix/master.cf file, all of these parameters are commented out and there is no other line calling for them. IPv4 continues to work even with this reported problem but my /etc/network/interfaces file is not being amended to allow the IPv6 connection (or if it is, it is not working properly).

Can anyone help me sort this?

Let me know if I need to post more snippets from files.

Undefinied means (in this case) it should be defined.

OK but how and where? As I said, these elements are commented out in the configuration files so where is postfix finding them? Much of the internet says they are a hangover from a prior version of postfix and are not needed. I do not mind defining them but I do not know how to.

You already said you found the config file where they are in. Just put in the real values and remove the comment out sign / part.
Either its that or there is an issue somewhere else. But its a good try to do that first.

Which OS are you using? In Ubuntu, you have to enable ipv6 in the /etc/sysctl.conf and then edit /etc/network/interfaces to add the IPv6 and then restart the network.

Sorry. Debian 10.

IPv6 forwarding of all packets is enabled.

/etc/network/interfaces.d/xxx.cfg is set for IPv6

@DrCarsonBeckett Carson, I do not think the issue is with the postfix config file. As I said, these items are all commented out.

Here is what I have done. I run:

service networking restart

But it fails to bring up the interface (which is working on IPv4). It tries to run:

*ExecStart=/sbin/ifup -a --read-environment *(code=exited, status=1/FAILURE)

And the critical errors given are the ones I have listed above:

May 17 23:15:45 xerxes ifup[5524]: ifup: failed to bring up eth0
May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_sender_restrictions
May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_client_restrictions
May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_helo_restrictions

Reading /etc/network/ifup it refers to using postconf which for Debian 10 is in /etc/sbin/ but it cannot be read as it appears to be a binary file(?).

When I investigate my master.cf file these three elements

mua_sender_restrictions, mua_client_restrictions and mua_helo_restrictions

Are commented out so no definition is given and I assume that postconf is looking for them. Reading the postfix.org site I chose recommended settings for each of these items, uncommented the lines and inserted them. To be safe, I rebooted.

Immediately after reboot, I ran a status request and the output was as follows:

root@xerxes:/etc/postfix# systemctl status networking.service
networking.service - Raise network interfaces

  • Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)*
  • Active: failed (Result: exit-code) since Sun 2020-05-17 23:15:45 CEST; 11s ago*
  • Docs: man:interfaces(5)*
    
  • Process: 5524 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)*
  • Main PID: 5524 (code=exited, status=1/FAILURE)*
    May 17 23:15:45 xerxes ifup[5524]: ifup: failed to bring up eth0
    May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_sender_restrictions
    May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_client_restrictions
    May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_helo_restrictions
    May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_sender_restrictions
    May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_client_restrictions
    May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_helo_restrictions
    May 17 23:15:45 xerxes systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
    May 17 23:15:45 xerxes systemd[1]: networking.service: Failed with result ‘exit-code’.

So the server is issuing warnings even if I do not try to restart the network and with these three elements defined.

Postfix is running and working for my email but I cannot raise IPv6 on eth0 because of this issue (there may be others but this one is the current blockage).

I have posted a request on the postfix.org mailing list to see if someone there can help but I think the items I have read on the internet about these three settings being deprecated may be right and it is the binary postconf calling for something historic that is not required?

Will post any more info I get on it.

I don’t believe the mua_ lines in master.cf should be uncommented unless you are trying to use them. I run CentOS 7 with Postfix 2.10.1 via yum (2:2.10.1-9.el7 from @base repo), what version are you on? What postfix guide did you follow? Some of the syntax and config variables have changed between versions.

Post the contents of your /etc/postfix/master.cf, postconf -n and /etc/postfix/main.cf (with sensitive info redacted where you feel appropriate). I reckon it’s a syntax error somewhere.

(I just noticed https://serverfault.com/a/997298/32054, perhaps a red herring, perhaps not?..)

something in your main.cf perhaps. check for those undefined :
grep -nir mua_ /etc/postfix

@GeoffatMM
Sorry for not reading the first post correctly, but you said it happend after you followed a guide (possible that that guide is wrong). So undo the changes and if it works, then you either did something wrong or the guide is wrong.
In general, Debian 10 works out of the box with IPv6. So what exactly are you trying to do?

@dimitrist, @chriswoods @DrCarsonBeckett thanks for the input. For some reason the initial white space on some of the argument lines in master.cf had been removed or not inserted. So Postconf was trying to read an unknown instruction. I reinserted the white space (and also removed duplicated lines) and postconf is now happy, so that is solved.

I am trying to set my IPv6 up on the only live interface eth0. It works for IPv4 but will not raise when I have the IPv6 elements defined.

I have renamed the post to IPv6 (and not postfix) Issues to better reflect the real issue.

Here is my interface.d/xxx.cf file:

auto lo
iface lo inet loopback
dns-nameservers xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx 127.0.0.1

auto eth0
iface eth0 inet static
address xxx.xxx.xxx.xxx
netmask 255.255.255.0
gateway xxx.xxx.xxx.1
broadcast xxx.xxx.xxx.255
network xxx.xxx.xxx.0
post-up iptables-restore < /etc/iptables.up.rules
mtu 1500
dns-nameservers 127.0.0.1 xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx

iface eth0 inet6 static (these are the lines I added according to the OVH guide)
address xxxx:xxxx:xxxx:2000:0:0:0:2097
netmask xxxx:xxxx:xxxx:2000::/128
post-up /sbin/ip -6 route addxxxx:xxxx:xxxx:2000:0000:0000:0000:0001 dev eth0
post-up /sbin/ip -6 route add default via xxxx:xxxx:xxxx:2000:0000:0000:0000:0001 dev eth0
pre-down /sbin/ip -6 route del default via xxxx:xxxx:xxxx:2000:0000:0000:0000:0001 dev eth0
pre-down /sbin/ip -6 route del xxxx:xxxx:xxxx:2000:0000:0000:0000:0001 dev eth0

Having fixed the postfix issues when I now run service networking restart I get:

service networking restart
Job for networking.service failed because the control process exited with error code.
See “systemctl status networking.service” and “journalctl -xe” for details.

journalctl -xe does not appear to give details relating to interfaces and systemctl status networking.service only gives:

networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2020-05-19 01:33:39 CEST; 1min 32s ago
Docs: man:interfaces(5)

Process: 22535 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
Main PID: 22535 (code=exited, status=1/FAILURE)
May 19 01:33:38 xerxes systemd[1]: Starting Raise network interfaces…
May 19 01:33:38 xerxes ifup[22535]: RTNETLINK answers: File exists
May 19 01:33:38 xerxes ifup[22535]: ifup: failed to bring up eth0
May 19 01:33:39 xerxes systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
May 19 01:33:39 xerxes systemd[1]: networking.service: Failed with result ‘exit-code’.
May 19 01:33:39 xerxes systemd[1]: Failed to start Raise network interfaces.

eth0 is clearly up (I assume but maybe I am wrong?) because I am in constant contact with the server over ports 22 and 10000. (Actually I remain in contact even if I run the stop command! Is this right?).

I tried to read ifup but it is full of ??? and non meaning words so not sure what to do or what the problem is.

Any ideas of what to try next?

Addendum:

I commented out the IPv6 statements completely and then ran service networking restart and got the same error so it may not even be the IPv6 entries that is causing my problem. IPv6 is not working because if I search the address it returns nothing and running IPv6 tests on xorex.rocks says either no address detected or IPv6 is not supported (which it is).

I’ve been caught out by similar ‘which side of the equals’ stupid syntax problems with Python (that and mixing spaces and tabstops… you only do that once)

In your previous post, I presume the addxxxx:xxxx:xxxx:2000:0000:0000:0000:0001 dev eth0 is a typo? (no space between add and start of your v6 address?)

From a prompt, curl -6 ifconfig.co will return your public IPv6 address if it’s operational. Very handy.

I wouldn’t bother with the route add and route del, the OS should sort that out for you automagically based on your gateway. Speaking of which, where are you defining default gateway?

Oh my CentOS box, in /etc/sysconfig/network-scripts/ifcfg-eth0, I define my config slightly differently;

... (IPv4 stuff above)
IPV6_FAILURE_FATAL=no
TYPE=Ethernet
DEVICE=eth0
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6ADDR=my:ipv6::addr:ess:1/64
#IPV6_DEFAULTGW=fe80::1
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
ONBOOT=yes
DNS6=my:provi:ders:ipv6:dns:serv:er

Debian 10 Buster uses hardware-based names (eno0, enp0s12c3, etc) - what does ls /sys/class/net show?

If your machine does indeed use eth0 then syntax like this will work for a static IPv6 in /etc/network/interfaces:

iface eth0 inet6 static
    address xxxx:xxxx:xxxx:2000:0:0:0:2097
    netmask 128
    gateway 2001:aabb:ccdd:eeff:1122:3344:dead:beef

then sudo systemctl restart networking… Then curl -6 ifconfig.co :wink:

(do you have conman installed? That will supercede interfaces)

@chriswoods thanks. It was a typo. Busy yesterday but will work through your suggestions later today.

1 Like

This was the result!

~# curl -6 ifconfig.co
curl: (7) Couldn’t connect to server

This was the result. It is a standard Buster implementation but maybe Virtualmin has reset the interfaces?

ls /sys/class/net
eth0 lo tun0 tun1

I have not inserted a dns server as it was not asked for on the OVH guide but if I am using a static address I guess I need to define the IPv6 DNS server as well? I will add that first to see what happens then try your setup to see if that changes anything.

Sorry for the delay in response just really busy (and tired!).

Hmm, interesting. Did you follow this OVH guide by the way - https://docs.ovh.com/gb/en/dedicated/network-ipv6/ , if so is your gateway set correctly? According to those OVH docs your gateway should look like your:ipv6:block:here:FF:FF:FF:FF

They also recommend in /etc/sysctl.conf
net.IPv6.conf.all.autoconf=0
net.IPv6.conf.all.accept_ra=0

I’d always define DNS servers when using a static IP. You can abbreviate netmask just to 128 if you want. The syntax of the post-up stuff looks OK to me though…

I forgot to mention, make sure the ipv6 kernel module’s loaded:
lsmod | grep ipv6
If not,
modprobe ipv6

What does service networking status output with the updated inet6 stanza?

Try ping6 and traceroute6 to a few IPv6 addresses if you think the interface is up, e.g.

google dns: [2001:4860:4860::8888]
cloudflare dns: [2606:4700:4700::1111]

With the modified network config syntax and a networking restart, does it show any active ipv6 interface? Is the interface actually up according to ifconfig? If so can you ping the gateway and whatever ipv6 DNS servers OVH operate?

Also don’t forget to check ip6tables for either a default policy of ALLOW on INPUT and OUTPUT, or that you have rules in place to permit necessary traffic for testing.

I’d double check with OVH that your ipv6 networking is enabled on the host side and that they’ve given you correct details. You also have tun0 and tun1 interfaces, you running a VPN client/server?

Hi Chris
I am still having problems. I set up a nameserver reference but it made no difference. I ahve been too busy to do anything else until today.

No, I used this one https://docs.ovh.com/gb/en/vps/configuring-ipv6/ as my server is a vps not a dedicated but I will go through the dedicated servers guide to see if it helps.

When I first set up the server I could not get my dns servers to show up in the Networking Interfaces section of webmin. I overcame it by inserting my own file under /etc/network/interfaces.d/

I am now having the same problem with IPv6 even though the interface is defined in the same file. Something is changing the interface entries. So in webmin:networking:network configuration the “Activated at Boot” entry gives:

Name Type. |Pv4 address. Netmask. IPv6 address Active
eth0 Ethernet 51.75.171.43 255.255.255.0 2001:41d0:801:2000:0:0:0:2097 Yes

based on the IPv6 address from my OVH control panel. However the “Active Now” entry gives:

Name Type. |Pv4 address. Netmask. IPv6 address Active
eth0 Ethernet 51.75.171.43 255.255.255.0 fe80::f816:3eff:fee4:8bb7. Up

Google tells me that fe80 is a link-local address which means nothing to me! Any ideas what is happening?

Chris, some more info. The dedicated servers have a different block of addresses so their gateways always end in FF:FF:FF etc. My gateway is defined for my VPS and is shown in my dashboard and that is the one I have used.

I have tried to amend sysctl,conf but when I run
sh sysctl -p
Iget:
sh: 0: Can’t open sysctl

I have rebooted the server which I hope will engage the revised sysctl.conf file/

I have added the IPv6 equivalent addresses for my dns servers (Including ::1 for localhost).

lsmod:

lsmod | grep ipv6
nf_defrag_ipv6 20480 1 nf_conntrack

service networking status
● networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2020-06-04 00:19:03 CEST; 5min ago
Docs: man:interfaces(5)
Process: 303 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
Main PID: 303 (code=exited, status=1/FAILURE)

Jun 04 00:19:02 xerxes systemd[1]: Starting Raise network interfaces…
Jun 04 00:19:02 xerxes ifup[303]: ifup: waiting for lock on /run/network/ifstate.eth0
Jun 04 00:19:03 xerxes ifup[303]: RTNETLINK answers: File exists
Jun 04 00:19:03 xerxes ifup[303]: ifup: failed to bring up eth0
Jun 04 00:19:03 xerxes systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Jun 04 00:19:03 xerxes systemd[1]: networking.service: Failed with result ‘exit-code’.
Jun 04 00:19:03 xerxes systemd[1]: Failed to start Raise network interfaces.

which is wierd because eth0 is up (well for IPv4 at least I guess?
ping6 asnd traceroute6 both report network unreachable so it is not working on IPv6

If so can you ping the gateway and whatever ipv6 DNS servers OVH operate? Again network unreachable.

I have already checked with OVH and they say it should just work.

That is all I have time for tonight. I will look into ip6tables tomorrow. This is probably the issue!

Thanks for your help.

Chris

I have looked at the IPv6 firewall that webmin set up for me when I added IPv6 (I guess).

I am not an iptables expert but here is the file for you in case you are!

Can I disable the firewall briefly to test if that is the problem? Or is there another way to test it?

Generated by webmin

[I have removed this detail as it was not the problem, Geoff]

Also,

Yes you are correct, I am running a VPN on the server over IPv4 which is working fine.

Tested ipv6 iptables and that was not the problem. Decided to play with the interfaces and although I am not sure which change did it (I suspect it was the netmask which I changed to a simple statement of netmask 64) but it is now working.

Another issue I discovered was that my ISP (SFR in France) is not yet IPv6 enabled so my attempts to test the pong on the IP6 address was failing as a result, even when I ran through my vpn so I was only finally able to check it using a remote IPv6 checker (https://ipv6-test.com/validate.php).

Clearly this does not help me as long as my ISP block IPv6 traffic but that is an issue I will now address with them.

Thanks all for trying to help. I am closing this now.

Geoff