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

Site-to-Site IPsec between vSRX and Fortigate

Hello all, Please note that this is the first time I'm working on Fortinet equipment so my questions might be noob-ish, but here goes. I'm trying to set up a simple site-to-site route-based IKEv2 IPsec tunnel between a vSRX and a Fortigate. See attached.  I've tried to follow the instructions here for the Fortigate configuration.  https://kb.fortinet.com/kb/documentLink.do?externalID=FD34846

 

Please see here the configuration on the vSRX

root> show configuration | display set
set version 12.1X47-D15.4
set system root-authentication encrypted-password "$1$6QxV/3Ab$tscyfSySD37ZMjGtNL5rl/"
set interfaces ge-0/0/0 unit 0 family inet address 192.168.10.1/24
set interfaces lo0 unit 0 family inet address 1.1.1.2/32
set interfaces lo0 unit 0 family inet address 10.1.1.1/8
set interfaces st0 unit 0 family inet address 1.1.1.1/32
set routing-options static route 20.0.0.0/8 next-hop st0.0
set routing-options static route 2.2.2.2/32 next-hop 192.168.10.2
set security ike proposal ikp1 authentication-method pre-shared-keys
set security ike proposal ikp1 authentication-algorithm sha-256
set security ike proposal ikp1 encryption-algorithm des-cbc
set security ike policy ikpol mode main
set security ike policy ikpol proposals ikp1
set security ike policy ikpol pre-shared-key ascii-text "$9$tp7MpBEcSeMWxEhVwg4ZG"
set security ike gateway ikgw1 ike-policy ikpol
set security ike gateway ikgw1 address 192.168.10.2
set security ike gateway ikgw1 external-interface ge-0/0/0.0
set security ike gateway ikgw1 version v2-only
set security ipsec proposal ipsec_prop protocol esp
set security ipsec proposal ipsec_prop authentication-algorithm hmac-sha-256-128
set security ipsec proposal ipsec_prop encryption-algorithm des-cbc
set security ipsec policy ipsec_pol proposals ipsec_prop
set security ipsec vpn ipsec_vpn bind-interface st0.0
set security ipsec vpn ipsec_vpn ike gateway ikgw1
set security ipsec vpn ipsec_vpn ike ipsec-policy ipsec_pol
set security policies from-zone Untrust to-zone Untrust policy p1 match source-address any
set security policies from-zone Untrust to-zone Untrust policy p1 match destination-address any
set security policies from-zone Untrust to-zone Untrust policy p1 match application any
set security policies from-zone Untrust to-zone Untrust policy p1 then permit
set security policies from-zone junos-host to-zone Untrust policy p1 match source-address any
set security policies from-zone junos-host to-zone Untrust policy p1 match destination-address any
set security policies from-zone junos-host to-zone Untrust policy p1 match application any
set security policies from-zone junos-host to-zone Untrust policy p1 then permit
set security policies from-zone Untrust to-zone junos-host policy p1 match source-address any
set security policies from-zone Untrust to-zone junos-host policy p1 match destination-address any
set security policies from-zone Untrust to-zone junos-host policy p1 match application any
set security policies from-zone Untrust to-zone junos-host policy p1 then permit
set security zones security-zone Untrust host-inbound-traffic system-services ping
set security zones security-zone Untrust interfaces ge-0/0/0.0
set security zones security-zone Untrust interfaces st0.0
set security zones security-zone Untrust interfaces lo0.0

 

And here is the Fortinet side

FortiGate-VM64-KVM # show vpn ipsec phase1-interface
config vpn ipsec phase1-interface
    edit "tu1"
        set interface "port1"
        set ike-version 2
        set peertype any
        set proposal des-sha256
        set dhgrp 14
        set remote-gw 192.168.10.1
        set psksecret ENC MC09d120Jj+ofvCx0S3Swjb7kDLog23Hpd9EST2DSR++ozxsUUmHCRJ1nhyevMnIaL3IB3YLIQTsTUNscj6VcKdmysZnfixvoYY7Lr1er0e10Qu3GZTpLUzCgOW/4EqZXmmE2ZfslFIWYbgtDrGZI1BDyYafCxkRDaMmGcrWc9+7P8tTwH/+YpwrhCUOcGykYd7p+Q==
    next
end

FortiGate-VM64-KVM # show vpn ipsec phase2-interface
config vpn ipsec phase2-interface
    edit "tu2"
        set phase1name "tu1"
        set proposal des-sha256
        set dhgrp 15
    next
