question

MatthewRelouw-6027 avatar image
0 Votes"
MatthewRelouw-6027 asked MatthewRelouw-6027 published

Packets dropped on subnet

We have a Azure hosted Watchguard Firebox, we've added a additional NIC and configured the routes etc. as required but can't successfully connect through the firebox to resources on this optional network.

Watchguard support has confirmed that the firebox is configured accordingly and we can see the packets arrive from the internet get processed by the firebox and sent to the correct network interface but they never arrive at the destination VM, packet capture in azure confirms the packets do not arrive at the intended VM's nic. The diagnostics tools in the firebox are able to ping the destination.

How can I trace the cause of these packets being dropped and resolve the issue.

azure-virtual-network
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

SaiKishor-MSFT avatar image
0 Votes"
SaiKishor-MSFT answered SaiKishor-MSFT edited

@MatthewRelouw-6027 Thank you for reaching out to Microsoft Q&A.

I understand that you are having issues with connectivity to your additional NIC attached to your WatchGuard Firebox where traffic forwarded to that NIC does not seem to be reaching the target VMs as expected.

Azure assigns a default gateway to the first (primary) network interface attached to the virtual machine. Azure does not assign a default gateway to additional (secondary) network interfaces attached to a virtual machine. Therefore, you are unable to communicate with resources outside the subnet that a secondary network interface is in, by default. Secondary network interfaces can, however, communicate with resources outside their subnet, though the steps to enable communication are different for different operating systems. Here are steps to enable the same for Windows VM : Configure guest OS for multiple NICs.
For Linux VM: Configure guest OS for multiple NICs

As mentioned in the document, Once you've added the route for a secondary interface, verify that the route is in your route table with route -n. Once you do the same, please check if the traffic reaches the target VM. If it still does not reach it, please capture the traffic on both the Firebox and the Target VM by using necessary filters to minimize traffic to only the extra NIC/test traffic and attach it here so we can verify the same. Thank you!
Remember:

Please accept an answer if correct. Original posters help the community find answers faster by identifying the correct answer. Here is how.

Want a reminder to come back and check responses? Here is how to subscribe to a notification.


5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

MatthewRelouw-6027 avatar image
0 Votes"
MatthewRelouw-6027 answered MatthewRelouw-6027 published

Thanks for the response, Routes on the firebox look to be correct as far as i can tell
IPv4 Routes


Destination Gateway Genmask Flags Metric Interface
0.0.0.0 172.16.0.1 0.0.0.0 UG 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 lo
168.63.129.16 172.16.0.1 255.255.255.255 UGH 0 eth0
172.16.0.0 0.0.0.0 255.255.255.0 U 0 eth0
172.16.8.0 0.0.0.0 255.255.255.0 U 0 eth1
172.18.2.0 0.0.0.0 255.255.255.240 U 0 eth2

Interface eth 2 is the one not behaving correctly

the routes from the vm attached to the same subnet as eth2 above are
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.18.2.1 172.18.2.4 10
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
168.63.129.16 255.255.255.255 172.18.2.1 172.18.2.4 11
169.254.169.254 255.255.255.255 172.18.2.1 172.18.2.4 11
172.18.2.0 255.255.255.240 On-link 172.18.2.4 266
172.18.2.4 255.255.255.255 On-link 172.18.2.4 266
172.18.2.15 255.255.255.255 On-link 172.18.2.4 266
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 172.18.2.4 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 172.18.2.4 266
===========================================================================
Persistent Routes:
None

Can't upload/attach pcap files so have shared them via the following link https://integralict-my.sharepoint.com/:f:/g/personal/matt_integralict_com_au/Ev2sMXknnoRFnjbm_GlIPfwBCGs5Fb9pCR4iv8AKJ361dw?e=OW6aah

'INTWGAZ rdptest.pcap' shows the connection attempt on the fireboxes eth2 interface.
'optionalvm rdptest.pcap' was captured from the vm with ip 172.18.2.4 and was filtered to port 3389 the only traffic seen is that to/from the bastion connection I was using to get to the server (anything 172.16.254.0/24 is the bastion subnet)

Not sure any of this helps let me know if there's additional info I can provide.

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.