hello there,
i hope you can help me with this issue, i have a gateway to gateway VPN site configuration, the tunnel goes up and seems fine, however on the remote subnet some IP addresses are not reachable from my local LAN, these addresses are reachable when i ping them locally (at the remote site).
setup:
FGT80, Firmware 5.6.10 (also tried with 5.6.11) - local subnet 192.168.13.0/24
FGT60, Firmware 6.0.6, remote subnet 172.16.16.0/24
i'm using a routing based VPN
pings works from the remote site to the local site.
Diganostics:
I've tried tcp dump on the local fortigate lan interface to monitor icmp:
FW (root) # diagnose sniffer packet LAN "icmp" interfaces=[LAN] filters=[icmp] 16.620849 192.168.13.103 -> 172.16.16.1: icmp: echo request 21.326596 192.168.13.103 -> 172.16.16.1: icmp: echo request 26.331553 192.168.13.103 -> 172.16.16.1: icmp: echo request 31.331637 192.168.13.103 -> 172.16.16.1: icmp: echo request
trace route from the local host:
Tracing route to 172.16.16.1 over a maximum of 30 hops
1 2 ms 3 ms 1 ms 192.168.13.254 2 * * * Request timed out. 3 * * * Request timed out. 4 * * * Request timed out.
running tcp dump on the remote site LAN interface intercepts no packets.
working address
example of pinging another address:
623.643337 192.168.13.103 -> 172.16.16.101: icmp: echo request 623.669938 172.16.16.101 -> 192.168.13.103: icmp: echo reply 624.649024 192.168.13.103 -> 172.16.16.101: icmp: echo request 624.676225 172.16.16.101 -> 192.168.13.103: icmp: echo reply 625.655834 192.168.13.103 -> 172.16.16.101: icmp: echo request 625.682663 172.16.16.101 -> 192.168.13.103: icmp: echo reply 626.679887 192.168.13.103 -> 172.16.16.101: icmp: echo request 626.707210 172.16.16.101 -> 192.168.13.103: icmp: echo reply
Trace route:
Tracing route to 172.16.16.101 over a maximum of 30 hops
1 2 ms 2 ms 2 ms 192.168.13.254 2 28 ms 27 ms 28 ms 83.[Remote public IP] 3 45 ms 28 ms 28 ms 172.16.16.101
Trace complete.
i'm wondering if the public ip address should appear in the trace above, in a vpn tunnel i would expect to see the remote LAN address, is that correct?
thanks for your help
Yosef
Solved! Go to Solution.
First, you're probably not allowing PING on the lan interface that has 172.16.16.1 on the FGT60D/E.
Then, in the second traceroute, you should see the tunnel interface IP. So if you see the wan interface IP, you probably didn't configure tunnel interface IP (interface name is same as phase1-interface name). So it's working like policy-bace IPsec relying on the policy.
The diag debug flow would be helpful, I would double-check routing on the hosts that are failing and especially if other hosts are working correctly.
Ken Felix
PCNSE
NSE
StrongSwan
First, you're probably not allowing PING on the lan interface that has 172.16.16.1 on the FGT60D/E.
Then, in the second traceroute, you should see the tunnel interface IP. So if you see the wan interface IP, you probably didn't configure tunnel interface IP (interface name is same as phase1-interface name). So it's working like policy-bace IPsec relying on the policy.
The diag debug flow would be helpful, I would double-check routing on the hosts that are failing and especially if other hosts are working correctly.
Ken Felix
PCNSE
NSE
StrongSwan
thanks emnoc, your tip regarding the diag debug flow was very helpful. I haven't used this command before.
somehow i missed checking the SSL addresses which overlap with some of the remote site addresses.
it works like a charm now
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1740 | |
1108 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.