dmauser / opnazure

Please have a look at this: https://forum.opnsense.org/index.php?topic=27418.0

tl;dr: I migrated to OPNSense a while back from pfSense. The 168.63.129.16 and 168.63.129.16/32 rules on pfSense are assigned to the WAN interface, whereas OPNSense somehow assigns 168.63.129.16 to LAN. This cripples communication with Azure agent.
Removing the latter rule manually restores the communication back.

I have no idea what could be at fault here, so I am reporting it back here as well. Any ideas why could that be?

Hi @wrobelda,

Sorry for the delay here.

When I wrote the script I had to remove a wrong route that was been added from DHCP from Azure on every boot.
You can check it here: https://github.com/dmauser/opnazure/blob/master/scripts/configureopnsense.sh#L73

This Azure IP 168.63.129.16 is used for many different things like LB Probe, waagent and so on...
I had to create a firewall rule to allow the traffic for the internal LB (in case you are deploying the HA version) you can see it here: https://github.com/dmauser/opnazure/blob/master/scripts/config.xml#L351

I also had to create a gateway for the Lan interface for fix routing issues:
https://github.com/dmauser/opnazure/blob/master/scripts/config.xml#L652

Please let me know if that helps.

Just wanted to share my experience.
I (reused) parts of the script to get the waagent working on our OPNSense boxes. Afterwards, we saw configd having a socket creation issue, resulting in "configd socket missing (@/var/run/configd.socket" messages and many subsequent issues. Traced this back to the link created in

opnazure/scripts/configureopnsense.sh

Line 66 in c47686a

ln -s /usr/local/bin/python3.8 /usr/local/bin/python

Removing the link and instead using the sed commands in the following two lines fixed our issue:

opnazure/scripts/configureopnsense.sh

Lines 67 to 68 in c47686a

    
           #sed -i "" 's/command_interpreter="python"/command_interpreter="python3"/' /etc/rc.d/waagent 
        
           #sed -i "" 's/#!\/usr\/bin\/env python/#!\/usr\/bin\/env python3/' /usr/local/sbin/waagent

BTW, we aren't experiencing the routing issue in the VM image published by decisosalesbv, but waagent didn't run. It does now, thanks for this work!

@svenschiller, that's a great feedback. Thank you very much for taking the time.
I'll consider this change in the next round of updates we are planning to do.

@svenschiller, I reviewed this item and if we don't create the symbolic link for python3.8 as python there are many things that would break in waagent including extensions like custom script extension.
I took the time and updated the entire project in the past few weeks including FreeBSD 13 and OPNSense 22.1.
I tested waagent and custom script extension after have it up and running and everything worked fine.
I'll close this issue for now.

	#sed -i "" 's/command_interpreter="python"/command_interpreter="python3"/' /etc/rc.d/waagent
	#sed -i "" 's/#!\/usr\/bin\/env python/#!\/usr\/bin\/env python3/' /usr/local/sbin/waagent

Communication with agent broken due to routing rules assignment