Multiple IPsec tunnels with overlapping networks - VIP

[madis]

I need to create several IPsec tunnels, all remote sites with the same network (192.168.0.0/24). It is not possible to do any NAT (or any other config) at remote site.

I would separate the sites by
- site 1 192.168.71.0/24

- site 2 192.168.72.0/24

My test config (FortiOS 7.4.0):

1. Configure VPNs, with 192.168.0.0/24 as remote phase2 selector
2. Configre Virtual IP (first site):
   - External range: DNAT address 192.168.71.1-192.168.71.254
   - IPv4 address: real customer side address 192.168.0.1-192.168.0.254
3. Configure Addresses:
   - DNAT address, with interface and static route (remote1_vip_address)
4. Configure Static route for DNAT address (remote1_vip_address, interface VPN)
5. Configure Policies:
   - OUT: LAN -> VPN, my_lan_address -> remote1_vip_address, no nat
   - REPLY: VPN -> LAN, remote1_vip_address -> VIP, no nat
   - IN: VPN -> LAN, all -> my_lan_address, no nat

It works for one tunnel, but as described in one Reddit post: if there is more than one VIP that the traffic fits, it is handled in the top down order that is followed by policies. It means that traffic meant to 192.168.72.0/24 will be routed to 192.168.71.0/24.

Is there a simple and standard solution to handle the problem?

[spoojary]

Try the following doc : 

https://docs.fortinet.com/document/fortigate/7.2.4/administration-guide/426761/site-to-site-vpn-with...

[madis]

I would like to specify my initial question. The goal is to establish multiple VPN-s with overlapping customer-side addresses. It is not possible to either NAT or change the address at customer’s end.
In that case, I can't see any possibility that the instruction above could be used.

Below is the config that I have tried and explanation why it fails. If there is another way to do it, I would very much appreciate your support. The only way I see it possible, is to initiate the traffic coming into the firewall from different IP-s.

My idea was to route the traffic either by DNAT-ed destination address or SNAT-ed source address, using policy routes.

• Overlapping subnet: 192.168.2.0/24
• Mask overlapping subnet to:
  • tun1: 10.168.2.0/24
  • tun2: 10.169.2.0/24
• Local LAN: 172.16.0.0/24
• Mask local LAN to:
  • tun1: 10.16.0.0/24
  • tun2: 10.17.0.0/24

Config:

• Address objects:

NAME	ADDRESS	INTERFACE
local_lan	172.16.0.0/24	lan
remote_lan_tun1	192.168.2.0/24	tun1
remote_lan_tun2	192.168.2.0/24	tun2
pool_lan_tun1	10.16.0.0/24	lan
pool_lan_tun2	10.17.0.0/24	lan

• VPN-s:

VPN NAME	Ph2 LOCAL ADDRESS	Ph2 Remote Address
tun1	pool_lan_tun1	remote_lan_tun1
tun2	pool_lan_tun2	remote_lan_tun2

• Virtual IP-s:

NAME	INTERFACE	EXTERNAL IP	MAPPED IP
VIP_remote_tun1	lan	10.168.2.1-10.168.2.254	192.168.2.1-192.168.2.254
VIP_remote_tun2	lan	10.169.2.1-10.169.2.254	192.168.2.1-192.168.2.254

• IP POOLs:

NAME	TYPE	EXTERNAL	INTERNAL
POOL_pool_lan_tun1	Fixed port range	10.16.0.1-10.16.0.254	172.16.0.1-172.16.0.254
POOL_pool_lan_tun2	Fixed port range	10.17.0.1-10.17.0.254	172.16.0.1-172.16.0.254

• Policies:

NAME	FROM	TO	SOURCE	DESTINATION	NAT
tun1_OUT	lan	tun1	local_lan	VIP_remote_tun1	POOL_pool_lan_tun1
tun2_OUT	lan	tun2	local_lan	VIP_remote_tun2	POOL_pool_lan_tun2

• Policy routes:
  PREFERRED:
  

