- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Hi there,
Specific settings mismatches as side a DAIP gateway VPN scenario will often be slower but 30-minutes seems excessive.
sk167473 explains the reasons in part, only one side can initiate the VPN and there is a need for DPD.
What version/build is the gateway appliance?
show software-version
This is Check Point's 1590 Appliance R81.10.07 - Build 397
For awareness per sk179615...
R81.10.08 is the current recommended release and R81.10.10 is the latest.
Something else to consider if the issue persists after investigating the DAIP / DPD elements perhaps.
this how my routing table looks like, when everything is ok.
netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default ua-113-113-192- 0.0.0.0 UG 0 0 0 WAN
10.0.0.0 192.168.4.10 255.0.0.0 UG 0 0 0 vpnt10
192.168.3.0 * 255.255.255.0 U 0 0 0 LAN1
192.168.4.10 * 255.255.255.255 UH 0 0 0 vpnt10
113.113.192.0 * 255.255.224.0 U 0 0 0 WAN
When the gateway reboots the routing table looks like this for about 30 min:
netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default 113.113.192.1 0.0.0.0 UG 0 0 0 WAN
10.0.0.0 192.168.4.10 255.0.0.0 UG 0 0 0 vpnt10
192.168.3.0 * 255.255.255.0 U 0 0 0 LAN1
192.168.4.10 * 255.255.255.255 UH 0 0 0 vpnt10
113.113.192.0 * 255.255.224.0 U 0 0 0 WAN
after about 30 mins it changes and works again
any ideas?
what is the difference between 113.113.192.1 and ua-113-113-192- ?
Try netstat -rn when everything's ok.
I'm guessing it'll be the same in both cases.
That suggests DNS is related to this issue.
You should check if DNS is working when the issue is occurring.
So, when using netstat -rn the result is the same as netstat -r when things are not working:
netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default 113.113.192.1 0.0.0.0 UG 0 0 0 WAN
10.0.0.0 192.168.4.10 255.0.0.0 UG 0 0 0 vpnt10
192.168.3.0 * 255.255.255.0 U 0 0 0 LAN1
192.168.4.10 * 255.255.255.255 UH 0 0 0 vpnt10
113.113.192.0 * 255.255.224.0 U 0 0 0 WAN
What DNS talking we about here? Is it my ISP DNS?
I could not resolve "ua-113-113-192-":
nslookup ua-113-113-192- 8.8.8.8
Server: dns.google
Address: 8.8.8.8
*** dns.google can't find ua-113-113-192-: Non-existent domain
on SMB, DNS is configured like this:
show dns
mode: global
proxy: on
resolving: on
primary ipv4-address: 10.8.0.12
secondary ipv4-address: 8.8.8.8
tertiary ipv4-address:
Where 10.8.0.12 is the our internal DNS server behind the central gateway
So,When the issue occurs, no pings can reach any destination:
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss
Gateway-ID-7FB7C2DC> ping google.com
ping: bad address 'google.com'
Looks like after reboot internet is not working. Is this correct understanding?
Then we do not need to troubleshoot VPN issues but ISP issues maybe?
DNS is internal IP i see so that would go via tunnel that is down? That leaves you with 8.8.8.8 that also is not working.
Can you confirm if internet is working after reboot?
After reboot nothing works!
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
Internet is not working directly after reboot, but it works after about 25-30 minutes when everything else start to work
so netstat -r looks like this directly after reboot:
netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default 113.113.192.1 0.0.0.0 UG 0 0 0 WAN
10.0.0.0 192.168.4.10 255.0.0.0 UG 0 0 0 vpnt10
192.168.3.0 * 255.255.255.0 U 0 0 0 LAN1
192.168.4.10 * 255.255.255.255 UH 0 0 0 vpnt10
113.113.192.0 * 255.255.224.0 U 0 0 0 WAN
netstat -r looks like this after 25-30 minutes when everything start to work:
netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default ua-113-113-192- 0.0.0.0 UG 0 0 0 WAN
10.0.0.0 192.168.4.10 255.0.0.0 UG 0 0 0 vpnt10
192.168.3.0 * 255.255.255.0 U 0 0 0 LAN1
192.168.4.10 * 255.255.255.255 UH 0 0 0 vpnt10
113.113.192.0 * 255.255.224.0 U 0 0 0 WAN
Hello,
I have seen this behavior before.
Do not use a DNS behind a VPN you have to create yourself. It does not work (chicken / egg) consistently. and especially if you need DNS to create the Tunnel it gets weird.
On the GW just use internet DNS servers (from your ISP, Google,...) behind the GW you can publish the internal DNS via DHCP.
Best Regards
Peter
Good tip, indeed these DNS servers should have specific routes for them outside the VPN.
I did as you said, the time it takes to move from 113.113.192.1 to ua-113-113-192- is now about 20 minutes!
Is that normal? Or should I do something more?
show dns
mode: global
proxy: on
resolving: on
primary ipv4-address: 8.8.8.8
secondary ipv4-address: 8.8.8.8
tertiary ipv4-address:
What about (mode) global or internet, does that have any thing to do with this problem?
The fact you cannot ping 8.8.8.8 or any other IP's after reboot tells me there is an internet access issue. The DNS and VPN not working is just an outcome of not working internet.
You should focus on this to be honest. Is it cluster? Maybe make packet capture on WAN interface to see what is going on.
If internet not working try to atleast ping DG to see if that is working:
113.113.192.1
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
12 | |
4 | |
3 | |
3 | |
3 | |
3 | |
2 | |
2 | |
2 | |
1 |
Thu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasMon 22 Sep 2025 @ 03:00 PM (CEST)
Defending Hyperconnected AI-Driven Networks with Hybrid Mesh Security EMEAMon 22 Sep 2025 @ 02:00 PM (EDT)
Defending Hyperconnected AI-Driven Networks with Hybrid Mesh Security AMERThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasMon 22 Sep 2025 @ 03:00 PM (CEST)
Defending Hyperconnected AI-Driven Networks with Hybrid Mesh Security EMEAAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY