This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

XG Site-to-Site IPSec VPN - 802.1X authentication failing

I've recently replaced an ageing Sonicwall with an XG230 running SFOS 18.0.3 MR-3

The XG is at our Head Office and I have 17 remote sites equipped with Draytek 2860/2 routers. The sites are connected with IPSec site-to-site VPNs for which the XG is the responder. All work well and the VPNs are stable.

At each of our sites, we advertise a corporate Wi-Fi network that uses 802.1X for authentication. The RADIUS server is located in our Head Office.

Some of the remote sites use the Draytek built in Wi-Fi, some have Ubiquity APs.

Since implementing the XG, clients fail to connect to the corporate Wi-Fi at all of the remote sites (Head Office is unaffected). I can see, from the RADIUS server logs, that the clients are making contact but at some point during the authentication process, it is failing - I suspect that nothing is getting back to the clients.

The XG logs would, to my inexperienced eye, tend to support this.

It's over two weeks since I logged this problem with Sophos Support and two weeks since I last heard anything from the, which was to say the issue had been escalated to an escalation engineers.

In the meantime, I have had to re-configure our Wi-Fi to use WPA2/PSK authentication. It's not great that I have had to downgrade security due to an apparent problem with a security appliance!

Has anybody else got this problem, or even better, have a workaround? Or do you have a similar set-up that is working?

Thanks



This thread was automatically locked due to age.
Parents
  • You should start to perform tcpdumps on this matter to see, what is actually going on.

    The tcpdump command on XG does not filter all IPSec packets. 

    If you can move to route based VPN, this would be better. Is this possible? 

  • This the tcpdump output (192.168.15.1 is the Draytek router and Wi-Fi access point, 192.168.0.227 is the Radius server)

    09:46:21.103227 ipsec0, IN: IP 192.168.15.1.39323 > 192.168.0.227.1812: RADIUS, Access-Request (1), id: 0x80 length: 139
    09:46:21.103257 Port1, OUT: IP 192.168.15.1.39323 > 192.168.0.227.1812: RADIUS, Access-Request (1), id: 0x80 length: 139
    09:46:21.106990 Port1, IN: IP 192.168.0.227.1812 > 192.168.15.1.39323: RADIUS, Access-Challenge (11), id: 0x80 length: 118
    09:46:21.137471 ipsec0, IN: IP 192.168.15.1.39323 > 192.168.0.227.1812: RADIUS, Access-Request (1), id: 0x80 length: 166
    09:46:21.137478 Port1, OUT: IP 192.168.15.1.39323 > 192.168.0.227.1812: RADIUS, Access-Request (1), id: 0x80 length: 166
    09:46:21.138783 Port1, IN: IP 192.168.0.227.1812 > 192.168.15.1.39323: RADIUS, Access-Challenge (11), id: 0x80 length: 90
    09:46:21.162764 ipsec0, IN: IP 192.168.15.1.39323 > 192.168.0.227.1812: RADIUS, Access-Request (1), id: 0x80 length: 331
    09:46:21.162790 Port1, OUT: IP 192.168.15.1.39323 > 192.168.0.227.1812: RADIUS, Access-Request (1), id: 0x80 length: 331
    09:46:21.177215 Port1, IN: IP 192.168.0.227.1812 > 192.168.15.1.39323: RADIUS, Access-Challenge (11), id: 0x80 length: 1472

    So, as confirmed by the Radius logs, the resets are arriving and the challenge responses are getting back to the XG on Port1 (LAN) but are then not getting to ipsec0...right?

  • Tcpdump does not cover out packets on IPsec on CLI. 

    You can verify this via Webadmin - Diagnostic - Packet capture. This tool does in fact cover both ways of IPsec. But i would say, this challenge will be forwarded to IPsec. So it seems valid from XG perspective. But feel free to check the port 1812 on packet capture GUI. 

Reply
  • Tcpdump does not cover out packets on IPsec on CLI. 

    You can verify this via Webadmin - Diagnostic - Packet capture. This tool does in fact cover both ways of IPsec. But i would say, this challenge will be forwarded to IPsec. So it seems valid from XG perspective. But feel free to check the port 1812 on packet capture GUI. 

Children
No Data