1

we configured our FortiGate 50B to route traffic from our local net 192.168.10.* (which is our office) to a remote network 172.29.112.* using an ipsec tunnel. Everything works fine as long my computer has an ip from 192.168.10.*.

We can also connect to the office network from at home using a ssl vpn connection. Once connected we receive an ip from 10.41.41.*.

Now I want to allow the traffic flow from 10.41.41.* to 172.29.112.* just like it does from the office network.

Could somebody point me in the right direction what I would need to do?

Thanks, Sascha

2

I had this same situation and fixed it by doing adding the policy from the SSL.vpn interface to the IPsec tunnel interface and then from the IPsec tunnel interface back to the SSL.vpn interface. The issue is what interfaces the traffic is allowed on. It will not hairpin to an interface that is not defined in a policy.

1

I'm in your same situation.

This is what I tried but didn't work (All IPs are an example and were taken from your question):

NAT to a Virtual IP (192.168.10.200) all traffic coming from SSLVPN (10.41.41.) and going to IPSEC (172.29.112.) So all SSLVPN traffic is being translated to an internal IP which should go trough the tunnel fine. By this way we could avoid modified IPSEC destination but didn't work.

The only way is to add in both IPSEC sides our SSLVPN network (10.41.41.*), as Alex said so all traffic would be routed fine

0

There's some information missing in your question.

Mostly;

  1. Are you NATing traffic inside the IPSEC Tunnel
  2. Are you also managing the peer at the other end of the IPSEC Tunnel

Assuming you are not NATing the traffic in the IPSEC tunnel, this is a quick checklist.

Add the 10.41.41.x subnet to your Interesting traffic

This will indicate that the 10.41.41.x subnet is expected to transit in the IPSEC Tunnel. You have to make that configuration change on both devices at each end of the IPSEC tunnel. If this is not done properly, your VPN wont even be able to complete Phase 1 of the IPSEC tunnel.

Add routes

Make sure your SSL VPN sends a proper route to the clients. This mean that the clients should have a route for the 172.29.112.x when connecting to the SSL VPN.

The same is true on the 172.29.112.x network, it needs to know where to route packets to 10.41.41.x .

In some cases, for example if both peers on the IPSEC VPN are also the default routers on their respective network, it might not be needed.

Add policies

I'm not a Fortinet expert but most firewall will also require that you explicitly allow traffic inside a VPN tunnel with policies or ACLs. This is true for both the IPSEC Tunnel and the SSL VPN connectivity.


Like I said, this is a pretty vague answer (i.e. they are pointers) but since there's not much specifics in the question, it's the best I can think of.

1
  • Thanks Alex, for the detailed answer to my imprecise question. (1) No NATing. (2) No, unfortunatly not. I asked the other admin to configure the tunnel to include the missing subnet, but I have to wait for his answer. Once that is done, I'll write a comment about the outcome. – Sascha Jun 13 '14 at 8:39
-1

1 – Go to Firewall Objects > Address > Addresses > Create New

Create the subnet 172.29.112.0/24 (type Subnet, Interface Any and check Show in Address list) named SubnetRemoteIPSEC

Create another subnet 10.41.41.0/24 (type Subnet, Interface Any and check Show in Address list) named SubnetClientSSL

2 – Go to your VPN SSL Policy and add the SubnetRemoteIPSEC in Local Protected Subnet (you should already have your office subnet here (192.168.10.0/24)).

3 – Add a new policy : Incoming Interface ssl.root

Source Address SubnetClientSSL

Outgoing Interface Name of your VPN interface

Destination Address all

Schedule Always

Service all

Action Accept

Enable NAT

Use Dynamic IP Pool and Create a pool (you can put the IP LAN of your fortigate 192.168.10.254-192.168.10.254 assuming that 192.168.10.254 is your internal IP).

You will be now able to access to your VPN IPSEC through the VPN SSL.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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