Comments
-
Sigh. Problem solved. I ran a diagnostic trace, and while looking at the output, found this: https://reddit.com/r/networking/comments/ezehn3/watchguard_m400_mobile_ikev2_with_radius_fun_and/ I think I had read about the limitation on the RADIUS client shared secret, and mine shouldn't have been too long, but I made it much…
-
Thanks for the quick response. From the Wireshark trace: Attribute Value Pairs AVP: t=Filter-Id(11) l=12 val=L2TP-Users AVP: t=Framed-Protocol(7) l=6 val=PPP(1) AVP: t=Service-Type(6) l=6 val=Framed(2) AVP: t=Class(25) l=46 val=3e54049e00000137000102000a0000070000000000000000… AVP: t=Vendor-Specific(26) l=42…
-
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).
-
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…
-
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).
-
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…