I am trying to set up transparent IPSEC encryption between clients and servers in our domain. I've set up connection security rules for transport mode via GPO for clients and servers (transport "server-to-server" type). The connection security
rule has our IPv4 address space (123.4.0.0/16) configured for "Endpoint 1" and the rest of the Internet (0.0.0.0-123.3.255.255, 123.5.0.0-223.255.255.255) for "Endpoint 2". The server's definitions are set to "Require inbound and request
outbound", the client's definitions are to "Request inbound and outbound". On the server's side, a single generic firewall rule is configured to "Allow connection if secure" and "require encryption" for all protocols and
all addresses.
All of servers have public IPv4 addresses, clients may either be behind a NAT device on foreign networks or have public IPv4 addresses on our network.
I can observe that in some cases a client would not start IKE negotiations with the destination server even though it is covered by the connection security rule. Example:
PS C:\Windows\system32> ping 123.4.6.61 -n 1
Ping wird ausgeführt für 123.4.6.61 mit 32 Bytes Daten:
Antwort von 123.4.6.61: Bytes=32 Zeit=82ms TTL=119
Ping-Statistik für 123.4.6.61:
Pakete: Gesendet = 1, Empfangen = 1, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 82ms, Maximum = 82ms, Mittelwert = 82ms
PS C:\Windows\system32> Get-NetIPsecQuickModeSA | ft
Name LocalEndpoint RemoteEndpoint TransportLayerFilterName EncapsulationMode Direction LocalPort RemotePort IpProtocol
---- ------------- -------------- ------------------------ ----------------- --------- --------- ---------- ----------
168 192.168.246.54 123.4.6.61 IPSec Transport Inbound
168 192.168.246.54 123.4.6.61 IPSec Transport Outbound
154 192.168.246.54 123.4.7.26 IPSec Transport Inbound
154 192.168.246.54 123.4.7.26 IPSec Transport Outbound
167 192.168.246.54 123.4.7.25 IPSec Transport Inbound
167 192.168.246.54 123.4.7.25 IPSec Transport Outbound
PS C:\Windows\system32> ping 123.4.6.62
Ping wird ausgeführt für 123.4.6.62 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Ping-Statistik für 123.4.6.62:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust),
PS C:\Windows\system32> Get-NetIPsecQuickModeSA | ft
Name LocalEndpoint RemoteEndpoint TransportLayerFilterName EncapsulationMode Direction LocalPort RemotePort IpProtocol
---- ------------- -------------- ------------------------ ----------------- --------- --------- ---------- ----------
173 192.168.246.54 123.4.7.25 IPSec Transport Inbound
173 192.168.246.54 123.4.7.25 IPSec Transport Outbound
174 192.168.246.54 123.4.6.61 IPSec Transport Inbound
174 192.168.246.54 123.4.6.61 IPSec Transport Outbound
154 192.168.246.54 123.4.7.26 IPSec Transport Inbound
154 192.168.246.54 123.4.7.26 IPSec Transport OutboundIn the network trace of the client machine (Windows 10 1803), I can see that it is not even trying to send an IKE packet to 123.4.6.62, although it perfectly connected to 123.4.6.61. This might be reversed after the client has been rebooted.
How could I debug this and is there any known remedy to this problem?
Kind regards,
While all servers have public IPv4 addresses, clients may either be behind a NAT device on foreign networks or have public IPv4 addresses on our network