Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
gratziano
New Contributor

only some remote addresses are reachable on remote subnet

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

2 Solutions
Toshi_Esumi
SuperUser
SuperUser

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.

View solution in original post

emnoc
Esteemed Contributor III

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  

View solution in original post

PCNSE NSE StrongSwan
3 REPLIES 3
Toshi_Esumi
SuperUser
SuperUser

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.

emnoc
Esteemed Contributor III

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  

PCNSE NSE StrongSwan
gratziano

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

 

Labels
Top Kudoed Authors