Site-to-Site IPsec between vSRX and Fortigate

[WhatNot]

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

[emnoc]

Not sure what your doing for src/dst subnets but this make me  believe here lies a few issues

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


The phase2 proxy-id wold be 0.0.0.0/0:0 ( aka quad  zeros ) for SRX and FGT. Here's a  SRX site2site tunnels cfg

Here's a sample rt-based srx-2-fgt that you can use as a guide.

http://socpuppet.blogspot.com/2013/09/vpn-ikev2-juniper-to-fortigate-routevpn.html

[Toshi_Esumi]

What did you configured under "config sys int" then edit "tu1", especially "set remote-ip"? It supposed to have 1.1.1.1/32 so that traffic between 2.2.2.2 and 1.1.1.1 goes over the tunnel. It automatically inject the /32 route into the routing table toward "tu1". I think it's currently goes outside of the tunnel by following 1.0.0.0/8 static route to port1. It shouldn't be there.

I don't have much experience with SRX but the next hop for 2.2.2.2 should be st0.0 instead of 192.168.10.2, which goes outside the tunnel to ge-0/0/0.0

[WhatNot]

toshiesumi wrote:

What did you configured under "config sys int" then edit "tu1", especially "set remote-ip"? It supposed to have 1.1.1.1/32 so that traffic between 2.2.2.2 and 1.1.1.1 goes over the tunnel. It automatically inject the /32 route into the routing table toward "tu1". I think it's currently goes outside of the tunnel by following 1.0.0.0/8 static route to port1. It shouldn't be there.

I don't have much experience with SRX but the next hop for 2.2.2.2 should be st0.0 instead of 192.168.10.2, which goes outside the tunnel to ge-0/0/0.0

I'm unfamiliar with the fortinet configuration. I added a static route for 1.0.0.0/8 with 192.168.10.1 as the next hop and port1 as the outside interface ( at least that's what I think it does). This seems natural to me as port1 is the outside interface for the IKE/IPsec SA.

FortiGate-VM64-KVM # show system interface
config system interface
    edit "port1"
        set vdom "root"
        set ip 192.168.10.2 255.255.255.0
        set allowaccess ping https ssh http fgfm
        set type physical
        set snmp-index 1
    next
    edit "ssl.root"
        set vdom "root"
        set type tunnel
        set alias "SSL VPN interface"
        set snmp-index 2
    next
    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
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

[WhatNot]

Also, as I've said, the FGT can ping 1.1.1.1 (the SRX st0.0 ip address) and its 2.2.2.2 tu1 interface address. The SRX cannot reach the 2.2.2.2 even though it has a route to it. 

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=4.3 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=3.2 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=3.2 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=3.5 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=64 time=4.2 ms

--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 3.2/3.6/4.3 ms

FortiGate-VM64-KVM # execute ping 2.2.2.2
PING 2.2.2.2 (2.2.2.2): 56 data bytes
64 bytes from 2.2.2.2: icmp_seq=0 ttl=255 time=0.0 ms
64 bytes from 2.2.2.2: icmp_seq=1 ttl=255 time=0.0 ms
64 bytes from 2.2.2.2: icmp_seq=2 ttl=255 time=0.0 ms
64 bytes from 2.2.2.2: icmp_seq=3 ttl=255 time=0.0 ms
64 bytes from 2.2.2.2: icmp_seq=4 ttl=255 time=0.0 ms

--- 2.2.2.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

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 ---
4 packets transmitted, 0 packets received, 100% packet loss

root> ping 2.2.2.2 source 1.1.1.1
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>

[smari]

do you by any chance have trusted hosts configured for the admin account on the fortigate ?

do a flow trace on the fortigate site to see the packet flowing in, and then do a ping from the srx with the debug running :

diagnose debug enable

diagnose debug  flow show function-name enable

diagnose debug  flow filter daddr 2.2.2.2

diagnose debug  flow trace start 20

then post the output

[Toshi_Esumi]

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.

[emnoc]

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

Yes you can paacket capture in fact he should do that on both sides of the tunnel. Also I would use a  common subnet in the FortiOS<>SJunOS and on the FGT tunnel interface you set the mask.

FGT

edit "tu1"
        set vdom "root"
        set ip 2.2.2.2 255.255.255.255
        set allowaccess ping
        set type tunnel
        set remote-ip 2.2.2.1/30
        set snmp-index 3
        set interface "port1"
    next
