Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Marklar
New Contributor

SSL VPN - only have access to one subnet

We have a site-site IPSEC tunnel setup reciprocating traffic between SiteA 192.168.1.0 and SiteB 192.168.3.0.

SSL VPN user gets an ip 192.168.1.240 at SiteA but no traffic is allowed to Site B. IPSEC VPN works fine.

 

I tried making a policy from ssl.root > 192.168.3.0...no dice

Static route from ssl.root > 192.168.3.0...no dice

Policy route from ssl.root > 192.168.3.0...nope

 

What are we missing?

9 REPLIES 9
rwpatterson
Valued Contributor III

SSL VPN is a separate interface, but it shares the subnet of the main interface at site A (assuming class C network). This may be the stem of your issue. SSL VPN should have a unique IP subnet from any others.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
Marklar

Thanks - I just changed the IP range in SSLVPN_TUNNEL_ADDR1 to a 10.0.0.1 ip range..same issue. Traffic is still stuck exclusively on the 1.x subnet.

rwpatterson
Valued Contributor III

Does the phase 2 selector on the VPN cover the subnet 10.0.0.x? If it does not, you could create an IP pool with a single valid IP address from the internal interface and apply it to the VPN policy as a test.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
Marklar

I assume you're referring to the site-site tunnel (p2 config attached). But yes, it should be covering the subnet since it's configured for 0.0.0.0 (source) and destination is the 3.x subnet we are trying to access via SSL VPN. I manually went in and specified 10.0.0.1 instead and still same result.  :\

rwpatterson
Valued Contributor III

Marklar wrote:

I assume you're referring to the site-site tunnel (p2 config attached). But yes, it should be covering the subnet since it's configured for 0.0.0.0 (source) and destination is the 3.x subnet we are trying to access via SSL VPN. I manually went in and specified 10.0.0.1 instead and still same result.  :\

In my opinion, here is the time to start the packet level sniffing to see where the traffic breaks down. If you do have the correct policies and routes set up in the remote device, then start the sniffer traces.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
Marklar

I agree with you, but I can't even do that. lol

I'm just going to create a ticket over this one - thanks for your help! I was hoping it was something glaringly easy, but sounds like it's not. Oh well thanks again!

Nils
Contributor II

How is the SSLVPN tunnel configured?

Do you use split tunneling? If yes, have you configured the remote network in the portal/Settings?

 

 

Nils
Contributor II

Marklar wrote:

I assume you're referring to the site-site tunnel (p2 config attached). But yes, it should be covering the subnet since it's configured for 0.0.0.0 (source) and destination is the 3.x subnet we are trying to access via SSL VPN. I manually went in and specified 10.0.0.1 instead and still same result.  :\

Do you have a route back from the other side to the local 10.0.0.0 network?

Does the traffic find its way back through the tunnel?

 

Try to activate NAT in the policy from ssl.root to the destination network and see what happens.

Marklar
New Contributor

Just so it's documented, I opened a ticket on this one and it was configured correctly. The issue was something that had to be enabled in the CLI - though Fortinet support agreed it should have been working as I had it set. Here is what they had to do:

 

config firewall policy

edit 14 (that was the policy which referenced the ssl.root source > wan1 > 192.168.3.x destination config)

set outbound en

 

= done.

 

..For some reason inbound was enabled and outbound was set to disabled in that policy. Took support about an hour to figure out.

I'd have never found that one!

 

Either way, that did it..no explanation why it was disabled in the first place, but whatever.

Thanks for all the help!

Labels
Top Kudoed Authors