Skip to content
Docs

Fix Mideye External Service Issues — MAS, Switch & Shield

Mideye Server integrates with multiple external services for authentication, magic links, and security features. This guide addresses connectivity and integration issues with these services.

Overview

Section titled “Overview”

Mideye Server communicates with several external services:

ServicePurposeDefault EndpointDefault Port
MAS (Mideye Activation Server)Magic link authenticationmas.mideyecloud.se443 (HTTPS)
Mideye SwitchSMS OTP and mobile app authenticationprimary.mideye.com / secondary.mideye.com20460 (TLS)
Mideye ShieldIP reputation and threat detectionConfigurable443 (HTTPS)

Connection issues with these services can cause authentication failures, degraded functionality, or complete service unavailability.

Common Error Messages

Section titled “Common Error Messages”
Error MessageLikely CauseSection
”Failed to connect to primary switch”Switch unreachable or SSL proxy interceptingSwitch Issues
”Failed to connect to secondary switch”Both switches unreachableSwitch Issues
”Failed to get magic link frontend URL”MAS connectivity issueMAS Issues
”Magic link URL not loaded”MAS unavailable at startupMAS Issues
”Failed to query IP”Shield service unreachableShield Issues
”Connection timed out”Firewall or network issueProxy Configuration
Section titled “MAS (Magic Link) Connection Issues”

Overview

Section titled “Overview”

MAS (Mideye Activation Server) provides magic link functionality for passwordless authentication. Mideye Server queries MAS to get magic link URLs and frontend configuration.

Default MAS URL: https://mas.mideyecloud.se

Silent Failure at Startup

Section titled “Silent Failure at Startup”

During startup, Mideye Server attempts to load the magic link frontend URL from MAS. If MAS is unreachable at that point, the load fails silently — the service starts normally but magic link functionality will not work.

The server automatically retries loading the URL every 10 minutes. Until a successful load, magic link authentication fails.

Symptoms

Section titled “Symptoms”
  • Magic link authentication fails with generic error
  • Users cannot complete magic link flows
  • Log shows: “Failed to get magic link frontend URL”
  • Magic links start working after ~10 minutes if MAS becomes available

Diagnostic Steps

Section titled “Diagnostic Steps”

  1. Check MAS configuration in the web interface:

    • The MAS host is configured in the application settings

  2. Test connectivity to MAS:

    Linux:

    Terminal window
    curl -v https://mas.mideyecloud.se

    Windows (PowerShell):

    Terminal window
    Invoke-WebRequest -Uri "https://mas.mideyecloud.se" -UseBasicParsing

  3. Check logs for MAS connection attempts:

    • Navigate to Log Files in the web interface
    • Search for “magic” or “frontEndBaseUrl”
    • If frontEndBaseUrl shows null, MAS was not loaded successfully

  4. Test DNS resolution:

    Linux:

    Terminal window
    nslookup mas.mideyecloud.se

    Windows:

    Terminal window
    Resolve-DnsName mas.mideyecloud.se

  5. Check if proxy is required:

    If your organization uses a web proxy for outbound HTTPS traffic, Mideye Server must be configured to use it.

Solution

Section titled “Solution”

Option 1: Fix Network Connectivity

  1. Allow outbound HTTPS (port 443) to mas.mideyecloud.se through your firewall

  2. If using a proxy, configure Mideye Server:

    Edit the application configuration file:

    application:
      proxyHost: proxy.company.com
      proxyPort: 8080
      useProxy: true

  3. Test connectivity through proxy:

    Linux:

    Terminal window
    curl -v --proxy proxy.company.com:8080 https://mas.mideyecloud.se

    Windows:

    Terminal window
    Invoke-WebRequest -Uri "https://mas.mideyecloud.se" -Proxy "http://proxy.company.com:8080"

  4. Restart service to reload MAS URL:

    Linux:

    Terminal window
    sudo systemctl restart mideyeserver6

    Windows:

    Terminal window
    Restart-Service MideyeServer6

  5. Verify frontEndBaseUrl was loaded by checking the log files — it should show a URL, not null

Option 2: Wait for Automatic Retry

  • The service retries every 10 minutes
  • If MAS was temporarily unavailable, it will recover automatically
  • Monitor logs for successful load

Mideye Switch Connection Issues

Section titled “Mideye Switch Connection Issues”

Overview

Section titled “Overview”

Mideye Switch handles SMS OTP delivery and mobile app authentication. Mideye Server connects to the Switch over a TLS-encrypted connection on port 20460. The connection uses Mideye’s own CA-signed certificate for server authentication.

Default hosts:

  • Primary: primary.mideye.com (port 20460)
  • Secondary: secondary.mideye.com (port 20460)

Failover Behavior

Section titled “Failover Behavior”

Mideye Server has built-in failover:

  1. Tries primary Switch first
  2. On failure, automatically tries secondary (if configured)
  3. If both fail, authentication fails

Symptoms

Section titled “Symptoms”
  • SMS OTP not delivered
  • Mobile app approval requests not sent
  • “Failed to connect to primary switch” in logs
  • “Failed to connect to secondary switch” in logs
  • Authentication fails with switch-related errors

Basic Diagnostic Steps

Section titled “Basic Diagnostic Steps”

  1. Check Switch configuration in the web interface:

    • Verify the primary and secondary Switch hosts are configured correctly

  2. Test connectivity to Switch (port 20460):

    Linux:

    Terminal window
    nc -zv primary.mideye.com 20460
    nc -zv secondary.mideye.com 20460

    Windows (PowerShell):

    Terminal window
    Test-NetConnection -ComputerName primary.mideye.com -Port 20460
    Test-NetConnection -ComputerName secondary.mideye.com -Port 20460

  3. Test DNS resolution:

    Linux:

    Terminal window
    nslookup primary.mideye.com
    nslookup secondary.mideye.com

    Windows:

    Terminal window
    Resolve-DnsName primary.mideye.com
    Resolve-DnsName secondary.mideye.com

  4. Review logs for connection patterns:

    • Navigate to Log Files in the web interface
    • Search for “switch” to see connection attempts and failures

  5. Check if proxy is interfering:

    • Review the application configuration for proxy settings

Solution for Basic Connectivity

Section titled “Solution for Basic Connectivity”

  1. Allow outbound TCP port 20460 to primary.mideye.com and secondary.mideye.com through your firewall

  2. Configure proxy if required:

    application:
      useProxy: true
      proxyHost: proxy.company.com
      proxyPort: 8080

  3. Verify secondary Switch is configured for failover

  4. Restart service after changes:

    Linux:

    Terminal window
    sudo systemctl restart mideyeserver6

    Windows:

    Terminal window
    Restart-Service MideyeServer6

SSL Proxy / MITM Interception

Section titled “SSL Proxy / MITM Interception”

This is one of the most common and difficult-to-diagnose Switch connectivity problems.

Many corporate networks use SSL-inspecting firewalls or proxies (such as Palo Alto, Zscaler, Fortinet, or Blue Coat) that perform man-in-the-middle (MITM) TLS interception. These devices terminate the TLS connection from Mideye Server, inspect the traffic, and re-encrypt it with their own certificate before forwarding to the destination.

Mideye Server rejects these intercepted connections because it validates the Switch’s TLS certificate against Mideye’s own Certificate Authority (CA). When an SSL proxy replaces the certificate, the connection fails.

How It Works

Section titled “How It Works”
Normal connection:
  Mideye Server ──TLS──► Mideye Switch (port 20460)
  Certificate: "Mideye Switch Certificate" signed by "Mideye CA" ✓


Intercepted connection (BROKEN):
  Mideye Server ──TLS──► SSL Proxy ──TLS──► Mideye Switch (port 20460)
  Certificate: "primary.mideye.com" signed by "Corporate Proxy CA" ✗
  Mideye Server rejects this — not signed by Mideye CA

Symptoms of SSL Proxy Interception

Section titled “Symptoms of SSL Proxy Interception”
  • Switch connection fails on both primary and secondary
  • Connection test (port check) succeeds but authentication fails
  • Log shows TLS/SSL handshake failures or certificate validation errors
  • Problem appeared after a network/firewall change
  • Same Mideye Server works when connected to a different network without SSL inspection

How to Detect SSL Proxy Interception

Section titled “How to Detect SSL Proxy Interception”

Use openssl s_client to inspect what certificate the server is presenting. This is the most reliable way to detect MITM interception.

Linux:

Terminal window
openssl s_client -connect primary.mideye.com:20460 -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer

Windows (PowerShell):

