[SOLVED] Cannot reach a secondary remote subnet over Site-to-Site VPN

[Nekrillo]

Hi all! I've had the issue stated on the label for quite some time now and people are starting to get quite annoying (and it's reasonable).

I have a Site-to-Site VPN between two FortiGate 60D, both with the firmware v6.0.5 build0268 (GA).

One of the site has two subnets. One handles our main services (RDP, DNS and LDAP) and the secondary only has a PBX. There's no problem on the connection between the first one and the remote one, but our PBX cannot reach the remote one, which is on the only remote subnet. If I set the ping source on the PBX related subnet I can reach the remote subnet, Likewise on traceroute. On the other hand, the remote subnet cannot reach it. Logs haven't been really useful and I'm awful at understanding wireshark. (I'm awful at mostly everything related to networking, but don't tell my boss that) I can provide more info, as I know this is all quite vague and poorly written due to my non-native-speaker excuse.

Thanks!

[sw2090]

Lets say Side A has the two subnets and Side B has only one but wants to reach the two subnets on side a via vpn.

Then you need on Side B:

static routes to the subnets on Side A with the vpn as interface.

policies to allow the traffic

and on Side A:

static route to Side B Subnet with vpn as interface (reverse Path to be able to route back to Side B)

Policies to allow the traffic

If you have all of these it shoud work.

You might use flow debug on cli to check what happens to your packets:

e.g. on Side B do:

  diag debug ena

  diag debug flow filter clear

  diag debug flow saddr <some client in Side B Subnet>

  diag debug flow daddr <some client in one Side A Subnet>

  diag debug flow trace start <numberofpackets>

then go to the client in Side B Subnet you entered as saddr above and ping the client on Side which you entered as daddr above. Wartch the FGT Cli and you see what Side B FGT does with the packets.

Once you see they enter the Ipsec you could do the same Flow debug on Side A FGT, ping again and watch what SIde A does with the packets.

[Nekrillo]

Thank you for your reply! Went all over this and found out that my local traffic on the second subnet was going straight to implicit deny. Since I was still blind enough not to see why I went ahead and scraped everything and started anew. That's when it hit me. Both subnets are on different interfaces, and my local policies were only set up for one of those. Copied the working ones, changed the interface and boom, all good. Sometimes you just need an external point of view to realize that you've been an idiot the whole time.

Thanks!