Hi CheckMates,
I have an L2TP remote access client connecting to a single R81.10_T66 gateway (my test gateway). The client gets allocated an IP address from an internal dhcp server and can access resources on the internal network based on a simple access policy. All works great on a single gateway!
I need to move the Remote Access vpn to a production gateway cluster but the L2TP client fails to connect. The user is prompted for logon credentials but the connection does not complete and times out. The client machine reports that the remote computer (the cluster) failed to respond and I get the same symptoms with both an R80.40 (T89) gateway cluster and an R81.10 (T66) cluster.
The single gateway and both clusters are managed by the same SMS so the pre-shared key, RemoteAccess community, the ldap group that Office Mode is offered to, etc. are consistent across the gateways. However, there is a difference in the VPN encryption domain used on the production R80.40 cluster. There are some other IPsec VPNs already in place so the VPN Domain is already set and I don’t want to change it in the production environment. I don’t have those same restrictions on the R81.10 cluster so I matched up the VPN Domain setting to my test gateway but the client still gets a connection failure and a timeout.
The RemoteAccess community uses the same VPN domain group on all three setups and it should override the VPN Domain setting on the gateway and clusters.
Both clusters use the same dhcp server as the single (test) gateway, the R80.40 cluster even uses the same dhcp subnet but I have had to set up a different subnet for the R81.10 cluster.
Network routing has been checked and the assigned dhcp subnet is being routed back to the relevant cluster.
DHCP Relay is NOT configured on the cluster members because it was not required on the single gateway.
Question: Do clusters behave differently and do I need to configure DHCP Relay on the cluster in this scenario?
I followed sk17957 L2TP debugging and the R81.10 cluster does not appear to have a path back to the client’s WAN IP whereas the single gateway does. I have not done debugging on the R80.40 cluster.
Output from the single R81.10 gateway:
@;21785559;[cpu_0];[fw4_1];l2tp_inbound_chain: L2TP packet arrived from 84.xxx.yyy.184.;
@;21785559;[cpu_0];[fw4_1];l2tp_inbound_chain: packet details: IP=a15d020, status=3;
@;21785559;[cpu_0];[fw4_1];check_ipsec_mspi_and_set_l2tp_mspi: MSPI with which the packet was decrypted and in the sessions table is 800007 (i: 1). Replacing with MSPI 800009 (i: 1) for an L2TP connection.;
@;21785559;[cpu_0];[fw4_1];check_ipsec_mspi_and_set_l2tp_mspi: Decrypt message updated.;
@;21785559;[cpu_0];[fw4_1];l2tp_inbound_chain: Session is <84.xxx.yyy.184 1701 14499 9687>. Decapsulating. Internal connection src=10.aaa.bbb.32; dst=204.ddd.eee.239.;
I don’t know where the 204.ddd.eee.239 address comes from because it is not the client’s WAN IP but at this point the client has been successfully allocated IP address 10.aaa.bbb.32 by the internal dhcp server and the client is connected.
Output from the R81.10 cluster:
@;27541528;[vs_0];[tid_19];[fw4_19];l2tp_inbound_chain: L2TP packet arrived from 84.xxx.yyy.184.;
@;27541528;[vs_0];[tid_19];[fw4_19];l2tp_inbound_chain: Fixing UDP checksum of PPP message. Probably using NAT-T.;
@;27541528;[vs_0];[tid_19];[fw4_19];l2tp_inbound_chain: packet is PPP with protocol c021. Passing to daemon.;
@;27541528;[vs_0];[tid_19];[fw4_19];vpn_tagging_chain: chain(0x7f1e46490e48), connection type : CONN_ENC_CLIENT (3) (3);
@;27541528;[vs_0];[tid_0];[fw4_0];handle_update_tu_duration: Entering;
@;27541528;[vs_0];[tid_19];[fw4_19];vpn_decrypt_verify: Got decryption message with MSPI 880000c (i: 17).;
@;27541528;[vs_0];[tid_0];[fw4_0];get_msa_by_mspi: Found MSA for mspi 880000c (i: 17) in global table.;
@;27541528;[vs_0];[tid_19];[fw4_19];get_msa_by_mspi: Found MSA for mspi 880000c (i: 17) in global table.;
@;27541528;[vs_0];[tid_0];[fw4_0];handle_update_tu_duration: Session guid is: 0 0 0 0;
@;27541528;[vs_0];[tid_0];[fw4_0];handle_update_tu_duration: Failed to get user_login_info entry;
@;27541528;[vs_0];[tid_19];[fw4_19];vpn_decrypt_verify:Packet Dropped -- CONN_ENC_NO_ENTRY[_SR] with packet reversed to the original direction of the connection;
At this point cluster appears to have no path back to the client so the client gets no response.
Any ideas why the cluster does not have a return path and the client does not get a dhcp address?
Thanks
Steve
