Total: 1234 words, 38 images,Estimated reading time: 2 minutes
Previously, OpenWrt was deployed on VMware Workstation (Deploying the latest version of OpenWrt 23.05.3 on VMware Workstation). If you want to deploy OpenWrt directly on ESXi, you will find that the conversion of the image cannot directly generate OVF or OVA files, and ESXi also has recognition problems when directly using the converted disk. Therefore, currently, you can only first deploy the disk image to Workstation, then export it as an OVF file, and finally migrate it to ESXi.
While OpenWrt is running, first check the host status information.
The disk space utilization and memory utilization are surprisingly low, with the disk using a total of 29 MB, memory using 55 MB, and CPU load being 0. Although it is much higher than the previous old version, the overall load is still very low.
First, change the network connection to “Bridged Mode”.
Then click on the “File” menu and select “Export as OVF”, where the generated OVF file and VMDK file are the two main files for importing into ESXi.
In ESXi, create a new virtual machine, select the type “Deploy a virtual machine from an OVF or OVA file”.
Select the exported OVF file and VMDK file, then give the virtual machine a name.
Select storage.
Then steps 4 and 6 disappear, leaving only step 5 “Deployment Options”. Choose “Thin Provision” for disk provisioning, modify the network mapping, and uncheck “Power on automatically”.
Confirm the host configuration and click “Finish”.
Before booting, adjust the hardware configuration slightly higher.
After adjustment, boot up successfully.
According to the previous method, change the host network card address to 192.168.1.225, test access through the browser, and it can be accessed normally.
How can a normal router have only one network card? Add another one, and change the adapter type to VMXNET (In VMware ESXi, the performance of different virtual network cards can vary up to three times!).
Check the network card information, where eth0 and br-lan are bound, corresponding to the host’s network adapter 1, connected to the VM Network, which should normally be the WAN port but is currently used as the LAN port and needs adjustment.
First, change the interface bound to the br-lan bridge interface to eth1.
Then change the IP address of the br-lan interface to 172.16.113.1, subnet mask 24 bits; now it is the gateway itself and does not need to configure a gateway.
Then click “Add new interface” to create a WAN interface, select protocol “Static address”, and choose interface “eth0”.
Configure the address as 192.168.1.225, subnet mask as 24 bits, and gateway as 192.168.1.1.
After adjustment, it will prompt that the configuration has not been saved and take effect, you need to click “Save & Apply” to make the changes take effect.
Then find a host and connect to the port group corresponding to the eth1 network card “LINK01”. You can see that the new network card has successfully obtained an address.
Then use the gateway of the LAN port on this host to log in to the router and test network connectivity.
Next, set the DNS information for the interface.
Then add the WAN interface to the security zone named WAN.
Save and apply to make the configuration take effect. Then the host can go online.
At this point, the network card adjustment is complete.
Use iperf3 to run a stream, test the bandwidth, and see if the traffic topology can be used.
Preliminary tests show that the difference in forwarding between going through OpenWrt and not going through OpenWrt is not significant. The average traffic through OpenWrt is 3.08 Gbps, which is similar to the data monitored by OpenWrt. The instantaneous flow is very large, but the device load is not high at all, even less than 10%.
Check the interface traffic statistics, LAN port received 18.73 GB, WAN port forwarded 18.90 GB, which is basically accurate.
This is a router.
This firewall function is still very attractive to me. Check the firewall rules.
Allow all traffic from LAN to WAN. If this rule is deleted, the traffic should be cut off.
At the same time, the traffic from the terminal to OpenWrt is also not available.
First, confirm the security zone settings, as the configuration rules will call here.
Then create a rule to allow ICMP packets.
After applying, it was found that it did not take effect. It only took effect after restarting the firewall on the firewall status page. I don’t know if this is normal.
After the restart, it worked, but why did the delay become 1ms, and TTL became 64?
Address resolution is normal, but the delay and TTL are incorrect. Confused? The configuration above is DNAT, and it should normally be configured on the page below for SNAT.
Then drove away the “ghost”.
Another configuration is to allow ICMP traffic, configured in Traffic Rules.
Now only ICMP is allowed, then allow the traffic for iperf stream. Create a rule that matches TCP port 5201.
Actually, it can be done here.
So the question is, under the normal status of the server, in addition to the normal status, there are also two types of abnormal connection statuses: one is timeout, and the other is rejection. Do you know the reason?
Long press the QR code to follow us
Leave a Comment
Your email address will not be published. Required fields are marked *