Incoming mail / Servicedesk force IPv4

Hi Everyone,

I’m currently facing a problem where I can not use any form of incoming mail. The self-hosted instance of gitlab is behind a firewall which can’t be bothered to route IPv6 traffic for dynamic WAN adresses. For technical reasons, I’m forced to stay with both, the firewall itself and the dynamic IPv6 address. Furthermore, I’d like to use Office 365 to handle mail traffic for me. Even if i wanted to, I cannot change this either.

Now, if I run gitlab-rake gitlab:incoming_email:check to debug into why it’s not working, it’ll display the IPv6 address of the mailserver. Even if I insert the FQDN or IPv4 in the config file (gitlab.rb). I disabled IPv6 completely on the Server (Ubuntu) with no effect at all:

sudo gitlab-rake gitlab:incoming_email:check
Checking Incoming Email ...

Incoming Email: ... Checking Reply by email ...

IMAP server credentials are correct? ... Checking XXXXXXXXX@XXXXXXXXX
no
  Try fixing it:
  An error occurred: Errno::EADDRNOTAVAIL: Cannot assign requested address - connect(2) for [2603:1026:205:14::2]:993
  Check that the information in config/gitlab.yml is correct
  For more information see:
  doc/administration/reply_by_email.md
  Please fix the error above and rerun the checks.
Init.d configured correctly? ... skipped
MailRoom running? ... skipped

Is there any way to force gitlab to use IPv4 for incoming mail as well as for service desk? Or am I just missing a very very simple solution because I’ve already wasted way to much time on that and becoming blind? :wink:

Would be great to get help.
Thank you!

Anyone got a idea?

How did you disable ipv6? Usually I find this has to be done in /etc/default/grub or whatever depending on your distro similar to this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash ipv6.disable=1"

the key part ipv6.disable=1. Providing you have done that, then your system will totally use ipv4 and nothing else. Which means everything will be routed over ipv4, and all your services that are running on the server should also as well. Sometimes you might have to check the configuration after disabling ipv6 to make sure it’s not attempting to use it. Not just for gitlab, but for other services as well.

Also ensure, after disabling ipv6 that you do:

gitlab-ctl reconfigure

to make sure that gitlab will then solely be using ipv4. Perhaps you didn’t do this, and it’s still trying to communicate on ipv6.

If after this you still have problems, then you’ll need to provide much more detail about your system, as otherwise it’s impossible to help.

Hi there and many thanks for answering!

yep, I did totally disable IPv6. I did it the steps like described here: https://linuxconfig.org/how-to-disable-ipv6-address-on-ubuntu-18-04-bionic-beaver-linux

I think I can verify that IPv6 is disabled. Neither ip a shows a trace of IPv6 nor does a ping returns a valid response anymore

$ ping google.com
PING google.com (142.250.184.238) 56(84) bytes of data.
64 bytes from fra24s12-in-f14.1e100.net (142.250.184.238): icmp_seq=1 ttl=120 time=5.37 ms
$ ping google.com -6
ping: socket: Address family not supported by protocol
$ getent ahosts localhost
127.0.0.1       STREAM localhost
127.0.0.1       DGRAM
127.0.0.1       RAW

gitlab:

$ sudo gitlab-rake gitlab:incoming_email:check

Checking Incoming Email ...

Incoming Email: ... Checking Reply by email ...

IMAP server credentials are correct? ... Checking XXX@XXX.XXX
no
  Try fixing it:
  An error occurred: Errno::EAFNOSUPPORT: Address family not supported by protocol - socket(2)
  Check that the information in config/gitlab.yml is correct
  For more information see:
  doc/administration/reply_by_email.md
  Please fix the error above and rerun the checks.
Init.d configured correctly? ... skipped
MailRoom running? ... skipped

Checking Reply by email ... Finished


Checking Incoming Email ... Finished

Gitlab (ce) 14.4.2 is running on a ubuntu 20.04 VM based on VMware. Said VM only runs gitlab and its needed services, nothing else.

My first guess was that I was either missing a simple setting or it’s a common, easy to fix problem… But seems like my system is not configured correctly or is having some trouble, right?
Is there a easy way to fix or at least to trick gitlab into thinking everything is configured in a correct (IPv4) way?

