IPSec Tunnel and Azure VNet Peering - Routing issue?

[tsven]

Hello together,

I am currently running into a problem after setting up an IPSecv2 Tunnel with an OPNsense-VM in Azure and our Virtual Networks. I guess it must be a routing issue, but I am not quite sure about it.


The setup:
We currently have a cluster deployed on azure in VNet1 (10.0.0.0/16). We need to connect it to some on-premise network via a vpn tunnel. For this we set up another VNet2 (10.179.0.0/16) that should act as our "Hub" network which will collect all external connections. The VNets are peered such that communication between both vnets is possible.
We also have to NAT the 10.xxx space due to collisions on the other side.

Code: [Select]

       (Peered)          (Tunnel)
VNet1 <--------> VNet2 <----------> On-Premise Network
10.0.0.0/16      10.179.0.0/16                10.3.0.96/28

The OPNsense router is a VM that is located in VNet2 (10.179.255.4).
VNet1 also has an AzureRouting table that maps 10.3.0.96/28 -> RouterIP.

Now what I have accomplished so far is, by following the docs, that the tunnel is up and running. We can communicate between the router and the on-premise network without any problems.
The traffic between the two VNets also works.
Additionally, I can also get traffic from a test-VM in Vnet2 trough the tunnel to the other network and back without any problems.

Now comes the problem:
Since I have to reach the cluster located in VNet1 I need to somehow route the traffic from the routing device in VNet2 to VNet1. I already managed to get the routing "Cluster --> TunnelInterface" working, the packet capture shows that there are packages arriving from the 10.xxx adress space and that there is actually a response from the other side that leaves the OPN LAN interface.

Interface   Capture output
enc0
enc0   08:12:18.557282 (authentic,confidential): SPI 0xa3bfeac9: IP 10.0.0.5 > 10.3.0.97: ICMP echo request, id 1, seq 26, length 40
enc0
enc0   08:12:18.563175 (authentic,confidential): SPI 0xc061e018: IP 10.3.0.97 > 172.26.130.5: ICMP echo reply, id 1, seq 26, length 40
LAN
hn0   08:12:18.557252 IP 10.0.0.5 > 10.3.0.97: ICMP echo request, id 1, seq 26, length 40
LAN
hn0   08:12:18.563311 IP 10.3.0.97 > 10.0.0.5: ICMP echo reply, id 1, seq 26, length 40

As far as I can tell, the package is reaching the router, propagating correctly back-and-forth but is stuck on the network-interface of the OPN-device on the way back.

It must be a routing problem but I don't know how to properly configure the UDRs in Azure because I have tried lots of routes but none seem to work. I tried to use azure routing tables on the routers-subnet but all configurations seem to have no effect.

As a sidenote, we also have an azure VPN GW located in the VNet2 for some other connections. My guess is that this is used by the vnet peering as the routing service and the routing tables between the OPN-device and the Azure VPN GW are not exchanged properly, but I really have no clue where it's going wrong.

I am quite new into the whole topic of networking in general and opnsense. If any infos are missing/additionally required just let me know.

I guess that this is more of an issue with Azure instead of OPN but maybe somebody already run into this problem and can help me out here.
Have a nice day!

[tsven]

I fixed it myself. In case someone runs into the same issue, here was the cause in my case:

It seems like IP-forwarding was disabled on the Azure VM Interface, the NIC of the OPNsense appliance. Turning it on resolved my issue with the non-communicating peered VNet. However I am still not sure why this worked for machines in the same VNet as the NIC.