SSL VPN - only have access to one subnet

[Marklar]

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?

[rwpatterson]

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.

[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]

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.

[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]

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.

[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]

How is the SSLVPN tunnel configured?

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

[Nils]

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]

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!