Table formatting

Author: PatAltimore

articles/iot-edge/troubleshoot-iot-edge-for-linux-on-windows-networking.md

@@ -103,9 +103,9 @@ The IoT Edge for Linux on Windows is still dependent on the underlying Windows h
 
 |Protocol|Port|Incoming|Outgoing|Guidance|
 |--|--|--|--|--|
-|MQTT|8883|BLOCKED (Default)|BLOCKED (Default)|<ul> <li>Configure *Outgoing (Outbound)* to be *Open* when using MQTT as the communication protocol.<li>1883 for MQTT isn't supported by IoT Edge. <li>Incoming (Inbound) connections should be blocked.</ul>|
-|AMQP|5671|BLOCKED (Default)|OPEN (Default)|<ul> <li>Default communication protocol for IoT Edge. <li> Must be configured to be *Open* if Azure IoT Edge isn't configured for other supported protocols or AMQP is the desired communication protocol.<li>5672 for AMQP isn't supported by IoT Edge.<li>Block this port when Azure IoT Edge uses a different IoT Hub supported protocol.<li>Incoming (Inbound) connections should be blocked.</ul></ul>|
-|HTTPS|443|BLOCKED (Default)|OPEN (Default)|<ul> <li>Configure *Outgoing (Outbound)* to be *Open* on port 443 for IoT Edge provisioning. This configuration is required when using manual scripts or Azure IoT Device Provisioning Service (DPS). <li><a id="anchortext">*Incoming (Inbound)* connection</a> should be *Open* only for specific scenarios: <ul> <li>  If you have a transparent gateway with leaf devices that may send method requests. In this case, port 443 doesn't need to be open to external networks to connect to IoT Hub or provide IoT Hub services through Azure IoT Edge. Thus the incoming rule could be restricted to only open *Incoming (Inbound)* from the internal network. <li> For *client to device (C2D)* scenarios.</ul><li>80 for HTTP isn't supported by IoT Edge.<li>If non-HTTP protocols (for example, AMQP or MQTT) can't be configured in the enterprise; the messages can be sent over WebSockets. Port 443 will be used for WebSocket communication in that case.</ul>|
+|MQTT|8883|BLOCKED (Default)|BLOCKED (Default)| Configure *Outgoing (Outbound)* to be *Open* when using MQTT as the communication protocol. <br><br> 1883 for MQTT isn't supported by IoT Edge. - Incoming (Inbound) connections should be blocked.|
+|AMQP|5671|BLOCKED (Default)|OPEN (Default)| Default communication protocol for IoT Edge. <br><br> Must be configured to be *Open* if Azure IoT Edge isn't configured for other supported protocols or AMQP is the desired communication protocol. <br><br>5672 for AMQP isn't supported by IoT Edge.<br><br>Block this port when Azure IoT Edge uses a different IoT Hub supported protocol.<br><br>Incoming (Inbound) connections should be blocked.|
+|HTTPS|443|BLOCKED (Default)|OPEN (Default)|Configure *Outgoing (Outbound)* to be *Open* on port 443 for IoT Edge provisioning. This configuration is required when using manual scripts or Azure IoT Device Provisioning Service (DPS). <br><br><a id="anchortext">*Incoming (Inbound)* connection</a> should be *Open* only for two specific scenarios: <br>1. If you have a transparent gateway with leaf devices that may send method requests. In this case, port 443 doesn't need to be open to external networks to connect to IoT Hub or provide IoT Hub services through Azure IoT Edge. Thus the incoming rule could be restricted to only open *Incoming (Inbound)* from the internal network.<br>2. For *client to device (C2D)* scenarios.<br><br>80 for HTTP isn't supported by IoT Edge.<br><br>If non-HTTP protocols (for example, AMQP or MQTT) can't be configured in the enterprise; the messages can be sent over WebSockets. Port 443 will be used for WebSocket communication in that case.|
 
 >[!NOTE]
 > If you are using an external virtual switch, make sure to add the appropriate firewall rules for the module port mappings you're using inside the EFLOW virtual machine.