end
FortiGate-VM64-KVM # show router static
config router static
    edit 1
        set dst 1.0.0.0 255.0.0.0
        set gateway 192.168.10.1
        set device "port1"
    next
    edit 2
        set dst 10.0.0.0 255.0.0.0
        set device "tu1"
    next
end

FortiGate-VM64-KVM # show firewall policy 1
config firewall policy
    edit 1
        set name "test"
        set uuid ca801e6a-c8eb-51e9-e8fd-097d48d3f681
        set srcintf "any"
        set dstintf "any"
        set srcaddr "all"
        set dstaddr "all"
        set schedule "always"
        set service "ALL"
        set logtraffic disable
    next
end

FortiGate-VM64-KVM # get system status
Version: FortiGate-VM64-KVM v5.6.1,build1484,170727 (GA)
Virus-DB: 1.00123(2015-12-11 13:18)
Extended DB: 1.00000(2012-10-17 15:46)
IPS-DB: 6.00741(2015-12-01 02:30)
IPS-ETDB: 0.00000(2001-01-01 00:00)
APP-DB: 6.00741(2015-12-01 02:30)
INDUSTRIAL-DB: 6.00741(2015-12-01 02:30)
Serial-Number: FGVMEVB5IEWQCYAE
IPS Malicious URL Database: 1.00001(2015-01-01 01:01)
Botnet DB: 1.00000(2012-05-28 22:51)
License Status: Valid
Evaluation License Expires: Wed Sep 11 08:15:43 2019
VM Resources: 1 CPU/1 allowed, 995 MB RAM/1024 MB allowed
BIOS version: 04000002
Log hard disk: Not available
Hostname: FortiGate-VM64-KVM
Operation Mode: NAT
Current virtual domain: root
Max number of virtual domains: 1
Virtual domains status: 1 in NAT mode, 0 in TP mode
Virtual domain configuration: disable
FIPS-CC mode: disable
Current HA mode: standalone
Branch point: 1484
Release Version Information: GA
FortiOS x86-64: Yes
System time: Tue Aug 27 10:29:46 2019

FortiGate-VM64-KVM # get system interface
== [ port1 ]
name: port1 mode: static ip: 192.168.10.2 255.255.255.0 status: up netbios-forward: disable type: physical netflow-sampler: disable sflow-sampler: disable scan-botnet-connections: disable src-check: enable mtu-override: disable wccp: disable drop-overlapped-fragment: disable drop-fragment: disable
== [ ssl.root ]
name: ssl.root ip: 0.0.0.0 0.0.0.0 status: up netbios-forward: disable type: tunnel netflow-sampler: disable sflow-sampler: disable scan-botnet-connections: disable src-check: enable wccp: disable
== [ tu1 ]
name: tu1 ip: 2.2.2.2 255.255.255.255 status: up netbios-forward: disable type: tunnel netflow-sampler: disable sflow-sampler: disable scan-botnet-connections: disable src-check: enable wccp: disable


 

Basically I'm trying to set up and IPsec session between 1.1.1.1/32 on the SRX and 2.2.2.2/32 on the Fortinet. I want traffic going from 10.0.0.0/8 on Fortinet lo0 to be thrown via st0.0 and authenicated and encrypted. For some reason which escapes me, 2.2.2.2 is not reachable from the vSRX even though it is configured on the Fortinet. Ping from the directly connected interfaces works however. 

root> ping 2.2.2.2
PING 2.2.2.2 (2.2.2.2): 56 data bytes
^C
--- 2.2.2.2 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

root> ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2): 56 data bytes
64 bytes from 192.168.10.2: icmp_seq=0 ttl=255 time=4.200 ms
64 bytes from 192.168.10.2: icmp_seq=1 ttl=255 time=6.418 ms
^C
--- 192.168.10.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.200/5.309/6.418/1.109 ms

FortiGate-VM64-KVM # execute ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=64 time=6.5 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=3.2 ms
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.2/4.8/6.5 ms

FortiGate-VM64-KVM # execute ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
64 bytes from 192.168.10.1: icmp_seq=0 ttl=64 time=3.7 ms
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=2.8 ms
^C
--- 192.168.10.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 2.8/3.2/3.7 ms

Any help would be greatly appreciated. Also, please note that I'm mostly a networking i.e routing and switching type of engineer and have less experience with security products. Kind Regards, WhatNot

 

 

14 REPLIES 14
WhatNot

toshiesumi wrote:

