PDU cannot connect to mailcow

MitchR

I have a PDU that sits in a 172.17.1.101 IP spacing that cannot connect to my Mailcow instance that sits at 172.22.201.220 via port 25 or 465. I have basically totally disabled the FW and DACL between the two subnets but i cannot even see any traffic from the PDU to the Mailcow server when reviewing the Mailcow logs. i did notice in the mailcow system there is a docker0 network interface that sits in that 172.17 ip space, ive disabled that to get some network traffic to flow from mailcow to the pdu but still cannot see any traffic on the docker compose logs. any help would be greatly appreciated.

ETNyx

Well first of all, did you break your instance after disabling docker networking?

If you have some kind of conflict in network space allocation there is environment variable for this, look to your .env.

MitchR

nope it still worked after disabling that docker0, from what I’ve been able to figure out that’s just the default docker bridge that gets created by default when docker is installed, all the Mailcow containers are using the Mailcow bridge i believe so luckily it didn’t break anything.

ill look at the .env

MitchR

after modifying the docker.service file to make the docker0 default bridge adapter use 192.168.0.254/24 then restarting the box im getting logs now from the PDU since that interface isnt in the ip space of my PDU. I am getting logs now at least showing traffic from my PDU but now getting SSL_ACCEPT error from the PDU IP, trying to narrow down what the issue is now.

DocFraggle

Use port 587 to send mails with authentication

MitchR

changed the port over to 587, and got a different error see below. the first attempt was just after i changed the port on the PDU, the second attempt when it starts to read the DNS name is after i added the ip to the fail2ban whitelist hosts

ETNyx

Guess that warning for invalid SNI are because those domain’s are not trusted by your CA, did you make them trusted?

Bigger problem is SSL_accept error. This is usually client configuration error, like enforcing explicit TLS on 465 or outdated cipher suit, like forcing SSL3.0 on client. How is your client configured?

MitchR

The PDU has a certificate from our internal CA, theres nothing else on the PDU that i can configure to say its from a trusted domain.

this is the cert info from git when doing a openssl s_client connect command, had to clear some info out due to sanitization.

$ openssl s_client -connect sdn9001vpdu124r1g=:443
Connecting to 172.17.1.101
CONNECTED(000001D0)
depth=0 sanitized, CN=SDN9001VPDU124R1G
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 sanitized, CN=SDN9001VPDU124R1G
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 sanitized, CN=SDN9001VPDU124R1G

verify return:1

Certificate chain
0 s:sanitized, CN=SDN9001VPDU124R1G
i:sanitized, CN=SDN-CA2-CA
a😛KEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256

v:NotBefore: Aug 4 15:49:23 2025 GMT; NotAfter: Aug 4 15:49:23 2027 GMT

Server certificate
—–BEGIN CERTIFICATE—–
sanitized
—–END CERTIFICATE—–
subject=sanitized, CN=SDN9001VPDU124R1G

issuer=sanitized

No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS

Server Temp Key: ECDH, secp384r1, 384 bits

SSL handshake has read 2883 bytes and written 841 bytes

Verification error: unable to verify the first certificate

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
removed for sanitization
Start Time: 1754916497
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: no

Max Early Data: 0

read R BLOCK

D0140000:error:0A000126:SSL routines::unexpected eof while reading:../openssl-3.2.4/ssl/record/rec_layer_s3.c:689: