When attempting remote connections to SQL Server 2008 Express through SSMS, several configuration layers need proper setup. The key symptoms you're seeing - port showing as FILTERED in scans while LISTENING locally - indicate network-level blocking despite correct SQL Server configurations.

First, let's verify the network path is clear using these PowerShell commands:

Test-NetConnection -ComputerName your_server_ip -Port 1433
tnc your_server_ip -port 1433 -InformationLevel Detailed

If these fail, the issue lies before reaching SQL Server. Common hosting provider restrictions include:

• 1and1's internal network ACLs
• Virtual server instance-level firewalls
• Network security groups (if using cloud hosting)

For SQL Server 2008 Express specifically, these SQLCMD commands help verify configurations:

-- Verify remote connections enabled
EXEC sp_configure 'remote access', 1;
RECONFIGURE;

-- Check TCP/IP status
SELECT local_tcp_port FROM sys.dm_exec_connections 
WHERE session_id = @@SPID;

-- Verify browser service running
EXEC xp_servicecontrol 'QUERYSTATE', 'SQLBrowser';

When standard connection attempts fail, try these specialized connection string formats in your application:

// C# example with timeout and retry logic
var connectionString = "Server=tcp:your_server_ip\\SQLEXPRESS,1433;" + 
                      "Network Library=DBMSSOCN;" +
                      "Connection Timeout=30;" +
                      "Persist Security Info=False;" +
                      "Encrypt=False;" +
                      "TrustServerCertificate=True;";

For 1and1 hosted servers specifically:

1. Request dedicated IP if using shared hosting
2. Verify their "FTP Plus" firewall isn't blocking ports
3. Check if they require special port forwarding rules

If TCP/IP remains problematic, consider:

-- Configure named pipes as fallback
EXEC sp_configure 'remote access', 1;
EXEC sp_configure 'remote query timeout', 600;
RECONFIGURE;

When dealing with remote connections to SQL Server Express, the most common pain points typically revolve around three key areas:

1. Network-level connectivity (firewalls/NAT)
2. SQL Server configuration
3. Authentication protocols

From your description, several important configuration points are already in place:

• Remote connections enabled in SSMS
• TCP/IP protocol enabled in SQL Native Client
• Port 1433 explicitly set in IP1 and IPALL
• Windows firewall configured (though currently disabled)

Let's verify some crucial components through T-SQL:

-- Check server network configuration
EXEC sp_readerrorlog 0, 1, 'Server is listening on' 

-- Verify TCP/IP status
SELECT local_tcp_port 
FROM sys.dm_exec_connections 
WHERE session_id = @@SPID

The fact that your port scan shows FILTERED rather than LISTENING suggests intermediate network filtering. Typical solutions include:

1. Contacting your host provider (1and1) to confirm they allow SQL Server traffic
2. Implementing port forwarding if behind NAT
3. Testing with telnet to verify basic connectivity

Since standard ports aren't working, consider these alternatives:

-- Dynamic ports configuration example
EXEC xp_instance_regwrite 
N'HKEY_LOCAL_MACHINE', 
N'Software\Microsoft\MSSQLServer\MSSQLServer\SuperSocketNetLib\Tcp\IPAll',
N'TcpDynamicPorts', 
N'REG_SZ', 
N''

For deeper diagnostics, run these PowerShell commands from your client machine:

# Test basic TCP connectivity
Test-NetConnection -ComputerName your.server.ip -Port 1433

# Check DNS resolution
Resolve-DnsName your.server.name

• Confirm SQL Browser service is running (UDP 1434)
• Verify SQL Express instance name is correct
• Test with SQLCMD for basic connectivity
• Check for multiple network interfaces

sqlcmd -S tcp:yourserver\SQLEXPRESS,1433 -U username -P password -Q "SELECT @@VERSION"