XG125 with 20 MR2 blocks UDP 500/4500 after upgrade from MR1

Hi,

Thank you for reaching out to Sophos Community.

Can you share the case ID? If none, I recommend creating one so that this can be further isolated if the cause is the upgrade, and kindly share the case ID.

Also, are all devices affected? Have you tried on different devices within the same network upon testing?

Thanks,
i tried different laptops.
All users have this problem if they are connected to APX AP´s.
If the use a mobile connection or a LANCOM Router, there is no problem at all.

Only if connected to Sophos Firewall.

I need to open a case.

A wireshark trace on the laptop show´s , that the destination VPN Server (pfsense firewall) is not responding.

Looks like the packages never leave the WiFi (at the Branch Office).

Thank you for the information, 

Please share the case ID here so we can monitor your case.

I was able to solve the problem, there was a misconfiguration in the rules.
I had a set up with an old XG115w with MR2 and was able to check the rules.

I noticed two bugs during setup.

During the setup wizard, you are asked for the timezone.
If I enter Europe/Berlin here,
the APs are assigned a USA configuration and the WLAN adapters end up in the LAN zone.

Could be done better.

After 90 minutes, WifFi fails for a few minutes and Problem is back.

Must be the old WiFi bug or a new bug with MR2

Case ID 01867960

not Solved?

Your APX is managed by central or Firewall (Bridge to AP-LAN or separate Zone .. may be an MTU problem)

If you connect the notebook by wire to the branch firewall ... problem didn't exist?

Possible to do a packet-capture using "host xxx.xxx.xxx.xxx and port 500" as BTF-String? (xxx = Notebook-IP)

Hi Dirk,

i have a XG115w with SFOS 20 MR2 with the same Wifi Setup and Firewall Rules.
The XG115w works fine.

APX is controlled by XG125
APX is Seperate Zone (Wifi)

I capture a Laptop in my home Office and i have a capture filter in wireshark, i can see that the client is talking over 500/4500 with the VPN Server.

But at the XG125 with APX as a WiFi AP, the client doesn´t get any response from the VPN Server. Wireshark show only the traffic from the client laptop, but no response from the APX 320 traffic.

The client have normal internet (most of the time), but the don´t have VPN (500/4500), XG125 drops all traffic to the client.

Sri has done the capture and saw the same problem, but has no idea.

Hi,

Thank you for sharing the case, as per an update, a scheduled call will have been requested from your side.

Why does the  XG125 get´s this log entries in IPSec (charon.log)?
There are a mass of entries.

2024-09-09 10:35:56
VPNmessageid="18050" log_type="Event" log_component="IPSec" log_subtype="System" status="Deny" user=""
con_name="" con_type="0" src_ip="" gw_ip="" local_network="" dst_ip="" remote_network=""
additional_information="" message="Received IKE message with invalid SPI (9FC31E20) from the remote gateway."

Why does the  XG125 get´s this log entries in IPSec (charon.log)?
There are a mass of entries.

2024-09-09 10:35:56
VPNmessageid="18050" log_type="Event" log_component="IPSec" log_subtype="System" status="Deny" user=""
con_name="" con_type="0" src_ip="" gw_ip="" local_network="" dst_ip="" remote_network=""
additional_information="" message="Received IKE message with invalid SPI (9FC31E20) from the remote gateway."

Hi juergenb52 , this log in charon.log indicates a message to the logging syb-system saying that for the incoming IKE (IPsec connection) packet, either there is no config or if the config (of an existing connection) is present the message is invalid.  Such packets will be dropped and notified to the logging sub-system.

The problem has been solved last night.

The XG125 died at 10:14 PM (Case ID 01877872).
I'm curious to see if the replacement will take as long as the XGS2100.

The problem is back.

This time, the XGS2100 with SFOS 20 an GA is going south ...
VPN Traffic is not forwarded to the external Port2.

The diagnostics packet capture, that showed this error on the XG125 (rip) shows the same behavior now at the XGS2100.

The ISP providers had checked the routers at HO and BO and restarted them, but the problem was still there.

Only a reboot of the XGS HA cluster in the head office put an end to the problem with this XG125 in the brach office.