[SOLVED] SSL vpn to remote network via ipsec

You have to have the VPN tunnel between the firewall built in interface mode on the FGT to get this to work. Policy mode will fail since there is no way to route traffic from one remote network to another. The policy based SSL VPN will only know about directly connected FGT networks. With Interface mode, you have to tell the FGT what the remote networks are and which path to route that traffic down.

Both the VPN SSL and the IPSec connections are interface based not policy based. Sorry i didn' t include that to begin with. I have static routes on the 60c as follows: 10.1.2.0/24 -> IPSec1 10.1.4.0/24 -> ssl.root IPSec1 is the interface name for my IPSec connection between Network 1 and 2. ssl.root is the interface name for my SSL VPN connection.

Yes I have a group specifically for my portal users ip range. I' m getting an ip address in the 10.1.4 range when i connect via SSL VPN. As to the policies I went over them several times and Matthew from Fortigate support also looked over them with me. He says everything is configured correctly on the Fortigate. I' m hoping someone has dealt with interfacing with a SG580 or Cyberguard (Now Mcafee) and Fortigate products. What baffles me the most if the face that my 10.1.3.0 subnet (Network 1) can communicate with 10.1.2.0 (Network 2). The configuration for the 10.1.4.0 subnet (Network 1) is identical. The only difference is the interface used. The firewalll policies use IPSec1 as the interface name for the 10.1.3.0 subnet. ssl.root is the interface used for the 10.1.4.0 subnet. Other than that their allowances and usages are the same.

Its not sending the packets back. The problem is why is it working on the 10.1.3.0 subnet? Both 10.1.3.0 and 10.1.4.0 are running across the same IPSec connection. If 10.1.4.0 won' t work then 10.1.3.0 shouldn' t work either.

It doesn' t have a static route for 10.1.3.0 or 10.1.4.0. The only thing i can assume is it builds the routs dynamically based on the IPSec P2 config which specifies 10.1.3.0 and 10.1.4.0. As far as the Cyberguard SG580 (now Mcafee) goes I' ve never had to build a route for IPSec connections. It just does it. Now the Fortigate has the routes built properly. I' ve tested the SG580 with other facilities and creating the static route isn' t necessary for other router types as well as far as the SG580 is concerned. The big difference here is I' ve never routed more than one subnet across a IPSec connection. Here' s what the routing table looks like on the SG580. Destination Gateway Genmask Flags Metric Ref Use Iface 10.1.4.0 * 255.255.255.0 U 0 0 0 ipsec0 10.1.4.0 - 255.255.255.0 ! 2 - 0 - 10.1.2.0 * 255.255.255.0 U 0 0 0 eth0.2 10.1.3.0 * 255.255.255.0 U 0 0 0 ipsec0 10.1.3.0 - 255.255.255.0 ! 2 - 0 - default [edit] 0.0.0.0 UG 3 0 0 eth1 default [edit] 0.0.0.0 UG 4 0 0 eth0.5 default [edit] 0.0.0.0 UG 4 0 0 eth1 As you can see the route is the same as the 10.1.3.0 network. This is correct. Here' s the router static config for the 60c sh router static config router static edit 1 set device " wan1" set gateway [edit] next edit 2 set device " IPSec1" set dst 10.1.2.0 255.255.255.0 next edit 3 set device " ssl.root" set dst 10.1.4.0 255.255.255.0 next end

I' m adding this for my own reference in addition to anyone else who may have ran into this problem. Hopefully google will pick this up so 3 years from now when I' ve forgotten how I solved this I can remember with a simple google search. The solution was failry simple. I added a second IPSec Phase 2 entry for the vpn tunnel to Network 2. The configuration is as follows: Network 1 (Fortigate 60c): 10.1.3.0/24 SSL VPN Subnet 10.1.4.0/24 Network 2 (Cyberguard SG580): 10.1.2.0/24 -=IPSec on Network 1=- One Phase 1 setup as a tunnel from Network 1 to Network 2. Two phase2 tunnels associated with the phase1 tunnel mentioned. The first one is mapped to 10.1.3.0/24. The second one is mapped to 10.1.4.0/24 -=IPSec on Network 2=- One IPSec setup to match the settings on the fortigate. The wrinkle to this is at the end you have an option to map subnets. One the Cyberguard I mapped 10.1.2.0/24 to 10.1.3.0/24 and then another entry for 10.1.2.0/24 to 10.1.4.0/24. When you do this on a Cyberguard / Secure Computing router it is the same as adding a second Phase 2 entry on the Fortigate. The solution to connect two subnets on the Fortigate 60c to the Cyberguard SG580 single subnet was two phase2 entries on the 60c. *Not* two subnets mapped in a firewall object under a single phase2 entry.

for future reference: If you want to have multiple subnets across an IPsec VPN then you can create an address group with multiple address objects in it, and put that into the QM selector as source or destination network. Here are the restrictions: 1. this usually works only from Fortigate to Fortigate 2. you have to switch the QM type to ' address' in the CLI 3. you have to use address groups for BOTH source and destination subnets even if one contains a single item only (the CLI does not enforce this requirement) Given these restrictions, it' s usually less hassle to create a bunch of phase 2' s if the number of subnets is small. I haven' t tried it but with an address you can specify an IP range as well as a subnet. You cannot do that directly in a QM, can you? So that would be another case for using the address group configuration.