Hot!Configure policy routes for route-based (interface-based) IPsec VPNs

Author
Cleyton Agenil da Silva
New Member
  • Total Posts : 12
  • Scores: 0
  • Reward points: 0
  • Joined: 2020/06/18 11:35:24
  • Status: offline
2020/11/24 09:00:36 (permalink)
0

Configure policy routes for route-based (interface-based) IPsec VPNs

Dear
I have the following scenario.
I have a VPN connection between two FG boxes.
The FG 80E HQ box is configured as follows:
 
FG 80E HQ
WAN -> 200.168.147.99/29
VPN-HQ -> 10.1.1.1/32
Remote IP / Mask -> 10.1.1.2/255.255.255.252
LAN -> 192.168.254.99/24
 
FG 50E Branch
WAN -> 177.127.147.230/29
VPN-BRANCH -> 10.1.1.2
Remote IP / Mask -> 10.1.1.1
LAN -> 192.168.247.99/24
 
I configured a route-based policy so that the VPN interface on the FG 80E HQ can obtain subnet access 192.168.247.0/24 and the FG 50E Branch has subnet access 192.168.254.0/24.
However I used this tutorial https://kb.fortinet.com/k....do?externalID=FD38790 to configure access, but it didn't work.
Could someone help me?
#1

9 Replies Related Threads

    Toshi Esumi
    Expert Member
    • Total Posts : 2403
    • Scores: 233
    • Reward points: 0
    • Joined: 2014/11/06 09:56:42
    • Status: offline
    Re: Configure policy routes for route-based (interface-based) IPsec VPNs 2020/11/24 09:15:03 (permalink)
    0
    To use a policy route, you still need to have a proper route into the tunnel, which is not described in the KB. Do you have a route for the subnet on the opposite end.
    Besides, I don't see any particular reason you need to configure a policy route as described in KB. I even want to know why this KB is posted. Because you still need to have a set of policies for both directions and in the policies you can control what sourc/destination combinations are allowed to go/come across. Then further, once you start dealing with multiple VPNs and failovers, you easily get in trouble with the policy route.
    #2
    emnoc
    Expert Member
    • Total Posts : 5919
    • Scores: 394
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    Re: Configure policy routes for route-based (interface-based) IPsec VPNs 2020/11/24 10:02:28 (permalink)
    0
    I think we should take a step back and identify what is NOT working? 
     
    Ken Felix
     

    PCNSE 
    NSE 
    StrongSwan  
    #3
    ede_pfau
    Expert Member
    • Total Posts : 6411
    • Scores: 551
    • Reward points: 0
    • Joined: 2004/03/09 01:20:18
    • Location: Heidelberg, Germany
    • Status: offline
    Re: Configure policy routes for route-based (interface-based) IPsec VPNs 2020/11/25 04:30:06 (permalink)
    0
    As posted, you do not need a policy route at all, hence no local and remote IPs on the tunnel interfaces (but they don't harm either).
    Post your routing table and the policy itself and we'll see if anything is misconfigured.

    Ede

    " Kernel panic: Aiee, killing interrupt handler!"
    #4
    Cleyton Agenil da Silva
    New Member
    • Total Posts : 12
    • Scores: 0
    • Reward points: 0
    • Joined: 2020/06/18 11:35:24
    • Status: offline
    Re: Configure policy routes for route-based (interface-based) IPsec VPNs 2020/11/25 04:39:37 (permalink)
    0
    Thanks for the answer
    The reason for configuring a policy route as described in KB, would be my problem with the DNS server behind the FG 80E HQ.
    As I said in the post, I have FG HQ 80E and a FG Branch 50E with VPN connection, the stations that are behind the FG can access the DNS, but the boxes do not ping in CLI mode.
    See scenario below:
    FG 80E HQ
    WAN -> 200.168.147.99/29
    VPN-HQ -> 10.1.1.1/32
    IP / Remote Mask -> 10.1.1.2/255.255.255.252
    LAN -> 192.168.254.99 / 24
    DNS Windows -> 192.168.254.100

    FG 50E Branch
    WAN -> 177.127.147.230/29
    VPN-BRANCH -> 10.1.1.2
    IP / Remote Mask -> 10.1.1.1
    LAN 192.168.247.99/24
    DNS Windows HQ -> 192.168.254.100
    When I specify DNS windows in the FG Branch option, as shown in the image attached in this post, an error message appears.
    DNS server behind FG HQ
    192.168.254.100 Unreachable
    This problem occurs when pinging the DNS server using the CLI command in the FG 50E box.
    As the image attached in this post
    post edited by Cleyton Agenil da Silva - 2020/11/25 04:46:34

    Attached Image(s)

    #5
    emnoc
    Expert Member
    • Total Posts : 5919
    • Scores: 394
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    Re: Configure policy routes for route-based (interface-based) IPsec VPNs 2020/11/25 07:14:42 (permalink)
    0
    So what I would do is set a interface address on both the vpn-interface and ensure that hq and branch FGT negotiate a phase2 for that  subnet and your ping will work along as the remote-firewall has a policy allowing that ping to the machine behind on  the law.
     
    You will need routes install to allow the HQ to Branch and Branch to HQ for  whatever tunnel interface addresses that you assign. Use a combination of "diag sniffer packet <phase1-interface-name> "host x.x.x.x and proto 1" to witness the ping and on the remote firewall "diag debug flow filter"  with the correct filters to witness the ping and the policy action that is taken.
     
    This is trivial to setup and pbr is not required.
     
    Ken Felix
     
     
     

    PCNSE 
    NSE 
    StrongSwan  
    #6
    ede_pfau
    Expert Member
    • Total Posts : 6411
    • Scores: 551
    • Reward points: 0
    • Joined: 2004/03/09 01:20:18
    • Location: Heidelberg, Germany
    • Status: offline
    Re: Configure policy routes for route-based (interface-based) IPsec VPNs 2020/11/25 07:28:03 (permalink)
    0
    May I translate emnoc's advice "and pbr is not required" = pbr/policy based route.
     
    Please note that pinging from the FGT's CLI can sometimes fail because the originating address is not the one you expect. Ping from a host on the LAN to see if your routing is correct.
    You do neither need policy routes, nor tunnel and remote IP addresses. Before further testing, delete at least the PBR.
     
    And again, if you would post ALL relevant information we could have solved your problem long ago.

    Ede

    " Kernel panic: Aiee, killing interrupt handler!"
    #7
    Cleyton Agenil da Silva
    New Member
    • Total Posts : 12
    • Scores: 0
    • Reward points: 0
    • Joined: 2020/06/18 11:35:24
    • Status: offline
    Re: Configure policy routes for route-based (interface-based) IPsec VPNs 2020/11/25 11:55:28 (permalink)
    0
    Dear ede_pfau and emnoc
    Thank you for your help.
    My intention to create Policy Based on route - pbr, would be to solve problem with access to the windows DNS server through the "DNS Settings" in the FG console, I don't know if this is the best option to solve the problem, since the address pattern VPN interface 0.0.0.0 IP / Remote 0.0.0.0/0.0.0.0
     
    FG 50E Branch

    Branch # ping 10.1.1.1 -> VPN Interface IP / Remote HQ
    PING 10.1.1.1 (10.1.1.1): 56 data bytes
    64 bytes from 10.1.1.1: icmp_seq = 0 ttl = 255 time = 27.0 ms
    64 bytes from 10.1.1.1: icmp_seq = 1 ttl = 255 time = 25.8 ms
    64 bytes from 10.1.1.1: icmp_seq = 2 ttl = 255 time = 26.1 ms
    64 bytes from 10.1.1.1: icmp_seq = 3 ttl = 255 time = 26.1 ms
    64 bytes from 10.1.1.1: icmp_seq = 4 ttl = 255 time = 26.1 ms
    --- 10.1.1.1 ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min / avg / max = 25.8 / 26.2 / 27.0 ms
    Branch # ping 192.168.247.99 -> LAN Branch Interface
    PING 192.168.247.99 (192.168.247.99): 56 data bytes
    64 bytes from 192.168.247.99: icmp_seq = 0 ttl = 255 time = 0.1 ms
    64 bytes from 192.168.247.99: icmp_seq = 1 ttl = 255 time = 0.1 ms
    64 bytes from 192.168.247.99: icmp_seq = 2 ttl = 255 time = 0.1 ms
    64 bytes from 192.168.247.99: icmp_seq = 3 ttl = 255 time = 0.1 ms
    64 bytes from 192.168.247.99: icmp_seq = 4 ttl = 255 time = 0.1 ms
    --- 192.168.247.99 ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min / avg / max = 0.1 / 0.1 / 0.1 ms
    Branch # ping 192.168.254.99 -> HQ LAN interface
    PING 192.168.254.99 (192.168.254.99): 56 data bytes
    --- 192.168.254.99 ping statistics ---
    5 packets transmitted, 0 packets received, 100% packet loss
     
    IPSEC PHASE1-INTERFACE VPN
     
    BRANCH (phase1-interface) # show
    config vpn ipsec phase1-interface
    edit "VPN-BRANCH"
    set interface "wan1"
    set local-gw XXX.XXX.XXX.XXX
    set peertype any
    set net-device disable
    set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
    set remote-gw XXX.XXX.XXX.XXX
    set psksecret ENC TQjyRi4nEWBfFVy5 / NSwjDh4BJxJ9mKQbaMjv9IX2xlaIgspZaxYvhu8xhgavi4WA2njHxsQFfu3ukSJkAMoT / Rvpvur67F4H9JZY2Q3QQQQQQQQQQQQQQQQQQQQQQQQQQQQQVMZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ)
    next
    end
    IPSEC PHASE2-INTERFACE VPN

    Branch (phase2-interface) # show
    config vpn ipsec phase2-interface
    edit "VPN-BRANCH"
    set phase1name "VPN-BRANCH-HQ"
    set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305
    set auto-negotiate enable
    set src-addr-type name
    set dst-addr-type name
    set src-name "192.168.247.0/24"
    set dst-name "192.168.254.0/24"
    next
    edit "VPN-BRANCH"
    set phase1name "VPN-BRANCH-HQ-DNS"
    set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305
    set auto-negotiate enable
    set src-addr-type name
    set dst-addr-type name
    set src-name "10.1.1.2/32"
    set dst-name "10.1.1.1/32"
    next
    end
    Route Static
    BRANCH (4) # get
    seq-num: 4
    status: enable
    dst: 0.0.0.0 0.0.0.0
    distance: 1
    weight: 0
    priority: 0
    device: VPN-BRANCH
    comment:
    blackhole: disable
    dynamic-gateway: disable
    dstaddr: 10.1.1.1/32
    link-monitor-example: disable
    bfd: disable
    ------------------------------------------------- / / ------------------------------------------------- -
    FG 80E HQ
    HQ # ping 10.1.1.2 IP VPN / Remote Branch interface
    PING 10.1.1.2 (10.1.1.2): 56 data bytes
    64 bytes from 10.1.1.2: icmp_seq = 0 ttl = 255 time = 26.5 ms
    64 bytes from 10.1.1.2: icmp_seq = 1 ttl = 255 time = 26.3 ms
    64 bytes from 10.1.1.2: icmp_seq = 2 ttl = 255 time = 26.3 ms
    64 bytes from 10.1.1.2: icmp_seq = 3 ttl = 255 time = 26.2 ms
    64 bytes from 10.1.1.2: icmp_seq = 4 ttl = 255 time = 25.1 ms
    --- 10.1.1.2 ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min / avg / max = 25.1 / 26.0 / 26.5 ms
    HQ # ping 192.168.254.99 HQ LAN interface
    PING 192.168.254.99 (192.168.254.99): 56 data bytes
    64 bytes from 192.168.254.99: icmp_seq = 0 ttl = 255 time = 0.1 ms
    64 bytes from 192.168.254.99: icmp_seq = 1 ttl = 255 time = 0.1 ms
    64 bytes from 192.168.254.99: icmp_seq = 2 ttl = 255 time = 0.1 ms
    64 bytes from 192.168.254.99: icmp_seq = 3 ttl = 255 time = 0.1 ms
    64 bytes from 192.168.254.99: icmp_seq = 4 ttl = 255 time = 0.1 ms
    --- 192.168.254.99 ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min / avg / max = 0.1 / 0.1 / 0.1 ms
    HQ # ping 192.168.247.99 LAN Branch Interface
    PING 192.168.247.99 (192.168.247.99): 56 data bytes
    --- 192.168.247.99 ping statistics ---
    5 packets transmitted, 0 packets received, 100% packet loss
     
    IPSEC PHASE1-INTERFACE VPN
     
    HQ (VPN-HQ) # show
    config vpn ipsec phase1-interface
    edit "VPN-HQ-BRANCH"
    set interface "wan1"
    set peertype any
    set net-device disable
    set proposal aes128-sha256 aes256-sha2
    set remote-gw XXX.XXX.XXX.XXX
    set psksecret ENC hKxNBj3XkvergUONCEoAebupp2zdo8R / 28QI0KyJn6CzoHwhf1T7Zt3VfS3sni7cW98giDScEaaZ61zbW7RTXIpiPK3hVXWHdcFZ + / PiDkY
    end
     
    IPSEC PHASE2-INTERFACE VPN
    HQ (VPN-HQ) # show
    config vpn ipsec phase2-interface
    edit "VPN-HQ-BRANCH"
    set phase1name "VPN-HQ-BRANCH"
    set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305
    set auto-negotiate enable
    set src-addr-type name
    set dst-addr-type name
    set src-name "all"
    set dst-name "10.1.1.2/32
    next
    end
     
    Route Static
    HQ (28) # get
    seq-num: 28
    status: enable
    dst: 0.0.0.0 0.0.0.0
    distance: 10
    weight: 0
    priority: 0
    device: VPN-HQ
    comment:
    blackhole: disable
    dynamic-gateway: disable
    dstaddr: 10.1.1.2/32
    link-monitor-example: disable
    bfd: disable
    #8
    emnoc
    Expert Member
    • Total Posts : 5919
    • Scores: 394
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    Re: Configure policy routes for route-based (interface-based) IPsec VPNs 2020/11/25 14:26:06 (permalink)
    0
    Okat bravo if I can make some recommendation 
     
    On the remote firewall your phase2 needs to have this added on FG80
     
     
    edit "VPN-HQ-BRANCH"2"
    set phase1name "VPN-HQ-BRANCH"
    set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305
    set auto-negotiate enable
    set src-addr-type name
    set dst-addr-type name
    set src-name "192.168.254.0/24"
    set dst-name "192.168.257.0/24"
    next
    end
     
    You will also needs policyes on both firewall to  allow the 1.1.1.0s address
     
    e.g 
     
    config firewall address
       edit 10.1.1.0-24
          set subnet 10.1.1.0/24
       end
     
    config firewall policy
    edit 0
    set name "allow_vpn_interfaces"
     
    set srcintf "VPN-BRANCH"
    set dstintf "VPN-BRANCH"
    set srcaddr "10.1.1.0-24"
    set dstaddr "10.1.1.0-24"
    set action accept
    set schedule "always"
    set service "PING"
    next
    end
     
    Make sure the policy is high up in the seq#. I believe if you fix the phase2-config, apply a policy 10.1.1.x can ping the lan behind the remote fgt over the ipsec-interface.
     
     
    For future reference when providing the cfg just do a "show" and not a "get" . The output is much easier to read imho 
     
    e.g  demostration of get and show with a firewall policy
     
     
    brooklyn-south (13) # get
    policyid : 13
    status : enable
    name : QUIC-BROWSERS
    uuid : d07a8548-0360-51eb-f755-ab46572a1f7f
    srcintf : "lan"
    dstintf : "wan1" "upg-zone-wan2"
    srcaddr : "LAN"
    dstaddr : "all"
    srcaddr6 :
    dstaddr6 :
    internet-service : disable
    internet-service-src: disable
    reputation-minimum : 0
    src-vendor-mac :
    rtp-nat : disable
    action : accept
    schedule : always
    schedule-timeout : disable
    service : "QUIC"
    tos-mask : 0x00
    anti-replay : enable
    utm-status : disable
    inspection-mode : flow
    profile-protocol-options: default
    ssl-ssh-profile : no-inspection
    logtraffic : utm
    logtraffic-start : disable
    auto-asic-offload : enable
    np-acceleration : enable
    permit-any-host : disable
    permit-stun-host : disable
    fixedport : disable
    ippool : disable
    session-ttl : 0
    vlan-cos-fwd : 255
    vlan-cos-rev : 255
    wccp : disable
    groups :
    users :
    fsso-groups :
    disclaimer : disable
    email-collect : disable
    natip : 0.0.0.0 0.0.0.0
    diffserv-forward : disable
    diffserv-reverse : disable
    tcp-mss-sender : 0
    tcp-mss-receiver : 0
    comments :
    block-notification : disable
    custom-log-fields :
    replacemsg-override-group:
    srcaddr-negate : disable
    dstaddr-negate : disable
    service-negate : disable
    timeout-send-rst : disable
    captive-portal-exempt: disable
    dsri : disable
    radius-mac-auth-bypass: disable
    delay-tcp-npu-session: disable
    vlan-filter :
    traffic-shaper :
    traffic-shaper-reverse:
    per-ip-shaper :
    nat : enable
     
     
    brooklyn-south (13) # show
    config firewall policy
    edit 13
    set name "QUIC-BROWSERS"
    set uuid d07a8548-0360-51eb-f755-ab46572a1f7f
    set srcintf "lan"
    set dstintf "wan1" "upg-zone-wan2"
    set srcaddr "LAN"
    set dstaddr "all"
    set action accept
    set schedule "always"
    set service "QUIC"
    set nat enable
    next
    end
     
    The latter is much easier to read and to follow , imho for just reviewing the cfg. 
     
    Ken Felix
     
     
     
     
    post edited by emnoc - 2020/11/25 14:27:38

    PCNSE 
    NSE 
    StrongSwan  
    #9
    Cleyton Agenil da Silva
    New Member
    • Total Posts : 12
    • Scores: 0
    • Reward points: 0
    • Joined: 2020/06/18 11:35:24
    • Status: offline
    Re: Configure policy routes for route-based (interface-based) IPsec VPNs 2020/11/26 12:48:09 (permalink)
    0
    Hello emnoc

    Include the options indicated, but did not work, pinging the CLI for DNS windows inside FG 50E Branch box does not respond.
    Ping command behind FG 50E Branch at stations works perfectly.

    Attached Image(s)

    #10
    Jump to:
    © 2021 APG vNext Commercial Version 5.5