Newbie - how can SSL VPN user access " dmz" ?

[#1]

Hi there, I am a newbie to Fortigate. I got one Fortigate-60 with v3.0 MR7. I setup a SSL VPN for remote user connecting back to office, they can access " internal" resources but not " dmz" resources. How can I let them to access " dmz" ? Little info: Fortigate IP: 192.168.116.1 Office IP: 192.168.116.0/24 DMZ IP: 172.17.100.254 Remote user IP:192.168.117.0/24 Thanks advanced Bill.

[claumakurumure]

create a frirewall rule ssl.root => DMZ accept

[#3]

oh thanks, I did it but still fails... I found that the SSL VPN user do not have route to my " DMZ" network, there is just routes to my " internal" network so I tried teaching the SSL VPN user to " route add" manually, they get into " DMZ" successfully, but it need the user doing such exercise everytime do you have any idea to let the SSL VPN users to have a route to " DMZ" network automactially once they are connected? thanks

[darrencarr]

Hi Bill, If your DMZ is connected to your Fortigate then you don' t need to define the route. If you go into the system and go to Router -> Monitor you should see the ntry for your DMZ. The type should be ' Connected' If this is the case then all you should require is a policy from ssl.root -> DMZ. You can further restrict the policy by defining the source as the SSLVPN range and also the destination host(s). With this in place it should work. If this fails you can look into setting up a debug session on the firewall to better understand the flow of the traffic, and where the problem lies. To do this (please bear with me I am using FortiOS 4) use the following steps: dia deb flow filter sa <ip address of your ssl.root connected host> dia deb flow filter da <ip address of the host you are trying to connect to in the DMZ) dia deb flow show console enable (enables debugging to the console) dia deb flow trace start 99 (outputs the first 99 lines of the debug session) dia deb en (enables the debug) After doing this attempt to connect to the DMZ via the ssl.root, and review the results of the debug session. You will more than likely find it is a policy issue or something along these lines. You may even have a static route in your firewall that is causing the traffic to be routed to the wrong destination. Given your network is connected to the firewall (DMZ) and has a distance/metric of 0, it should superceed any static route you have defined. If you are still struggling post the output of your debug session. D

[rwpatterson]

Make sure the ' WANx -> ssl.root' policy allows the same services you need to the DMZ.

[#6]

ORIGINAL: rwpatterson Make sure the ' WANx -> ssl.root' policy allows the same services you need to the DMZ.

[size=3]Yes, there is a policy " wan1 -> ssl.root" [/size]

[rwpatterson]

ORIGINAL: beans_billlee

ORIGINAL: rwpatterson Make sure the ' WANx -> ssl.root' policy allows the same services you need to the DMZ.

[size=3]Yes, there is a policy " wan1 -> ssl.root" [/size]

What services are you letting through there? HTTP needs to be one of them. Also, all the ssl.root -> <interface> policies are type ' ACCEPT' , FYI.

[#8]

ORIGINAL: rwpatterson

ORIGINAL: beans_billlee

ORIGINAL: rwpatterson Make sure the ' WANx -> ssl.root' policy allows the same services you need to the DMZ.

[size=3]Yes, there is a policy " wan1 -> ssl.root" [/size]

What services are you letting through there? HTTP needs to be one of them. Also, all the ssl.root -> <interface> policies are type ' ACCEPT' , FYI.

Yes: ssl.root -> dmz (1) 2 * all * Web server always * HTTP ACCEPT

[rwpatterson]

Look again. Not the same policy.

[#10]

Sorry, i dont understand, do you mean i missed any policy or wrong policy applied?