Terminal window
# Using OpenSSL (if installed, e.g., via Git for Windows)
& "C:\Program Files\Git\usr\bin\openssl.exe" s_client -connect primary.mideye.com:20460 -showcerts 2>$null | Select-String "subject=|issuer="


# Alternative: PowerShell-native check
$tcpClient = New-Object System.Net.Sockets.TcpClient("primary.mideye.com", 20460)
$sslStream = New-Object System.Net.Security.SslStream($tcpClient.GetStream(), $false, {$true})
$sslStream.AuthenticateAsClient("primary.mideye.com")
$cert = $sslStream.RemoteCertificate
Write-Host "Subject: $($cert.Subject)"
Write-Host "Issuer: $($cert.Issuer)"
$sslStream.Dispose()
$tcpClient.Dispose()

What the Correct Certificate Looks Like

Section titled “What the Correct Certificate Looks Like”

When connecting directly to Mideye Switch (no MITM), you should see:

subject=C = SE, ST = Stockholm, L = Stockholm, O = Mideye, OU = Support, CN = Mideye Switch Certificate
issuer=C = SE, ST = Stockholm, L = Stockholm, O = Mideye, OU = Support, CN = Mideye CA

Key identifiers of the legitimate Mideye Switch certificate:

  • Subject CN: Mideye Switch Certificate
  • Issuer CN: Mideye CA
  • Issuer Organization: Mideye
  • Key size: 2048-bit RSA (server certificate)
  • TLS version: TLS 1.3 (TLS_AES_256_GCM_SHA384)

A full openssl s_client output for a healthy connection looks like this:

depth=1 C = SE, ST = Stockholm, L = Stockholm, O = Mideye, OU = Support, CN = Mideye CA
depth=0 C = SE, ST = Stockholm, L = Stockholm, O = Mideye, OU = Support, CN = Mideye Switch Certificate
---
Certificate chain
 0 s:C = SE, ST = Stockholm, L = Stockholm, O = Mideye, OU = Support, CN = Mideye Switch Certificate
   i:C = SE, ST = Stockholm, L = Stockholm, O = Mideye, OU = Support, CN = Mideye CA
 1 s:C = SE, ST = Stockholm, L = Stockholm, O = Mideye, OU = Support, CN = Mideye CA
   i:C = SE, ST = Stockholm, L = Stockholm, O = Mideye, OU = Support, CN = Mideye CA
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit

What an Intercepted Certificate Looks Like

Section titled “What an Intercepted Certificate Looks Like”

If an SSL proxy is intercepting traffic, you will see a different issuer. For example:

subject=CN = primary.mideye.com
issuer=CN = Corporate Proxy CA, O = Your Company, C = US

Or:

issuer=CN = Zscaler Intermediate Root CA, O = Zscaler Inc.

Or:

issuer=CN = Palo Alto Networks Inc., O = Palo Alto Networks

Any issuer that is NOT Mideye CA means the connection is being intercepted.

Solution: Bypass SSL Inspection for Mideye Switch Traffic

Section titled “Solution: Bypass SSL Inspection for Mideye Switch Traffic”

The only solution is to exempt Mideye Switch traffic from SSL inspection in your network security appliance. This is safe because Mideye Server already validates the Switch certificate against its own trusted CA.

Contact your network/security team and request an SSL inspection bypass rule for:

ParameterValue
Destination hostsprimary.mideye.com, secondary.mideye.com
Destination port20460
ProtocolTCP/TLS
SourceMideye Server IP address(es)

Example bypass configurations for common appliances:

Palo Alto Networks:

  • Create a Decryption Policy rule with Action: No Decrypt
  • Match on destination address (resolve primary.mideye.com and secondary.mideye.com)
  • Match on destination port: 20460

Zscaler:

  • Add primary.mideye.com and secondary.mideye.com to the SSL Bypass list
  • Or create a custom URL category with these domains and set the SSL Inspection policy to Do Not Inspect

Fortinet / FortiGate:

  • Create an SSL/SSH Inspection exemption for the destination addresses
  • Or use a custom deep inspection profile that excludes these destinations

Blue Coat / Symantec ProxySG:

  • Add a policy layer that skips SSL interception for traffic to primary.mideye.com:20460 and secondary.mideye.com:20460

Verifying the Fix

Section titled “Verifying the Fix”

