I'm playing with another VDOM setup. This time the Root vdom will hold the primary traffic while a sub vdom will only have an inbound IPSec VPN connection for remote clients to connect too via forticlient. I've got the root vdom setup and it's passing traffic correctly. The VPN terminates at VDOM-A.
Here is a network map
I've got a VIP at the root vdom that's passing traffic through to the 10.2.2.2 IP. I've got the firewall rule at root that's allowing traffic inbound to the VIP. In VDOM-A, I've got VPN configured with the 10.2.2.2 interface (the intervdom link) so it should be all setup correctly. The "external" (this is all in a lab, no actual real IPs involved) IP for the IPSec VPN is 40.40.40.35. When I try to connect from a VPN client, the connection just times out and won't connect.
If I run a "diagnose sniffer packet any 'host 40.40.40.35'" and run a ping 40.40.40.35 from the VPN client, I see traffic. However, when I actually try to connect with FortiClient I don't see ANY traffic. On the client side I can see the traffic going out, but on the Root or VDOM-A side, I see no traffic at all and I'm lost as to what I've got wrong.
So this is a fortinet on the client side
You can see the ping go out. Then you can see the IPSec connection attempt.
However, on the vdom a side
You can see the ping traffic, but then nothing at all. It makes no difference if I run the diag at the root or VDOM-A context. I can see the ICMP traffic sent by the client to 40.40.40.35. I can even see port 80 traffic if the client tries to browse to 40.40.40.35. When the client tries the VPN connection though, I don't see any traffic.
Solved! Go to Solution.
OMG guys, I'm an idiot. I'm thinking that the problem is with the VDOM because I'm learning that and don't fully understand it. So that's where the problem has to be, right?
Well Mr idiot here, for WHATEVER reason, on the client side didn't have an "any" rule set up. I was only allowing ICMP and HTTP outbound. OMG. I've spent SO much time troubleshooting the wrong side. *facepalm*
Created on 12-11-2024 08:41 AM Edited on 12-11-2024 08:43 AM
For VPN, you need to run IKE debug at VDOM-A where the VPN is terminated at.
Toshi
Nothing shows when I do that.
Perhaps this will supply more clarity.
Created on 12-11-2024 08:59 AM Edited on 12-11-2024 09:00 AM
No. Those icmp packets are not inside the VPN tunnel. Outside. Or, nothing to do with the VPN.
Those UDP 500 packets are the VPN attempts. But since you're filtering with the host IP 40.40.40.35, you don't see the forwarded packet to 10.2.2.2 because those packet don't have the 40 IP any more.
Again you have to sniff/IKE debug on VDOM-A side. Not at root vdom.
Toshi
Created on 12-11-2024 09:02 AM Edited on 12-11-2024 09:04 AM
I respectfully disagree. When tested in another known working config, it does not matter what context the debug is run in. When I figured out the issue, I instantly started seeing the traffic even though I was in a root vdom context.
Then you're NOT terminating the VPN at the VDOM-A interface.
Root vdom has no VPN configured. The only VPN that is configured is in VDOM-A.
I'm leaving for the airport. So share your config with @dingjerry_FTNT and get it troubleshot.
Toshi
Just FYI - from the VDOM-A context (which I call 'Bubble')
So you can see it does not matter what context you run the debug in. I see the traffic in both.
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 |
---|---|
1740 | |
1108 | |
752 | |
447 | |
240 |
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.