SSLVPN to Remote Site via IPSec VPN?

[wcbenyip]

Hi ALL, I get an issue still finding the way to solve it, hope can invite your input or advise in a faster way, thanks! This is the case: I have to allow some clients to connect to the Office A via SSLVPN, and then accessing the resources in Office B, in which the Office B & Office A are connected by Site-to-Site IPSec VPN. Once the SSLVPN client is connected successfully, I can only access to the resource in Office A, but even cannot ping to resource in Office B... Do you have any suggestion/idea to enlighten me? Thanks a lot!

[rwpatterson]

See this post: http://support.fortinet.com/forum/tm.asp?m=92337&p=1&tmode=1&smode=1 Bottom line, your office site A needs to have it' s tunnel to site B set up in interface mode.

[beaven67]

I have the exact same scenario with only one major difference. Site B is not a fortinet firewall so A route based vpn may not be doable in every circumstance. I suspect that this is possible using a policy based vpn as well. Does anyone have any input on this? Idea' s

[rwpatterson]

Both sides don' t need to be set up in the same way. If using 2 FGTs, one could be interface while the other route based. As long as the tunnel is established and the handshaking is good, the other end shouldn' t care one way or the other how it' s done. With a policy based tunnel, there is no way to tell the local FGT how to route traffic to remote subnets that aren' t directly attached to the remote unit. In route mode, try it all you want. When you' re done pulling your hair out, set up the tunnel in interface mode, set up the static routes, and enjoy your favorite beverage.

[wcbenyip]

rwpatterson

Thanks rwpatterson! I just re-setup the site-to-site IPSec VPN in Interface Mode at mid-night. Now the tunnel is up and traffic could be redirected to both side. However, I have a bit confuse with the static route and the local IP / remote IP that " should be" configured on the Interface as a virtual one. Does the virtual IP have to be setup? Because it' s indicated on the fg doc, the IPs should not be used in any network. During the traceroute, that interface IP would be one of the hop as gateway to another side... can I omit that interface IP and use the firewall' s internal IP just like in policy based vpn mode? Also, it seems that I still cannot allow the SSLVPN subnet to access to the remote Office B resource...

[rwpatterson]

ORIGINAL: wcbenyip However, I have a bit confuse with the static route and the local IP / remote IP that " should be" configured on the Interface as a virtual one. Does the virtual IP have to be setup? Because it' s indicated on the fg doc, the IPs should not be used in any network. During the traceroute, that interface IP would be one of the hop as gateway to another side... can I omit that interface IP and use the firewall' s internal IP just like in policy based vpn mode?

You only need the interface IP if you are doing higher level routing (OSPF, BGP, etc).

Also, it seems that I still cannot allow the SSLVPN subnet to access to the remote Office B resource...

The easiest way to fix that would be to NAT that traffic with an IP address that is permitted in the phase 2 selectors for the tunnel. The long way would be to add another phase 2 that covers the SSL VPN IP subnet. Oh yes, and the correct policy needs to be in place!

[wcbenyip]

1/ So, that means if I am not applying higher level routing, then it' s no need to set the interface IP and just leave it as 0.0.0.0 is OK? 2/ Actually, we have the dial-up IPSec VPN client that connecting to the Office A, and then going to Office B with that Interface Mode VPN as well... now I cannot access to the fc client from Office B.... and detailed hint? Many thanks! More detail: (current scenario) FC client(IPSec) ---> Office A <---(IPSec VPN interface mode)---> Office B + SSLVPN Q1/ FC Client ---------> Resource in Office B Q2/ SSLVPN ----------> Resource in Office B Q3/ Office B ----------> FC Client