INCOMING	OUTGOING	SOURCE	DESTINATION
lan	tun1	10.16.0.0/24	192.168.2.0/24 or 10.168.2.0/24
lan	tun2	10.17.0.0/24	192.168.2.0/24 or 10.169.2.0/24

ACTUAL:

INCOMING	OUTGOING	SOURCE	DESTINATION
lan	tun1	172.16.0.0/24	192.168.2.0/24
lan	tun2	172.16.0.0/24	192.168.2.0/24

• Static routes:
  Policy routes don’t get matched without static routes???
  

DESTINATION	INTERFACE
remote_lan_tun1	tun1
remote_lan_tun2	tun2

The problem is, that DNAT is done before routing (10.168.2.254 -> 192.168.2.254) and SNAT is done after routing (172.16.0.1 -> 10.16.0.1). This makes it impossible to use Policy route option:

madisgate # diag debug flow filter addr 10.168.2.254
madisgate # diagnose debug flow trace start
madisgate # diagnose debug enable

madisgate # id=20085 trace_id=69 func=print_pkt_detail line=5644 msg="vd-root:0 received a packet(proto=1, 172.16.0.1:1->10.168.2.254:2048) from lan. type=8, code=0, id=1, seq=460."

id=20085 trace_id=69 func=init_ip_session_common line=5814 msg="allocate a new session-0000230b"

id=20085 trace_id=69 func=fw_pre_route_handler line=181 msg="VIP-192.168.2.254:1, outdev-lan"

id=20085 trace_id=69 func=__ip_session_run_tuple line=3426 msg="DNAT 10.168.2.254:8->192.168.2.254:1"

id=20085 trace_id=69 func=vf_ip_route_input_common line=2566 msg="Match policy routing id=1: to 192.168.2.254 via ifindex-19"

id=20085 trace_id=69 func=vf_ip_route_input_common line=2581 msg="find a route: flag=04000000 gw-192.168.2.254 via tun1"

id=20085 trace_id=69 func=fw_forward_handler line=777 msg="Allowed by Policy-3: SNAT"

id=20085 trace_id=69 func=__ip_session_run_tuple line=3412 msg="SNAT 172.16.0.1->10.16.0.1:60417"

id=20085 trace_id=69 func=ipsecdev_hard_start_xmit line=788 msg="enter IPsec interface-tun1"

id=20085 trace_id=69 func=esp_output4 line=927 msg="IPsec encrypt/auth"

id=20085 trace_id=69 func=ipsec_output_finish line=618 msg="send to 192.168.70.254 via intf-wan"

[Toshi_Esumi]

The problem with your set up is two parallel routes for 192.168.2.0/24 exist in the same routing-table toward two IPsec interfaces. And you don't have control which way to go after DNAT is performed.

One way I know it should work is to separate them into two VDOMs. A problem with VDOMs is the smaller models of FGTs support only 10 VDOMs including root VDOM, so you can have only upto 9 customers.
Another possibility is using VRFs, which can grow much more. But I haven't used VRF so far so I don't know how it would work with just one plane of FW policies with DNATs across VRF boundaries. Somebody else should be able to chime in.

Toshi

[Toshi_Esumi]

I was searching for some sample config in KB pool either VDOM or VRF method. Only one I could find so far was below.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Access-of-remote-overlapping-subnets-over/...

 Although I don't like the design in the KB because it's using both VDOMs and VRFs but it might be necessary if you don't have a routable addition public IP subnet to assign to each VDOM.

I'm still not sure exactly how to set this up with VRFs only but with VDOM-link or NPU vlink, which should be possible. But based on the admin guide below, tt looks like almost the same with multi-VDOM method for routing part because you still need to do "route leaking between VRFs". You can take a look at the admin guide for the route leaking with "star topology" then adopt it into your design. 
https://community.fortinet.com/t5/Support-Forum/Multiple-IPsec-tunnels-with-overlapping-networks-VIP...

Toshi