I think the problem is still on the SRX side since pinging 1.1.1.1 from FGT side goes in the tunnel (because you configured "remote-ip" properly on the tu1 interface. You should see the /32 route into the tu1 if you do "get router info routing-t all".) and coming back from SRX through the tunnel. You can try sniff ping traffic at least on the FGT side with "diag sniffer packet <interface_name, like tu1, port1> 'host 1.1.1.1'" while you're pinging. Depending on your type of FGT, you probably need to disable asic offloading on the in/out policy through the tunnel to see all packets in sniffing; "set auto-asic-offload disable". Don't forget re-enable it after debugging is done.

I remember SRX didn't let PCAP run on a tunnel interface in the past. It might have changed by now though.

 

Both FGT and SRX are using interface-base IPsec, not policy-base IPsec, you need to route traffic for the other end to the tunnel interface (tu1, st0.0) instead of the GW interfaces to bring up the tunnel. Same applies to Cisco between "VTI" (interface-base) vs. "crypto map" (policy-base).

 

By the way, based on your tunnel interface config, I see you're running 5.4 or older version on the FGT. I recommend you bring up to at least the latest 5.6, or latest 6.0. There were many vulnerabilities fixed inbetween.

I think the problem is on the Fortigate. The ping towards 1.1.1.1/32 doesn't go through the tunnel, it goes through the static route to 1.0.0.0/8 I added. 

 

FortiGate-VM64-KVM # get router info routing-t all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default

S 1.0.0.0/8 [10/0] via 192.168.10.1, port1
C 192.168.10.0/24 is directly connected, port1


FortiGate-VM64-KVM #

 

Even though the tu1 interface is configured. 

FortiGate-VM64-KVM # show system interface tu1
config system interface
    edit "tu1"
        set vdom "root"
        set ip 2.2.2.2 255.255.255.255
        set allowaccess ping
        set type tunnel
        set remote-ip 1.1.1.1
        set snmp-index 3
        set interface "port1"
    next
end

Can you take a second look at the FGT config. This is the first time I've configured a Fortinet device of any kind and there's a high probability of my making a mistake.

emnoc
Esteemed Contributor III

msg="iprope_in_check() check failed on policy 1, drop" that's due to  icmp and no revelant 

proto=1, 192.168.10.1:46084->2.2.2.2:2048


Ken Felix

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
WhatNot
New Contributor

emnoc wrote:
msg="iprope_in_check() check failed on policy 1, drop" that's due to icmp and no revelant 

proto=1, 192.168.10.1:46084->2.2.2.2:2048


Ken Felix

FortiGate-VM64-KVM # show firewall policy
config firewall policy
    edit 1
        set name "test"
        set uuid ca801e6a-c8eb-51e9-e8fd-097d48d3f681
        set srcintf "any"
        set dstintf "any"
        set srcaddr "all"
        set dstaddr "all"
        set schedule "always"
        set service "ALL"
        set logtraffic disable
    next
end
 

 

Edit: My bad. After set action accept ping from SRX to 2.2.2.2 comes up.

However, the IPsec Phase1/Phase2 SA's still are not established.

emnoc
Esteemed Contributor III

2.2.2.2 is the fortigate , that fwpolicy1 has no bearing on traffic  generate to  a ADDRESS bound on a interface of the firewall.

 

these control traffic to ip.address on the FGT directly

[ul]
  • Local-in policy 
  • allow access options
  • and trust-hosts[/ul]

     

    fwiw..... I would start by looking at that and placing st.0 and tu1 interfaces in the same subnet for testing across the <vpn path> before testing local-2-remote subnets.

     

    The.src 192.168.10.1 is NOT a vSRX nor the 1.1.1.1 of the tunnel st.0 interface and if it's not part of the trust-host or is blocked by a local-in, than I would expect it to be dropped by the FortiOS.

     

    Ken Felix

     

  • PCNSE 

    NSE 

    StrongSwan  

    PCNSE NSE StrongSwan
    smari
    New Contributor

    Ken Felix is right,

     

    You can do a :

    diagnose debug application ike -1 

    on the FGT to debug the p2 problem you have

    NSE7, FMG, FAC, FAZ .

    1500D's, 1200D's, 900D's, 300D's, 200D's, 100D's and bunch of small stuff.

     

    NSE7, FMG, FAC, FAZ . 1500D's, 1200D's, 900D's, 300D's, 200D's, 100D's and bunch of small stuff.
    Labels
    Top Kudoed Authors