recently with the aid of Prism I was able to resolve the creation of a hairpin NAT.
I was investigating the logviewer entries for some of the devices and found what I think are a couple issues?
1/. some entries have a src_tran_port with a value and others have 0.
please see the coloured lines in the text below
2/. the firewall/Nat rule seems to break and cause packet corruption causing many devices to retry NTP lookup many times and other devices to send requests and receive 0 bytes returned. I reset the rules by changing the destination to an internal network, save it, then restore the original any, save it and the firewall/NAT rule works again for about 12 hours,
What is the cause and then how do I permanently fix the issue?
This is becoming very annoying having to make the change every 12 hours because XG decides that the source port needs to be translated which then is rejected by the NTP server.
Why does the XG suddenly decide that ports need translating?
The NAT process definitely has a bug.
I deleted and recreated the firewall rule which worked for a short time and then started using double NAT translations all of its own accord. Also appears to screw uptake packet data because the NTP does not respond when the NAT changes itself.
I've seen NAT issues and a reboot usually solves them. Do you think that would have worked for you or was a rule recreation necessary? Not that one is better than the other.
Also, what firmware version?
worlds number one free ICMP monitoring platform: https://pinescore.com
v18.0.5. Due to a mis configure I had to rebuild the XG. After the configuration restore, the Nat issue was still there. I have made some more changes and will wait for awhile.
after having rebuilt the XG I realised I could of accessed it through cm and fixed the broken configuration.
A fresh installation did not fix the issue. Some process in XG decides that the hairpin needs some auto change which breaks the hairpin traffic flow path.
I wil use the DPI and see if that has any affect?
I have disabled all checks on the firewall rule.