OPNsense firewall in Azure - traffic not able to pass site2site IPsec connection

[mkonecny]

I'm currently testing an Azure environment with an OPNsense firewall for external communication. The OPNsense was deployed by https://github.com/dmauser/opnazure/ with two network interfaces. The initial configuration with Let's Encrypt WebGUI cerificate was successfull and the appliance is accessible by external interface and WebGUI. After creating a site2site IPsec tunnel between the OPNsense and another external firewall the tunnel is successfully comming up, but it's not possible to access internal ressources behind the OPnsense. We are running a lot of site2site IPsec connections on virtual OPNsense appliances (Hyper-V, ESX) without any problems and a similar Azure environment with Sophos XG is working properly. Any ideas about the reason for this issue?

Thanks and regards,Mike

[schnipp]

According to the deployment diagram your NSG is only configured for incoming traffic on TCP ports 22 and 443. For IPsec connections you need UDP port 500 for ISAKMP and ESP for the tunnel (respectively UDP port 4500 when using NAT-T for the tunnel)

[mkonecny]

I´ve configured on the WAN interface the standard three rules - 500 (ISAKMP) 4500 (NAT-T), ESP and the tunnel is comming up properly. The behaviour is quite strange - the traffic can pass the tunnel in direction from OPNsense to the external firewall (Sophos UTM). From Sophos UTM towards OPNsense the traffic is not able not pass the tunnel. I can neither access the WebGUI nor ressources behind the OPNsense.

[schnipp]

Configuring the WAN interface and port forwarding is not enough. As I had already mentioned, please check the configuration of the network security group.

BTW what is the intended use of such a setup like depicted in the drawing? I do not recommend applying the same NSG to the untrusted and trusted subnet. Furthermore, it is not good idea that SSH and WebGUI are directly accessible over the internet (especially with such a creepy password).  :'(

[mkonecny]

I have found the reason for this problem, I had transposed digits in the firewall rule for incoming IPsec traffic. The rest was ok - now the traffic is passing the tunnel in both direction