After the bypass rule is applied:

  1. Test the certificate again:

    Linux:

    Terminal window
    openssl s_client -connect primary.mideye.com:20460 -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer

    Windows:

    Terminal window
    & "C:\Program Files\Git\usr\bin\openssl.exe" s_client -connect primary.mideye.com:20460 -showcerts 2>$null | Select-String "subject=|issuer="

  2. Confirm the issuer is Mideye CA:

    subject=C = SE, ST = Stockholm, L = Stockholm, O = Mideye, OU = Support, CN = Mideye Switch Certificate
    issuer=C = SE, ST = Stockholm, L = Stockholm, O = Mideye, OU = Support, CN = Mideye CA

  3. Restart Mideye Server:

    Linux:

    Terminal window
    sudo systemctl restart mideyeserver6

    Windows:

    Terminal window
    Restart-Service MideyeServer6

  4. Test authentication — Try an SMS OTP or mobile app authentication to verify Switch connectivity

  5. Monitor logs — Check Log Files for successful Switch connections

Switch Connectivity Behind a Web Proxy

Section titled “Switch Connectivity Behind a Web Proxy”

If your Mideye Server reaches the internet through a web proxy (HTTP/HTTPS proxy), the Switch connection on port 20460 may need special handling.

Key differences between proxy and SSL inspection:

  • A web proxy forwards traffic without inspecting TLS content (certificates pass through unchanged)
  • An SSL-inspecting proxy terminates TLS and re-encrypts with its own certificate (MITM)

If you need proxy for Switch connectivity:

application:
  useProxy: true
  proxyHost: proxy.company.com
  proxyPort: 8080

Test proxy connectivity:

Linux:

Terminal window
# Test if the proxy allows CONNECT to port 20460
curl -v --proxy proxy.company.com:8080 --connect-to primary.mideye.com:20460:primary.mideye.com:20460 https://primary.mideye.com:20460/

Windows:

Terminal window
# Test proxy connectivity
Invoke-WebRequest -Uri "https://primary.mideye.com:20460" -Proxy "http://proxy.company.com:8080" -ErrorAction SilentlyContinue

If the proxy blocks non-standard ports (only allows 80/443), request that port 20460 be allowed for primary.mideye.com and secondary.mideye.com.

Mideye Shield Connection Issues

Section titled “Mideye Shield Connection Issues”

Overview

Section titled “Overview”

Mideye Shield provides IP reputation and threat detection services. Failed Shield queries may log warnings but typically do not block authentication.

Symptoms

Section titled “Symptoms”
  • “Failed to query IP” in logs
  • Shield queries timeout
  • IP reputation data not updated

Diagnostic Steps

Section titled “Diagnostic Steps”

  1. Check Shield configuration:

  2. Test Shield endpoint connectivity:

    Linux:

    Terminal window
    curl -v https://your-shield-endpoint.com

    Windows:

    Terminal window
    Invoke-WebRequest -Uri "https://your-shield-endpoint.com" -UseBasicParsing

  3. Review logs:

    • Navigate to Log Files
    • Search for “shield” to see query attempts and failures

Solution

Section titled “Solution”
  1. Verify Shield service is accessible from Mideye Server
  2. Allow firewall access to Shield endpoints (HTTPS, port 443)
  3. Configure proxy if needed (same as MAS proxy configuration)
  4. Verify endpoint URL format (must be HTTPS)

Proxy Configuration

Section titled “Proxy Configuration”

Overview

Section titled “Overview”

If Mideye Server is behind a corporate proxy, external service connectivity requires proxy configuration.

Configuration

Section titled “Configuration”

Edit the application configuration file:

application:
  useProxy: true
  proxyHost: proxy.company.com
  proxyPort: 8080

Testing Proxy Configuration

Section titled “Testing Proxy Configuration”

Linux:

Terminal window
# Test MAS through proxy
curl -v --proxy proxy.company.com:8080 https://mas.mideyecloud.se


# Test Switch through proxy
curl -v --proxy proxy.company.com:8080 https://primary.mideye.com:20460/

Windows:

Terminal window
# Test MAS through proxy
Invoke-WebRequest -Uri "https://mas.mideyecloud.se" -Proxy "http://proxy.company.com:8080"


# Test Switch through proxy
Test-NetConnection -ComputerName primary.mideye.com -Port 20460

System-Level Proxy (Alternative)

Section titled “System-Level Proxy (Alternative)”

If the application-level proxy configuration doesn’t work, you can configure proxy at the system level:

Linux:

