0

I've got a bit of a problem. I have 2 Sites. HQ and Branch both are connected via a site-to-site VPN (IPsec).

HQ.: 192.168.10.x/24 Branch.: 192.168.25.x/24

If I am in the HQ building and in the 192.168.10.x/24 network, I can access the 192.168.25.x/24 network without a problem.

If I am at home and connect via FortiGate VPN IPsec client to the HQ, I can access the 192.168.10.x/24 network, but I cannot reach the 192.168.25.x/24 network.

What I've tried so far.:

  1. Firewall policy to allow traffic from clientvpn network (10.10.10.x/24) to the 192.168.25.x/24 network, and reverse.
  2. Adding a static route on my PC, so that the PC will try to access the 192.168.25.x/24 network via 10.10.10.1 (FortiGate).

Traceroute will display only * * * on the process to reach the 192.168.25.x/24 network.

Any Idea?

I have tried using the search, but I couldn't find anything similar.

Improve this question
2
  • Thank you. Didn't know it, i thought it would be ok to ask here.
    – Philipp Kahr
    Commented Jan 12, 2016 at 7:39
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide your own answer and accept it.
    – Ron Maupin ♦
    Commented Aug 13, 2017 at 0:57

2 Answers 2

Reset to default
1

You could try an easy solution: when connected via FortiClient, NAT your source IP address to the HQ network's range. For this, enable 'NAT' in the policy from client tunnel to HQ_LAN. From this point on, your client will be treated as any host on the HQ network, including routing and policing to the branch network.

As an alternative, you could build a second phase2 just for the 10.10.10.x network, on both sides of the HQ-BR tunnel, add this network to the tunnel policies on both sides, and add routes in Branch and on the client PC. That last requirement almost always justifies NATting instead.

Improve this answer
0

There could be several issues, first get rid of the static route on the VPN client, if the route is not there then the problem is elsewhere. Post routing table while connected to VPN (route PRINT).

I assume you're not using split tunneling for the client VPN and advertise a default route, right? It should be in the routing table when connected.

Then check whether you have defined network 10.10.10.x/24 in phase 2 of the HQ-Branch VPN on both sides as for it to communicate directly (without NAT), it MUST be there.

1.) For policies check whether you have correct source and destination interfaces - source should be ssl.root (or equivalent) and destination branch IPSec VPN interface

Improve this answer
0

Not the answer you're looking for? Browse other questions tagged or ask your own question.