Authentication not working over BOVPN
We have a Firebox M200 running XTM 11.9.6 (yes, it's old. I inherited it off the previous sysadmin and haven't got around to updating yet).
We changed Internet connection and since then were unable to authenticate through the Firebox to the AD. I also changed the IP on one of the vlans.
Current interface setup is:
- eth0 - WAN
- eth1 - LAN
- eth2 - VLAN
- VLAN 200 - Wifi
- VLAN 300 - Guest WIFI
The AD is a managed AD in AWS and the Firebox is connected via a BOVPN. Interesting thing is the workstations on the LAN can authenticate and ping the the AD servers across the BOVPN.
Using the Authentication > Servers > Test Connection for LDAP and Active Directory, I receive 'Connect to server: Failed (can't connect to 172.31.33.242[server is down or unreachable])'
Using Dashboard > Traffic Monitor I get the following:
2020-12-29 20:25:43 admd admPrcsAction: xpath=/authentication/diagnose 2020-12-29 20:25:43 admd admActionTestUser:get rqst [[email protected]] 2020-12-29 20:25:43 admd admGetNextAuthRqstSessId() got sessId=65584 2020-12-29 20:25:43 admd Use [domain.com.au] Svr#1 ip=0xac1f21f2 domain-name= port= 389 Score=0 2020-12-29 20:25:43 admd admActionTestUser: create hash entry OK, Id=65584 2020-12-29 20:25:43 admd admLdapSessInit: LDAP URI is ldap://[ip of ad server]:389 2020-12-29 20:25:43 admd admLdapSessInit: set LDAP referrals off for AD server ok. 2020-12-29 20:25:43 admd admLdapSessInit: ldap_initialize succeed, connHdl=0x100af240 2020-12-29 20:25:43 admd admLdapSessStartBinding: building user DN by searchBase==>OU=orgUnit,DC=domain,DC=com,DC=au 2020-12-29 20:25:43 admd admLdapSessStartBinding: dnsSuffix=[domain.com.au] 2020-12-29 20:25:43 admd admLdapSessStartBinding: search binding, using built user DN==>[email protected] 2020-12-29 20:25:48 admd admLdapSessStartBinding: search binding failed, msgId=-1, err=(null) 2020-12-29 20:25:48 admd ADM auth user [[email protected]] Error, Reason - Ldap binding not successful 2020-12-29 20:25:48 admd Authentication of Firewall user [[email protected]] from console rejected, unknown reason id="1100-0005" 2020-12-29 20:25:48 admd ct=47 **** SessHashListWalk: numEntry=1 Size=255 2020-12-29 20:25:48 admd admLdapSessFSM: state=0, secDiff=0 2020-12-29 20:25:48 admd admLdapSessFSM: Drop on default, do nothing. 2020-12-29 20:25:48 admd --Success on del sess for authRqstId=65584(0x10030) 2020-12-29 20:25:48 admd admLdapSessReleaseResource:ldap_unbind() connHdl=0x100af240
System Status > Diagnostics > Network > Ping shows 100 % packet loss to the AD server.
I've rebuilt the VPN between the AWS and firebox with no result, although I don't think that's the issue as the computers are able to authenticate normally. I feel like it's a routing or policy issue on the Firebox, but I've not changed any of that (aside from rebuilding with the correct new WAN IP address) from when it was working.
Another thought I had was the firebox is using one of the other interface IP addresses (instead of eth1) to initiate communications with the AWS resources. Because it's using the wrong IP, there is no routes or security groups in AWS to allow the IP that it's using. I'm not sure how to test / fix that theory if it's correct.
Thank you for your assistance.
2 things to try:
1) you can turn on "Enable logging for traffic sent from this device" to see if the Test Connection for LDAP packets are coming from expected firewall IP addr
2) you can specify the firewall interface to ping from using the Advanced Options, using the -I (interface) option. If it works from eth1, then you know the ping test is coming from a different firewall interface.
I enabled "Enable logging for traffic sent from this device" and found that the Firebox is sending to the DC's from the IP bound to the WAN interface.
I tried the ping, specifying eth1 as a source and the DC replied.
How do I force it to use eth1 (instead of eth0) as the source of the communications across the BOVPN?
For normal BOVPNs, when this happens the resolution is to add the external interface IP addr to the BOVPN Tunnel settings.
Are you talking about this help article: https://watchguard.com/help/docs/webui/XTM_11/en-US/index.html#cshid=en-US/bovpn/manual/manual_bovpn_ad_auth_example_c.html
I assume when you say 'normal' you mean between two Fireboxes? If it is the above article, I might be able to replicate it with the AWS site to site VPN as site A.
I'll take a look at the AWS forums and see if anyone has a solution too.
'normal' meaning a non-AWS BOVPN.
So in a 'normal' BOVPN, can you let me know what steps would be followed to fix this issue?
Add a Tunnel entry with Local = the external interface IP addr, Remote = the same as for the existing Tunnel entry.
Make the equivalent on the other end.
Just an update on this, I still haven't solved the issue. I've tried creating routes on both ends to send traffic that is destined for the AD servers, that is from (and back to) the wan interface on the Firebox, across the VPN tunnel.
Can anyone help with getting a packet trace that is longer that 50 packets so I can verify the traffic is actually going down the tunnel and not to the upstream router?
Any other information you think may be helpful too.
How are you doing the packet trace? Using TCP DUMP on your firewall?
If so, saving to disk allows a much bigger file to be captured.
Also, consider opening a support incident on this.