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):
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?
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 the following doc :
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.
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 NAME | Ph2 LOCAL ADDRESS | Ph2 Remote Address |
tun1 | pool_lan_tun1 | remote_lan_tun1 |
tun2 | pool_lan_tun2 | remote_lan_tun2 |
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 |
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 |
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 |
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 |
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"
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
I was searching for some sample config in KB pool either VDOM or VRF method. Only one I could find so far was below.
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
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 |
---|---|
1502 | |
1013 | |
749 | |
443 | |
209 |
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.