end


SRX

set interfaces st0 unit 0 family inet address  2.2.2.1/30

set routing-options static route x.x.x.x/xxx  next-hop 2.2.2.2

# place the route to  the  FGT local-subnets as required for the route-based VPN. The earlier provide blog post shows a typical route based vpn for fgt-2-srx and it works


This way the tunnel networks would be common between the two. As soon as the ph1/ph2 completes the networks would be presented in the respective device RIB.

Ken Felix

[WhatNot]

The packets are being sent by the SRX. However, they are being denied on the Fortinet. Which is strange, considering I already made an allow-all policy.

FortiGate-VM64-KVM # id=20085 trace_id=17 func=print_pkt_detail line=5363 msg="vd-root received a packet(proto=1, 192.168.10.1:46084->2.2.2.2:2048) from port1. type=8, code=0, id=46084, seq=70."
id=20085 trace_id=17 func=init_ip_session_common line=5519 msg="allocate a new session-00000048"
id=20085 trace_id=17 func=vf_ip_route_input_common line=2583 msg="find a route: flag=84000000 gw-2.2.2.2 via root"
id=20085 trace_id=17 func=fw_local_in_handler line=397 msg="iprope_in_check() check failed on policy 1, drop"
id=20085 trace_id=18 func=print_pkt_detail line=5363 msg="vd-root received a packet(proto=1, 192.168.10.1:46084->2.2.2.2:2048) from port1. type=8, code=0, id=46084, seq=71."
id=20085 trace_id=18 func=init_ip_session_common line=5519 msg="allocate a new session-00000049"
id=20085 trace_id=18 func=vf_ip_route_input_common line=2583 msg="find a route: flag=84000000 gw-2.2.2.2 via root"
id=20085 trace_id=18 func=fw_local_in_handler line=397 msg="iprope_in_check() check failed on policy 1, drop"
id=20085 trace_id=19 func=print_pkt_detail line=5363 msg="vd-root received a packet(proto=1, 192.168.10.1:46084->2.2.2.2:2048) from port1. type=8, code=0, id=46084, seq=72."
id=20085 trace_id=19 func=init_ip_session_common line=5519 msg="allocate a new session-0000004a"
id=20085 trace_id=19 func=vf_ip_route_input_common line=2583 msg="find a route: flag=84000000 gw-2.2.2.2 via root"
id=20085 trace_id=19 func=fw_local_in_handler line=397 msg="iprope_in_check() check failed on policy 1, drop"
id=20085 trace_id=20 func=print_pkt_detail line=5363 msg="vd-root received a packet(proto=1, 192.168.10.1:46084->2.2.2.2:2048) from port1. type=8, code=0, id=46084, seq=73."
id=20085 trace_id=20 func=init_ip_session_common line=5519 msg="allocate a new session-0000004b"
id=20085 trace_id=20 func=vf_ip_route_input_common line=2583 msg="find a route: flag=84000000 gw-2.2.2.2 via root"
id=20085 trace_id=20 func=fw_local_in_handler line=397 msg="iprope_in_check() check failed on policy 1, drop"

FortiGate-VM64-KVM #
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

[WhatNot]

emnoc wrote:

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

Yes you can paacket capture in fact he should do that on both sides of the tunnel. Also I would use a  common subnet in the FortiOS<>SJunOS and on the FGT tunnel interface you set the mask.

FGT

edit "tu1"
        set vdom "root"
        set ip 2.2.2.2 255.255.255.255
        set allowaccess ping
        set type tunnel
        set remote-ip 2.2.2.1/30
        set snmp-index 3
        set interface "port1"
    next
end


SRX

set interfaces st0 unit 0 family inet address 2.2.2.1/30

set routing-options static route x.x.x.x/xxx next-hop 2.2.2.2

# place the route to the FGT local-subnets as required for the route-based VPN. The earlier provide blog post shows a typical route based vpn for fgt-2-srx and it works


This way the tunnel networks would be common between the two. As soon as the ph1/ph2 completes the networks would be presented in the respective device RIB.

Ken Felix

Is this a requirement on Fortinets ? I know for a fact that on SRX IPsec and Cisco GRE (plain, no IPsec) there is no requirement for the tunnel interfaces to have IP addresses in the same subnet. This would seem like an odd requirement.