Authentication not working over BOVPN

scottnicklessscottnickless
in Firebox - Authentication

Hi All,

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 [userid@domain.com.au]
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==>userid@domain.com.au
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 [userid@domain.com.au] Error, Reason - Ldap binding not successful
2020-12-29 20:25:48 admd Authentication of Firewall user [userid@domain.com.au] 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.

Comments

  • Bruce_BriggsBruce_Briggs

    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.

  • scottnicklessscottnickless

    Thanks Bruce,

    @Bruce_Briggs said:
    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

    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.

    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 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?

  • Bruce_BriggsBruce_Briggs

    For normal BOVPNs, when this happens the resolution is to add the external interface IP addr to the BOVPN Tunnel settings.

  • scottnicklessscottnickless

    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.

  • Bruce_BriggsBruce_Briggs

    'normal' meaning a non-AWS BOVPN.

  • scottnicklessscottnickless

    Hi Bruce,

    @Bruce_Briggs said:
    '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?

    Thanks
    Scott

  • Bruce_BriggsBruce_Briggs

    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.

  • scottnicklessscottnickless

    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.

    Thanks
    Scott

  • Bruce_BriggsBruce_Briggs

    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.

  • ahudeahude

    What is the latest on this trouble? I am a seasoned WG engineer and am currently having this issue and trying to explore all options before contacting support.

  • kimmo.pohjoisahokimmo.pohjoisaho

    If you are using the route-based BOVPN Vif configuration, try to configure a free IP address from your on-prem network in the BOVPN Vif / VPN Routes / Assign virtual interface IP addresses config.

    Firebox is now using this address when it is connecting to the remote LDAP through the VPN tunnel.

  • scottnicklessscottnickless

    Hi @ahude,

    @ahude said:
    What is the latest on this trouble? I am a seasoned WG engineer and am currently having this issue and trying to explore all options before contacting support.

    We ended up dropping Watchguard for another brand. Our firewall hardware was out of date and support had expired years before I posted this, so with no option of a firmware update or ability to log a support request, we made the business decision to move to a different brand.
    Sorry I couldn't be of more help.

Sign In to comment.