SSL VPN connects but no reply from internal network

[scerazy]

Done all by the book (OK, pdf manual) SSL VPN is setup, I can login fine to either Portal or tunnel, but get NO reply from internal servers that have FG as default GW I have the firewall rule for SSL-VPN from Internet to port24 (default GW for my 10.0.0.0/16 network) with ID based Policy for SSL VPN Users and FW rule for tunnel from ssl.root to port24 and the correct routing for my VPN Pool 172.16.199.0/24 I can connect fine to the FTG SSL VPN, but get no reply from anything Using ie Portal Connection Tool Ping I get: 10.0.0.32 is not reachable because of permission denied Any suggestions? My Internet interface is a group of WAN1 & WAN2 as weighted load balance 2 ISPs I CAN ping port 24 10.0.1.1 on the FTG after connecting with SSL client

PPP adapter fortissl:
 
    Connection-specific DNS Suffix  . :
    Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
    Physical Address. . . . . . . . . : 00-53-45-00-00-00
    DHCP Enabled. . . . . . . . . . . : No
    IP Address. . . . . . . . . . . . : 172.16.199.2
    Subnet Mask . . . . . . . . . . . : 255.255.255.255
    Default Gateway . . . . . . . . . :
    DNS Servers . . . . . . . . . . . : 10.0.0.32
                                        10.0.0.32

Thanks Seb

[darrencarr]

Hi Seb Just to confirm a couple of things 1) you have a static route that specifies DESTINATION: 172.16.99.0/24 DEVICE: ssl.root GATEWAY: 0.0.0.0 Distance: 10 2) you have an external->ssl.root policy with action set to SSL-VPN 3) you have a policy ssl.root -> internal with action set to ACCEPT 4) you have defined the services you want to allow from ssl.root -> internal (PING, DNS, etc) 5) you have defined your users/user groups for connecting to the sslvpn If this fails, and you can successfully connect to the VPN, you could then try to use the built in debug commands to troubleshoot your problem. I like to use dia deb fl fil sa 172.16.199.2 dia deb fl fil da 10.0.0.32 dia deb sh con en dia deb fl tra sta 99 dia deb en Try to PING again and see what you get in the console. It may be that the route is incorrectly configured or you are being blocked by not having a policy defined. It should be fairly obvious from the output where the problem lies.

[scerazy]

Yes, setup should not be a problem at all. After all it is just a bit of logic, but... does not work Yes, I have the static route setup correctly Yes, FW rules are as below:

12 	Internet 	ssl.root 	* all		* InternalLAN	always	ANY	SSL-VPN
 	
 15 	ssl.root 	port24 		* VPN pool	* InternalLAN	always 	* ANY	ACCEPT
 

4. ??? Where? I have ANY 5. Yes, from LDAP, which works fine for connecting to VPN Sadly the debug commands do NOT run on 4.0 MR1 build 194 # dia deb fl fil sa 172.16.199.2 ambiguous command before ' fil' Command fail. Return code -7 Seb

[darrencarr]

Seb Apologies, I should have updated my lab before posting the debug. I have begun the upgrade and left it running when I left the office. Not sure if this command is available but the ' fl' was flow....must be additional commands in v4 beginning with fl Is flow an option? if so try dia deb flow fil sa 172.16.199.2 I will look into it more tomorrow when in the office.

[scerazy]

Following are the correct synatx (thanks to FTG support) diag deb reset diag debug en diag debug flow filter saddr 172.30.199.1 diag debug flow filter daddr 10.0.0.32 diag debug flow show console en diag debug flow show function-name en diag debug flow trace start 99 To stop debug, run the following command diag deb disable diag deb reset And I can see what is going on wrong. Now I can try to fix it Will keep you posted Seb

[darrencarr]

Thats good. Hope you can resolve. dia deb fl - used to work in 3 They must have added additional commands beginning with fl Looking forward to upgrading my units in the next couple of weeks to 4 Will be good to hear how you resolved the problem.

[scerazy]

It turned out that I was missing policy route to push the traffic from ssl.root to internal lan through Port24 (once done all works as expected) I have also another port configured on the same subnet via: config system settings set allow-subnet-overlap enable end and the traffic from ssl.root was insisting on going via the other port (hence was going nowhere) Amazed at FTG support how quickly they solved the ticket (normally it takes way too long!) More about policy routing is here: http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=10815&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=3119717&stateId=wrong%20Id Seb