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

PUBLIC IP AS A PHASE 2 SELECTOR IN IPSEC VPN

Hello everyone...

 

I'm supporting a client for an ipsec vpn setup..I have configured everything right.the tunnel is up both phase 1 and phase 2...I have  done the necessary routing and policies and everything looks fine 

 

The remote addresses on the phase 2 selectors are public IP addresses..the traffic destined for this remote address hits the LAN TO WAN policy despite the ingress and egress policies matching the tunnel being at the top of the policy chart...I decided to update the administrative distance for the vpn static routes to a lesser one but this didn't do the trick

Has anyone ever come across this scenario ? And how did you work around it ..I'm running firmware version 7.0.13

 

 

29 REPLIES 29
CHAMPE
New Contributor

Hi ..Due to some privacy concerns I cannot share them..the incoming policy routes should have the outgoing interface as the lan interface and outgoing policy route should have the outgoing interface as the sd wan member interface. Right?

AEK

I don't think you will need any "incoming policy route".

You need only one policy route on local FG as follows:

  • Source: LAN
  • Destination: Specific public IP address(s)
  • Destination interface: Tunnel interface
  • Gateway: Remote IP of tunnel interface

If you do that and you have no other policy route then it should work fine.

AEK
AEK
CHAMPE
New Contributor

Thanks..I'll give it a try

Skytech1
New Contributor III

Hey Champe,

 

When doing a sniffer what comes in the output?, can you share the config? It shouldn't be a problem, the fortigate shouldn't care if the address are public or private

CHAMPE

The issue is the traffic is not going through the tunnel but through the lan to wan policy 

Skytech1
New Contributor III

You can try to set phase2 to "all" something like this:

edit "VPN_Name"
set phase1name "VPN_Phase1"
set proposal aes256-sha256
set pfs disable
set auto-negotiate enable
set keylifeseconds 9600
next

 

And manage the routing on the Routing Section with a static route...i've done this several times and it works

Toshi_Esumi
SuperUser
SuperUser

Actually I have SD-WAN with two circuits on my 40F and a bunch of rules with them at the same time two IPsec VPNs to company network, which are NOT a part of SD-WAN interfaces. And, there is NO policy routes at all.
But I can access/ping one of public IP in my company's network over the tunnel once I put in a specific route toward the tunnel interface. I verified with traceroute. (BTW, I use 0/0<->0/0 for network selector so don't have to adjust)

Can you ping the destination IP from the FGT? If you ping it from inside of FGT, it shouldn't be using any policy routes/SD-WAN rules but just folloing the route in the routing table.
If this doesn't get to the destination, something is wrong for the tunnel setup. If this gets through, your policy routes (probably unnecessary) are getting in the way for the traffic from the real client devices over the tunnel.

If you can't share your config in this forum, you should open a TT at TAC to get it examined privately.

 

Toshi

CHAMPE

We had a Tshoot session with TAC earlier and he took some log files and conf file for analysis. I cannot ping the remote address from the firewall itself..the topology looks like this for the outgoing traffic internal server..>ip pool (overload nat) ...>tunnel...>Site B. For the incoming traffic site B ...>tunnel.. >Lan ..>Dst: Virtual IP( for the server)

 

I'll try removing the interface from the SD wan zone ..hopefully it works 

Toshi_Esumi

Just trust the TAC person. Any one of them should be able to figure this out as long as he/she has given proper access to your network.

Toshi

CHAMPE
New Contributor

Hello everyone 

Policy route did not do the trick..one of my colleagues advised changing the route metric of the sdwan zone to a higher one and changing the metric of the IPSec interface route to a metric lower than that...I believe this will do the trick considering the subnet defined for the ipsec route is a specific one

Labels
Top Kudoed Authors