Hi All,
I'm tired of beating my head against this wall and am hoping one of you may have a sledgehammer or wrecking ball I can borrow. The use case is as such: PLC vendor needs access to specific VLAN on our network so they can remotely manage their systems. They requested an IPSec VPN to access via the FortiClient.
So far I have an IPSec VPN set up that works almost flawlessly. User can connect, is unable to ping any of our internal IP addresses and can even ping the IP address (172.22.5.2/24) on our core cisco stack. That IP is the VLAN172 IP address. If I SSH in to the cisco device I can ping everything on that subnet no problem. Pinging and tracerouting via the Fortigate CLI succeeds to all 172 subnet addresses as expected as well. But from the VPN the cisco is the only IP address I can ping successfully.
On the internal interface I have a VLAN set up with the proper VLAN ID and 172.22.5.6/24 as the IP address. I have the 172.22.5.0/24 Subnet set up as a firewall object as well as the VPN subnet. I have a single policy set up allowing traffic from the VPN Subnet to the 172 Subnet (always/ALL) and a static route set up from the VPN Subnet to the VPN.
Doing a tracert while connected to the VPN shows it hitting my primary internal interface rather than the VLAN interface. At this point I believe that the VPN is routing across the internal interface rather than the VLAN sub-interface.
Phase1
config vpn ipsec phase1-interface edit "172 VPN" set type dynamic set interface "wan2" set mode aggressive set xauthtype auto set mode-cfg enable set proposal 3des-sha1 aes128-sha1 set authusrgrp "172 IPSec VPN User Group" set ipv4-start-ip 10.10.20.101 set ipv4-end-ip 10.10.20.110 set ipv4-netmask 255.255.255.0 set dns-mode auto set ipv4-split-include "172 Subnet" set psksecret next end
Phase2
config vpn ipsec phase2-interface edit "172 VPN" set phase1name "172 VPN" set proposal 3des-sha1 aes128-sha1 next end
There is one policy in place that is set up with Incoming Interface (172 VPN), Source Address (VPN Subnet), Outgoing Interface (172 VLAN), Destination Address (172 Subnet). All/Always/ NAT is disabled. I also have a static route in place to go from the VPN IP Subnet to the VPN.
Hopefully this makes sense and someone here has the magic bullet to make this VPN work as expected.
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.
Try to enable NAT on policy-10.Thanks.
<<<<I have a single policy set up allowing traffic from the VPN Subnet to the 172 Subnet (always/ALL) and a static route set up from the VPN Subnet to the VPN.>>>>
Dialup User VPN no need set up static routes.
Make sure VPN tunnel is up (dia vpn tunnel list)
You may check it with "debug flow"
dia debug flow filter daddr 172.22.5.2
dia debug flow show console enable
dia debug flow trace star 20
Thanks.
Hi Jeff,
Unfortunately this isn't giving me any data to work with. On the firewall I set up the flow filter and enabled showing the flow on the console and ran "diag debug flow trace start 20" (it threw an error if i didn't make it start rather than star) and then from the connected VPN client I ran a ping. Nothing shows up on the console. Any other troubleshooting routes I can take?
Thanks
I guess you are using low end box which does not have console.
If you using SSH/Telnet/CLI console, try it "dia debug enable" , it will print out debug message on virtual terminal, thanks.
Okay, so here's the results from that..
2016-04-07 10:19:01 id=13 trace_id=434 msg="vd-root received a packet(proto=1, 10.10.20.101:1->172.22.5.2:8) from 172 VPN_0."
2016-04-07 10:19:00 id=13 trace_id=433 msg="allocate a new session-18317071" 2016-04-07 10:19:00 id=13 trace_id=433 msg="find a route: gw-172.22.5.2 via 172 VLAN" 2016-04-07 10:19:00 id=13 trace_id=433 msg="Allowed by Policy-10:" 2016-04-07 10:19:00 id=13 trace_id=433 msg="insert vlan cos:0 id:172"
Repeat that a few times. I then checked for a destination I am not able to make it to and got this:
2016-04-07 10:26:40 id=13 trace_id=442 msg="vd-root received a packet(proto=1, 10.10.20.101:1->172.22.5.51:8) from 172 VPN_0." 2016-04-07 10:26:40 id=13 trace_id=442 msg="allocate a new session-18318acb" 2016-04-07 10:26:40 id=13 trace_id=442 msg="find a route: gw-172.22.5.51 via 172 VLAN" 2016-04-07 10:26:40 id=13 trace_id=442 msg="Allowed by Policy-10:" 2016-04-07 10:26:40 id=13 trace_id=442 msg="insert vlan cos:0 id:172"
So it looks as though it is being sent out from the firewall but not making it back for some reason. I know that the equipment responds to pings from the firewall as if I run a ping straight from the CLI Console it responds back immediately. I'm honestly not sure why I would be getting different results for different IPs over the VPN but not from the CLI Console as well. Obviously something is blocking but I still have no idea what. I'll keep banging at it as I have time and any other suggestions on things to check are more than welcome!
Thanks
Try to enable NAT on policy-10.Thanks.
That did it. Everything I read stated to not have NAT enabled on the policy so it didn't occur to me that I would need to change that. Thanks for the help!
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 |
---|---|
1688 | |
1087 | |
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.