Terminal window
# Add to /etc/environment
export http_proxy="http://proxy.company.com:8080"
export https_proxy="http://proxy.company.com:8080"
export no_proxy="localhost,127.0.0.1,*.internal.domain.com"

Windows:

Terminal window
# Set system proxy
[System.Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.company.com:8080", "Machine")
[System.Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.company.com:8080", "Machine")

Restart the service after changing system proxy settings.

Diagnostic Commands Summary

Section titled “Diagnostic Commands Summary”

Quick Connectivity Tests

Section titled “Quick Connectivity Tests”

Linux:

Terminal window
# Test MAS
curl -v https://mas.mideyecloud.se


# Test Mideye Switch
nc -zv primary.mideye.com 20460
nc -zv secondary.mideye.com 20460


# Test Switch certificate (detect SSL proxy interception)
openssl s_client -connect primary.mideye.com:20460 -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer


# Test with proxy
curl -v --proxy proxy:8080 https://mas.mideyecloud.se

Windows (PowerShell):

Terminal window
# Test MAS
Invoke-WebRequest -Uri "https://mas.mideyecloud.se" -UseBasicParsing


# Test Mideye Switch
Test-NetConnection -ComputerName primary.mideye.com -Port 20460
Test-NetConnection -ComputerName secondary.mideye.com -Port 20460


# Test Switch certificate (requires OpenSSL, e.g., via Git for Windows)
& "C:\Program Files\Git\usr\bin\openssl.exe" s_client -connect primary.mideye.com:20460 -showcerts 2>$null | Select-String "subject=|issuer="

Monitor Connections

Section titled “Monitor Connections”

Linux:

Terminal window
# Watch logs for connection issues
tail -f /opt/mideyeserver6/log/mideyeserver.log | grep -iE "switch|mas|shield"

Windows:

Terminal window
# Watch logs for connection issues
Get-Content "C:\Program Files\Mideye Server\log\mideyeserver.log" -Wait | Select-String "switch|mas|shield"

Prevention and Monitoring

Section titled “Prevention and Monitoring”

Pre-Deployment Checklist

Section titled “Pre-Deployment Checklist”

Before deploying Mideye Server, verify external service connectivity:

  • DNS resolves primary.mideye.com, secondary.mideye.com, mas.mideyecloud.se
  • TCP port 20460 open to primary.mideye.com and secondary.mideye.com
  • HTTPS (port 443) open to mas.mideyecloud.se
  • No SSL proxy intercepting traffic to Mideye Switch (verify certificate issuer is Mideye CA)
  • Proxy configured if required for outbound internet access
  • Shield endpoint accessible if using Mideye Shield

Regular Health Checks

Section titled “Regular Health Checks”

Periodically test external service connectivity to catch issues before they affect users:

Linux:

health-check-external.sh
#!/bin/bash
echo "=== External Service Health Check ==="


# Test MAS
printf "MAS: "
curl -s -o /dev/null -w "%{http_code}" https://mas.mideyecloud.se && echo " OK" || echo " FAILED"


# Test Switch (primary)
printf "Switch Primary: "
nc -w 3 -zv primary.mideye.com 20460 2>&1 | grep -q succeeded && echo "OK" || echo "FAILED"


# Test Switch (secondary)
printf "Switch Secondary: "
nc -w 3 -zv secondary.mideye.com 20460 2>&1 | grep -q succeeded && echo "OK" || echo "FAILED"


# Check for MITM
printf "Certificate check: "
ISSUER=$(openssl s_client -connect primary.mideye.com:20460 </dev/null 2>/dev/null | openssl x509 -noout -issuer 2>/dev/null)
echo "$ISSUER" | grep -q "Mideye CA" && echo "OK (Mideye CA)" || echo "WARNING: $ISSUER"

Getting Help

Section titled “Getting Help”

If external service issues persist:

  1. Collect diagnostic information:

    • Export logs from the Log Files page (filter for “switch”, “mas”, “shield”)
    • Run connectivity tests (see commands above)
    • Document your network topology (firewalls, proxies, VPNs)

  2. For SSL proxy / MITM issues specifically, provide:

    • The openssl s_client output showing the certificate chain
    • The firewall/proxy appliance make and model
    • Whether a bypass rule was attempted

  3. Contact Mideye Support with:

    • External service configuration (sanitized)
    • Connection test results
    • Network topology description
    • Error messages from logs