AD authentication through BOVPN VI

Hi. We have sites connected via BOVPN virtual interfaces, and a spoke site is having problems authenticating SSL-VPN via AD. The tunnel is up, and I can reach the AD server from machines at the spoke site, and have verfiied authentication via ldp. But, the (T10) remote device says it can't connect to the AD server, even though it can be pinged from the web UI (via -I). There is an article that mentions having to set up specific routes for this on BOVPN:

https://watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/bovpn/manual/manual_bovpn_ad_auth_example_c.html

...but of course, this is BOVPN VI, so if this still applies, the instructions won't work.

Ideas?

Thanks...

Best Answers

  • edited May 2019 Answer ✓

    OK, opened a case with WG, and have a solution, similar to the link above. It also addresses ping situation. On the VI VPN Routes page, you have to assign a virtual IP to each end of the tunnel. According to the rep, you can use a netmask on the peer side (vs. IP), but if you use an IP, they must match. IP's in this case are unused on either side, prior to assigning to the VI.

    With this in place, SSL-VPN auth to AD across the tunnel works, as does ping.

  • edited February 2020 Answer ✓

    Ack. Already answered this. Though, one additional positive effect of using VI IP addresses is that it is crucial for remote sites with dynamic IP addresses (IKEv1 Aggressive mode).

Answers

  • Is the AD server IP addr within the route that you have set up for the BOVPN ?
    If so, then this should work if you have set up the AD properly on the T10.
    If not, then you need to add route info for this to work.
    Consider opening a support incident to get WG help to make this work

  • Thanks for the response, Bruce. Yes, the AD server is on the same route/tunnel, no NAT-T, etc. The suspicious part for me is that you have to tell the WG to use the internal interface via -I for pings, so it seems like it would need similar help to reach the AD server, thus the article linked above.

    OK, if I get no more positive responses, I'll ask WG.

  • Probably the need for the -I ping option in the Web UI is that the IP addr and thus default interface for your Web UI connection is not one which matches the Route set up for the BOVPN Virtual Interface

  • @Bruce_Briggs said:
    Probably the need for the -I ping option in the Web UI is that the IP addr and thus default interface for your Web UI connection is not one which matches the Route set up for the BOVPN Virtual Interface

    Nope. Verified that -I is needed, even when connected to the web UI from the spoke site, which is on the same subnet as the tunnel. Without -I, it tries to send the packets out to External (eth0).

  • Most odd

  • Thank you @MushyMiddle, this is the only place where I found how to do it.

Sign In to comment.