ipsec vpn using fortigate 60d / fortinet 5.2 and forticlient

[DrZoidberg]

good morning,

we have used the conf decribed in the title for a while to allow external users to connect to an internal samba share. the setup followed the cookbook example. this worked very well until we changed the internet provider.

the new provider uses ppoe, to support this we had to add a static route:

Destination 0.0.0.0/0 Device wan1 Gateway 123.123.123.9 

the ip of wan1 is 123.123.123.10. this works for everything (wlan, internal network, rdp from external clients, internal web servers ...) except for the vpn connections. after adding a second policy to allow traffic from wan1 to the vpn interface i'm able to connect with forticlient and there's some data transfered in both directions. the client gets an ip address  but i'm not longer able to see the internal network resources.

any ideas how to fix this?

thanks

lorenz

[EMES]

Do you have a route for your ssl von subnet pointing at ssl.root and a policy allowing the ssl.root interface to the inside?

[Toshi_Esumi · Accepted solution]

Are you sure about the static default route you put in? PPPoE normally injects the default static route with GW automatically into FG's routing table with "ppp1" as the interface (not wan1). Although you still use wan1 in your policies, if you still have to put some static routes toward the circuit you need to have dynamic-gateway enabled (I think you can do it only with CLI) without GW IP then it would automatically point to ppp1 with the GW IP whatever it pulled.

Check the routing table via either GUI or CLI.

[DrZoidberg]

hi toshi,

sorry for the late answer. 

yes, we need that static route. ppoe is not done by the fortigate, we have to use a modem. the setup looks like this:

ONT -> 123.123.123.9 : modem (audiocodecs mediant) : 123.123.123.10 -> wan 1 fortigate 

i've set up a ipv4 policy from wan 1 to the vpn address range (and vice versa). as mentioned i'm able to connect to the vpn and the client gets an vpn range ip adress. but there's no route to the internal network.

[Toshi_Esumi]

So PPPoE has nothing to do with your FG but FG uses Static /30 subnet to connect to the vendor modem/router. Then ISP change shouldn't have done anything to FortiGate's dialup IPSec VPNs. I would suspect the new ISP blocking ESP packets or similar unless you have another IPSec like site-to-site on the same FG, which works fine unlike the dialup IPSec.

You mentioned you sniffed some on the VPN. Now you can sniff with the IP the client pulled like below. You probably don't see anything.

"diag sniffer packet any 'host [CLIENT_IP]' 4"

[ede_pfau]

Nobody mentioning that a policy from "wan" to "tunnel_IF" is nonsense?

When the FGT acts as a (IPsec) VPN gateway it listens on a WAN interface - you can see the relation in Network>Interfaces where the tunnel IF appears as a subinterface of the WAN port. As the VPN traffic is encrypted the physical WAN port has nothing to do with that traffic.

In order to access internal hosts from remote you need a policy from 'tunnel_IF' to 'internal', that's all. And of course a route to the remote hosts' IP address range, pointing to 'tunnel_IF' (no gateway needed). All like stated in the Cookbook recipe.