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

Multiple IPsec tunnels with overlapping networks - VIP

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 postif 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?

4 REPLIES 4
spoojary
Staff
Staff
madis
New Contributor

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
Esteemed Contributor III

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
Esteemed Contributor III

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

Labels
Top Kudoed Authors