SSL VPN Routing over another VPN

[RolandBaumgaertner72]

Hi,

we are not able to make this working. We have a VPN functioning from our FG to another SonicWall and the idea now is that a remote SSL VPN user connects to our FG and than via the main VPN to the other network.

In the VPN Portal we route the network of the SonicWall. Also we have a new SSL VPN policy to this other VPN and network. Just to be sure we also tried with Policy Route from SSL VPN to VPN Sonicwall.

Are we missing something or is it a problem on the SonicWall site?

Thanks!

[AEK]

Hi Roland

First, try sniff the traffic at SonicWall level to see if packets from SSL VPN client are reaching the second site. If so, check if SonicWall is routing the replies through the tunnel as well.

[RolandBaumgaertner72]

Hi,

Thanks for the fast response. We dont have access to the SW but we know that the VPN FG<>SW is working. So first I wanted to be sure, that from our site everything is OK.

Thanks

[AEK]

Then try diag sniffer packet on FG to see if the packets from SSL VPN are forwarded through the right tunnel.

[AEK]

diag sniffer packet any 'host x.x.x.x and icmp' 4

Where x.x.x.x is the IP of SSL VPN client.

Then try ping the remote site from the SSL VPN client.

[ede_pfau]

---

@RolandBaumgaertner72 wrote:

Hi,

Thanks for the fast response. We dont have access to the SW but we know that the VPN FG<>SW is working. So first I wanted to be sure, that from our site everything is OK.

Thanks

We dont have access to the SW

---

So if traffic is originating from the SSLVPN, how does the SW know where to route the replies to?

Looks like a routing issue to me.

Try to NAT the traffic to your IPsec VPN address range (which is included in phase2). You can do that in the policy SSLVPN -> IPsec VPN, after creating an IP pool with 1 address. Should work instantly, and it's very easy to sniff.

But there are limits: traffic from your side and it's replies will work but traffic from their side into your SSLVPN will not. Without additional configuration on the SW's side you cannot join a new network.

"NAT is poor man's routing."

Often, instead of fixing the underlying error in routing you can make it work with NATting. Within limits.

[dbhavsar]

Hi @RolandBaumgaertner72 ,

- One thing make sure that you have the SSLVPN subnet added to phase2 selectors on IPSec VPN and make sure that phase2 selector is up.

- Another thing is you will need a policy from sslvpn to ipsec tunnel, with NAT disabled on it also reverse policy is needed for the same.

[hbac]

Hi @RolandBaumgaertner72,

Please refer to the following articles: 

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Forward-traffic-originating-from-SSLVPN-in...

https://community.fortinet.com/t5/FortiGate/Technical-Note-U-turn-traffic-from-SSL-VPN-to-IPsec-Site...

You can run packet sniffer and debug flow to see if traffic is leaving FortiGate via the site to site VPN tunnel or not. Replace x.x.x.x with destination IP and generate ping. 

di deb disable
di deb res
diagnose debug flow filter clear
di deb flow filter addr x.x.x.x
di deb flow filter proto 1
diagnose debug flow show function-name enable
di deb flow show iprope en
diagnose debug console timestamp enable
diagnose debug flow trace start 9999
diagnose debug enable

Regards, 

[RolandBaumgaertner72]

Hi,

thanks for all information. The P2 with the SSL VPN network wasnt UP so we fixed it. I did the sniffing and from our FG traffic went from SSL to VPN so it was OK. At the end it was a policy on the SD with wrong SSL network.

Thanks!