[SOLVED] SSL vpn to remote network via ipsec

[kilrathi]

I' ve been working on this problem for a week now. I' ve spoke to Fortinet support and they comfirm my setup on the Fortigate is correct. Here' s what I have. Network 1 Subnet 10.1.3.0/24 SSL VPN Subnet 10.1.4.0/24 Network 2 Subnet 10.1.2.0/24 I want my users to be able to connect to Network 1 via ssl vpn. Once they are connect i want them to be able to use resources on Network 2. Network 1 & Network 2 are connected via a IPSec vpn connection. Users from Network 1 on subnet 10.1.3.0/24 can communicate with Network 2 just fine. Users from Network 1 on subnet 10.1.4.0/24 via SSL vpn cannot communicate with Network 2 at all. Network 1 is a Fortigate 60c Network 2 is a Cyberguard SG580 The SSL VPN connection is setup with tunnel mode enabled and split tunneling *disabled*. This means when my users connect all their network traffic (Intranet and Internet) are funneled through the SSL VPN connection. Inside the IPSec tunnel that connects the two networks together I have both 10.1.3.0 and 10.1.4.0 listed as an allowed subnet in the Phase 2 config. The routing table is identical as to the 10.1.3.0 and 10.1.4.0 networks respectively. When i run diag commands from Network 1 to trace the packets it shows the connection going to the remote network (Network 2) but I am not getting a response when using the 10.1.4.0 subnet. Originally i thought this was a routing issue, but the SG580 (Network 2) has the same config for 10.1.4.0/24 as 10.1.3.0/24. If neither of them worked I wouldn' t be as confused. Has anyone else ran into this type of issue when trying to connect to a remote network through your SSL VPN connection and a IPSec tunnel? I' m running a Fortigate 60c (Firmware 4.0 MR2) and a Cyberguard SG580 (Firmware 4.0.10) Any help or insight is appreciated.

[rwpatterson]

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.

[kilrathi]

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.

[rwpatterson]

If the policies are in place as well, I can' t see why this doesn' t work. Have you assigned IP addresses in the portal?

[kilrathi]

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.

[rwpatterson]

Perhaps the remote end device isn' t sending the traffic back because it doesn' t know about your private network. Run a diag sniffer trace on the IPSec interface and watch the packets.

[kilrathi]

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.

[rwpatterson]

That' s not entirely true. If the far end doesn' t have a static route back to that subnet, it will go out their default gateway, not the tunnel. Here' s quick trick: Create an IP pool with one IP address on the 10.1.3.0/24 network, and assign it to the policy for the SSL VPN users. They will ride the working IP subnet across and back.

[kilrathi]

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

[kilrathi]

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.