Internet connection drop after several hours on a 1:1 mapped email server
Steven430
Newbie ✭
I have an Exchange email server. 1:1 mapped a public IP. After several hours of time, I found that the server is able to ping the LAN IP of sonicwall but can't ping any Internet IP.
What I did to resume the connection? Just simply swap the sequence of the 1:1 NAT rule between "incoming nat" and "outgoing nat" (e.g. rule1: incoming nat; rule2: outgoing nat). Then, after several hours, the problem take place again, and i just simply swap the rules again (e.g. rule1: outgoing nat; rule2: incoming nat). I keep to repeat the above steps for a week.
And I've already upgrade the firmware to the latest one and stopped all the UTM feature already. Anyone have idea on this issue?
Best Answers
-
CORRECT ANSWER
Saravanan
Moderator
Hi @STEVEN430,
Thanks for the packet capture.
Looks like the issue is at the upstream of the SonicWall WAN side. As per the packet capture, I can see only the ICMP requests forwarded to the upstream of the SonicWall and no ICMP replies.
Packet before NATTING:
Src MAC = 00:0c:29:30:66:54, Dst MAC = 2c:b8:ed:5a:0c:9c; Src IP = 10.8.1.4, Dst IP = 8.8.8.8 || 00:0c:29:30:66:54 - MAC address of the host 10.8.1.4, 2c:b8:ed:5a:0c:9c - MAC address of the SonicWall LAN interface.
Packet after NATTING:
Src MAC = 2c:b8:ed:5a:0c:9d, Dst MAC = 00:25:9e:fb:8b:6d; Src IP = 210.3.49.218, Dst IP = 8.8.8.8 || 2c:b8:ed:5a:0c:9d - MAC address of the SonicWall WAN interface, 00:25:9e:fb:8b:6d - MAC address of the upstream modem.
Both these ICMP packets are forwarded by the SonicWall. So, SonicWall handles the packets fine. You may need to trace the packets on the upstream modem/router side.
Tweaking the NAT policy removes the problem temporarily - yes and this is because as explained on my previous comment, after tweaking, the ARP process takes place and hence the communication resumes. So, I presume the upstream modem loses ARP cache after specific time.
Please monitor how frequently the issue happens and make a note of the time value. Check for the ARP timeout on the upstream modem during the issue time without tweaking the NAT policy on the SonicWall. This could isolate and resolve the issue permanently.
Regards
Saravanan V
Technical Support Advisor - Premier Services
Professional Services
0 -
CORRECT ANSWER
Ajishlal
Community Legend ✭✭✭✭✭
Hi @Steven430
Additionally create a route policy for the exchange server and try.
For example follow the below screen shot.
NB: If you are using Exchange Network Load Balance IP for NAT (Virtual Interface), You have to tweak the NAT policy.
1
Answers
Hi @STEVEN430,
Thank you for visiting SonicWall Community.
As per your description, it looks like the issue is specific to a 1 to 1 NAT usable public IP? Are you noticing this issue with any other usable WAN IP? It sounds like this is a ARP issue as per the symptom reported. When you tweak the NAT policy, the ARP process takes place again and hence the communication resumes via that NAT policy. We would need to perform a packet capture based on the destination IP (To an Internet IP address like 4.2.2.2, etc,.,) for PING traffic to identify if firewall sends out the traffic to its WAN side.
Regards
Saravanan V
Technical Support Advisor - Premier Services
Professional Services
Hi Saravanan,
Thanks for your reply. Actually, I captured the packet log during the event took place. But seems here is unable to attach html. So, i converted the content to txt file. The attached log file including the period of disconnecting and resuming.
Email server private ip is: 10.8.1.4, and opened a cmd prompt and keeps to ping 8.8.8.8
Thanks Saravanan, your explaination really make sense. Maybe I need to check with our ISP's device or just reboot it for trial. For my observation, its will fail around 5-6 hrs, seems it has fixed period of time. Many thanks for your help!
Hi Ajishlal,
Thanks for your advise, I've already added the routing policy for my email server as a test. Let me update you after observation period, thanks a lot!
Hi Ajishlal,
After adding the explicit routing entry, the problem still exist......
Hi @Steven430 ,
For testing purpose, disable the NAT policy which you suspected and try to ping any public IP from your server and observe the behavior. If still you have the ping drops, please check your network topology of your Firewall and Switch connections. especially where you have multiple links between switches and check if there any loops created or not. If its possible check your switch logs about any unusual events while ping to the WAN as well as check any IP conflict in your network.