Contributor

Question

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

Forum|Forum|16 years ago
May 20, 2010
5 replies
9693 views

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

New Member

create a frirewall rule ssl.root => DMZ accept

A

Anonymous_UserAuthor

Contributor

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

New Member

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

New Member

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

A

Anonymous_UserAuthor

Contributor

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]

A

Anonymous_UserAuthor

Contributor

More infomation: Internal user, 192.168.116.0, can access DMZ http://172.17.100.1, can access http://192.168.116.1 SSL VPN user, 192.168.117.0, CANNOT access DMZ http://172.17.100.1, can access http://192.168.116.1 but if the VPN user manually add " route add" (in their windows PC command prompt) a static route to DMZ network, they can load http://172.17.100.1 successfully my question is how to inject a route to DMZ for the SSL VPN users?

darrencarr

New Member

Hi Bill, You can use PuTTY client to capture the debug log. Download the client from http://www.putty.org/ and adjust the window properties to capture 200 lines of output. Get the debug setup just before the user connects. If you do it too soon (depending on your timeout settings) your session may expire. Can you also tell me what model of Fortigate you are using, and how your network is laid out, i.e. are all the Interfaces (DMZ, Internal) interfaces on the Fortigate unit? Can you also detail each of the interfaces, their IP address and subnet mask. Reason I ask is that I have seen people use an IP address for an interface of 172.17.7.1/32 Really, if your interfaces are configured correctly, and are all configured on the Fortigate, then all you need is policies that are correctly configured. Post the debug log and we can take it from there

A

Anonymous_UserAuthor

Contributor

ORIGINAL: darrencarr Hi Bill, You can use PuTTY client to capture the debug log. Download the client from http://www.putty.org/ and adjust the window properties to capture 200 lines of output. Get the debug setup just before the user connects. If you do it too soon (depending on your timeout settings) your session may expire. I have PuTTY ready, but which IP should I key in " dia deb flow filter sa" before the SSL VPN user connects? As the SSL VPN user will get their IP after they are connected. I tried a SSL VPN user connected IP 192.168.117.100 to dia deb flow filter sa, and ask the user to access http://172.17.100.1, but the putty dont show anything. Do I need to look into other log file for the debug? Can you also tell me what model of Fortigate you are using, and how your network is laid out, i.e. are all the Interfaces (DMZ, Internal) interfaces on the Fortigate unit? Can you also detail each of the interfaces, their IP address and subnet mask. Reason I ask is that I have seen people use an IP address for an interface of 172.17.7.1/32 I' m using Fortigate-60 3.00-b0741(MR7 Patch 5), all interface are on the Fortigate. Network layout: dmz 172.17.100.254 / 255.255.255.0 internal 192.168.116.1 / 255.255.255.0 wan1 (PCCW) 202.181.x.x / 255.255.255.224 Really, if your interfaces are configured correctly, and are all configured on the Fortigate, then all you need is policies that are correctly configured. Post the debug log and we can take it from there

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

ede_pfau

SuperUser

Has anybody noticed that the OP posted a " xxx.0" as a host address? Wonder if that would work...

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded