Can an SSL VPN run without NAT?
FortiClient 10.200.0.x -> Router 10.0.0.1 -> FGT 10.0.0.10 -> Internal Network 10.0.0.X
Running into a problem with internal software trying to connect back to the client but it only sees the client as 10.0.0.10 and not 10.200.0.x. Is it as simple as disable NAT on the policy? Or is there more to it than that?
Thanks
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
If the internal software makes contact to the clients spontaneously, don't forget to add a policy toward ssl.root.
Scratch this entry.
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
NAT should only be needed on policies facing the Internet. Any policy that doesn't reach out to public space should be safe to have NAT disabled.
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
OKay, so I can simply disable NAT on the policies... I'll give it a go.
If the internal software makes contact to the clients spontaneously, don't forget to add a policy toward ssl.root.
toshiesumi wrote:So I just tried disabling it on policy 3 below and while the VPN connection stayed, I couldn't RDP in so I must have a problem with the policy. What else would I be missing?If the internal software makes contact to the clients spontaneously, don't forget to add a policy toward ssl.root.
edit 3 set name "RDP" set srcintf "ssl.VPN" set dstintf "port3" set srcaddr "SSLVPN_TUNNEL" set dstaddr "RDP Clients" set action accept set status enable set schedule "always" set service "RDP" "DNS" set utm-status enable set logtraffic all set groups "RDP_Only" set av-profile "g-default" set ssl-ssh-profile "certificate-inspection" set nat enable next
edit 4 set name "To_SSL_Clients" set srcintf "port3" set dstintf "ssl.VPN" set srcaddr "all" set dstaddr "SSLVPN_TUNNEL" set action accept set status enable set schedule "always" set service "ALL" set nat enable next
I would drop the service limit, currently you have RDP and DNS, then just test with ping to the destination. I'm assuming it wouldn't work. Then start debugging with sniffing and "flow debug" to see why even ping doesn't come through.
routing???
Tip
"diag sniffer packet ssl.root " when doing your test. Check before and after nat is enable. Look at the src ? Can the far end reach back to it?
ssl.root is a interface treat it like any other interface.
Ken Felix
PCNSE
NSE
StrongSwan
emnoc wrote:routing???
Tip
"diag sniffer packet ssl.root " when doing your test. Check before and after nat is enable. Look at the src ? Can the far end reach back to it?
ssl.root is a interface treat it like any other interface.
Ken Felix
Wish I would seen this when I was testing! Clients would lose connectivity immediately when disabling NAT on the policies. Tunnel would stay up but could not reach anything.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1696 | |
1091 | |
752 | |
446 | |
228 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.