Currently I am trying to make a VPN Site to Site between a Fortigate 90D and a TP-LINK TL-R600VPN however I am facing an issue in which the Fortigate CLI can make a ping to the private TP-LINK gateway (192.168.4.1), and one of the machines in the other subnet can make a ping to the fortigate gateway (192.168.3.1) however the PCs cant see each other (192.168.4.100 canÂ´t see 192.168.3.23 and the contrary is also true).
The route is set in Fortigate so that the connections to 192.168.4.0/24 go through the VPN, the question is, what is missing in the configuration so that the two PCs can ping each other? thanks in advance
I would start by using the diag debug flow install a few filters and make sure you are getting matches on the traffic that should cross the vpn.
The diag sniffer packet could be of help if it' s a routed-based vpn .
But sounds like it' s a firewall policy. Do you have matchs for the SA and in both direction when you do testing ?
The execute diag vpn tunnel list name " you phase1 interface name " while your sending traffic.
monitor the rx/tx bytes counters. Are they increasing ? Is the traffic getting to you and being dropped or squashed by a firewall policy ?
I have the following routing policy
Castellana (The VPN I created)
BTW, using diag debug flow I notice that rxp and txp packets are increasing, so I don' t think it has to do with the VPN, rather than the routing or the firewall policies (that are configured to allow anything between internal and VPN both ways)
Maybe you can get something from this cli log I made, this log is the result of a Ping between 192.168.3.23 and 192.168.4.100, the ping didn' t respond but here is the log
CXRFTG # diag debug enable
CXRFTG # diag debug flow filter daddr 192.168.4.100
CXRFTG # diag debug flow show console enable
show trace messages on console
CXRFTG # diag debug flow trace start 1000
CXRFTG # id=13 trace_id=1001 msg=" vd-root received a packet(proto=1, 192.168.3.23:1->192.168.4.100:8) from internal."
id=13 trace_id=1001 msg=" allocate a new session-00b43f7f"
id=13 trace_id=1001 msg=" Match policy routing: to 192.168.4.1 via ifindex-30"
id=13 trace_id=1001 msg=" find a route: gw-192.168.4.1 via Castellana"
id=13 trace_id=1001 msg=" use addr/intf hash, len=4"
id=13 trace_id=1001 msg=" find SNAT: IP-192.168.3.1, port-62464"
id=13 trace_id=1001 msg=" Allowed by Policy-9: SNAT"
id=13 trace_id=1001 msg=" SNAT 192.168.3.23->192.168.3.1:62464"
id=13 trace_id=1001 msg=" enter IPsec interface-Castellana"
id=13 trace_id=1001 msg=" send to IP-B via intf-wan1"
id=13 trace_id=1001 msg=" encrypting, and send to IP-B with source IP-A"
id=13 trace_id=1002 msg=" vd-root received a packet(proto=1, 192.168.3.23:1->192.168.4.100:8) from internal."
id=13 trace_id=1002 msg=" Find an existing session, id-00b43f7f, original direction"
id=13 trace_id=1002 msg=" SNAT 192.168.3.23->192.168.3.1:62464"
id=13 trace_id=1002 msg=" enter IPsec interface-Castellana"
id=13 trace_id=1002 msg=" send to IP-B via intf-wan1"
id=13 trace_id=1002 msg=" encrypting, and send to IP-B with source IP-A"
If I read your post correctly you have created a Policy Route, not a regular static route - is that correct?
You would only need a Policy Route if the decision which route to take was NOT the destination address. In your case, a regular static route will do and should be used.
Besides, the log shows that the traffic enters the tunnel but reply traffic is never seen. I suspect that there is no route on the other end for 192.168.3.0/24 pointing to the VPN.
BTW, I' d obfuscate the public addresses in the log. You can still edit your post at this time.
Thanks for the answer, as you correctly stated, I had a policy route through the VPN (left only the static route I stated above), I removed it and the VPN from the TP-LINK side works for all of the 192.168.3.0/24 of the Fortigate side, however, the VPN from Fortigate to TP-LINK doesnt work, even though I can make a PING to the 192.168.4.1 TP-LINK gateway
Is that a problem on Fortigate side or on TP-LINK?
Do you have both policies on the FGT, i.e.
- FGT-LAN to TP-LAN and
- TP-LAN to FGT-LAN ?
If yes, then look at the TP side for missing policy, ACL, access rules, whatever...
It is not routing - the FGT receives the reply traffic fine!