You could do with posting the configuration you made in gitlab.rb or wherever you put this incoming email configuration, as we cannot see that in your posts. That could help show whether your configuration is actually wrong and potentially the reason for it failing.

Since if you disabled ipv6 in grub as per the article (the sysctl stuff is not enough on it’s own), then ipv6 isn’t on the machine. Running ifconfig would show more successfully whether it’s disabled or not. If you see inet6 in the ifconfig results, that would mean it’s still enabled.

Also, just in case and like I wrote, did you re-run gitlab-ctl reconfigure after disabling ipv6 and rebooting the server? Also would help to see your gitlab.rb to find out exactly what changes are listed in here, just in case an ipv6 config option is still enabled. For example:

nginx['listen_addresses'] = ['123.456.789.123', '[::]']

that shows ipv6 as an option for listening on. You can also check/verify with:

netstat -tunlp

if you see results like this:

tcp6       0      0 :::80                   :::* 

that also shows that ipv6 is still enabled as well as from ifconfig inet6 results. Anyway, please post all your configuration (make sure to change sensitive data like hostname, ip addresses, usernames, passwords) before posting here. As without that, impossible to diagnose further.

Here we go with the config reduced to only the mail-related stuff

gitlab.rb - mail stuff
## GitLab URL
external_url 'http://XXX.XX'

### Email Settings
gitlab_rails['gitlab_email_enabled'] = true
gitlab_rails['gitlab_email_from'] = 'git@XXXXX'
gitlab_rails['gitlab_email_display_name'] = 'XXX GitLab'
gitlab_rails['gitlab_email_reply_to'] = 'noreply@XXX'
gitlab_rails['gitlab_email_subject_suffix'] = '[GIT]'

### Default Theme
gitlab_rails['gitlab_default_theme'] = 2

### Reply by email
gitlab_rails['incoming_email_enabled'] = true

#### Incoming Email Address
gitlab_rails['incoming_email_address'] = "git+%{key}@XXXX.XX"
gitlab_rails['incoming_email_email'] = "XXXX@XXXX.XXXX"
gitlab_rails['incoming_email_password'] = "XXXX"

#### IMAP Settings
gitlab_rails['incoming_email_host'] = "outlook.office365.com"
gitlab_rails['incoming_email_port'] = 993
gitlab_rails['incoming_email_ssl'] = true
gitlab_rails['incoming_email_start_tls'] = true
gitlab_rails['incoming_email_mailbox_name'] = "inbox"
gitlab_rails['incoming_email_idle_timeout'] = 60
gitlab_rails['incoming_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"

### Service Desk
gitlab_rails['service_desk_email_enabled'] = true
gitlab_rails['service_desk_email_address'] = "git+%{key}XXXX.XXXX"
gitlab_rails['service_desk_email_email'] = "XXXX@XXXX.XXXX"
gitlab_rails['service_desk_email_password'] = "XXXX"
gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
gitlab_rails['service_desk_email_idle_timeout'] = 60
gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
gitlab_rails['service_desk_email_host'] = "outlook.office365.com"
gitlab_rails['service_desk_email_port'] = 993
gitlab_rails['service_desk_email_ssl'] = true

In case you need it, here is the whole file

I 've tried to stay close to the official docs on how to configure the incoming mail, especially the microsoft 365 part.

My instance might be configured in a non-complete state and for internal testing only, not for production on a internet-accessable machine. However, the machine is able to access the internet.

Yes, I did run gitlab-ctl reconfigure after all that changes made to the networking settings. Sorry, did not mention that before :confused:

ifconfig returns only IPv4 stuff:

ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.XXX.XXX netmask 255.255.255.0  broadcast 192.168.XXX.255
        ether XX:XX:XX:XX:XX:XX  txqueuelen 1000  (Ethernet)
        RX packets 280203  bytes 38669790 (38.6 MB)
        RX errors 0  dropped 2870  overruns 0  frame 0
        TX packets 34092  bytes 10974670 (10.9 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 229507  bytes 753627191 (753.6 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 229507  bytes 753627191 (753.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

same on netstat -tunlp, only IPv4-addresses are shown. So I’m pretty sure that I’ve killed IPv6 on that machine, right?