The NAT process appears to have a bug

Hi folks,

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

  • src_ip="10.10.10.13"
  • src_country="R1"
  • dst_ip="17.253.116.253"
  • dst_country="TWN"
  • protocol="UDP"
  • src_port="123"
  • dst_port="123"
  • packets_sent="1"
  • packets_received="0"
  • bytes_sent="76"
  • bytes_received="0"
  • src_trans_ip="10.10.10.1"
  • src_trans_port="0"
  • dst_trans_ip="10.10.10.5"
  • dst_trans_port="0"
  • src_zone_type="LAN"
  • src_zone="LAN"
  • dst_zone_type="LAN"
  • dst_zone="LAN"
  • con_direction=""
  • con_event="Stop"
  • con_id="49707584"
  • virt_con_id=""
  • hb_status="No Heartbeat"
  • message=""
  • appresolvedby="Signature"
  • app_is_cloud="0"
  • src_ip="10.10.10.13"
  • src_country="R1"
  • dst_ip="17.253.66.125"
  • dst_country="AUS"
  • protocol="UDP"
  • src_port="123"
  • dst_port="123"
  • packets_sent="1"
  • packets_received="1"
  • bytes_sent="76"
  • bytes_received="76"
  • src_trans_ip="10.10.10.1"
  • src_trans_port="48"
  • dst_trans_ip="10.10.10.5"
  • dst_trans_port="0"
  • src_zone_type="LAN"
  • src_zone="LAN"
  • dst_zone_type="LAN"
  • dst_zone="LAN"
  • con_direction=""
  • con_event="Stop"
  • con_id="978939648"
  • virt_con_id=""
  • hb_status="No Heartbeat"
  • message=""
  • appresolvedby="Signature"
  • app_is_cloud="0"
  • Which to me seems odd?

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?

Ian



changed the heading
[edited by: rfcat_vk at 12:14 AM (GMT -7) on 21 Apr 2021]
Parents
  • 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?

    Ian

     
    V18.0.x - e3-1225v5 6gb ram with 4 ports - 20w. 
    3 AP55s and 2 APX120s having a holiday until software update is released.
    If a post solves your question use the 'This helped me' link.
Reply
  • 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?

    Ian

     
    V18.0.x - e3-1225v5 6gb ram with 4 ports - 20w. 
    3 AP55s and 2 APX120s having a holiday until software update is released.
    If a post solves your question use the 'This helped me' link.
Children
  • 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.

    Ian

     
    V18.0.x - e3-1225v5 6gb ram with 4 ports - 20w. 
    3 AP55s and 2 APX120s having a holiday until software update is released.
    If a post solves your question use the 'This helped me' link.
  • 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

  • Hi Ryan,

    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.

    ian

     
    V18.0.x - e3-1225v5 6gb ram with 4 ports - 20w. 
    3 AP55s and 2 APX120s having a holiday until software update is released.
    If a post solves your question use the 'This helped me' link.
  • 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?

    Ian

     
    V18.0.x - e3-1225v5 6gb ram with 4 ports - 20w. 
    3 AP55s and 2 APX120s having a holiday until software update is released.
    If a post solves your question use the 'This helped me' link.
  • I have disabled all checks on the firewall rule. 

    Ian

     
    V18.0.x - e3-1225v5 6gb ram with 4 ports - 20w. 
    3 AP55s and 2 APX120s having a holiday until software update is released.
    If a post solves your question use the 'This helped me' link.