Fortigate on AWS - Site to Site VPN

[calvarado]

Hi,

We have deployed a Fortigate NGFW instance on AWS, we need to achieve a Site to Site connection to a customers Fortigate 600c to access an database server.

We successfully created the Site to Site Tunnel, using their instructions, Phase 1 and Phase 2 are up, but we are not able to reach out the target machine on their network.

We created the following on our side:

1) Static route with target network where the machine is located, that must go through the VPN tunnel, with administrative distance of 2. The default route has an administrative distance of 10.

2) Firewall rules (cloned reverse) that allow traffic from our network (10.0.1.0/24) to their network.

3) Our AWS security group allows traffic for ESP (50), as well as UDP 500 and 4500, all outbound traffic is allowed.

What else can we be missing? We tried pinging from the Fortigate itself after the tunnel with exec ping-options source 10.0.1.41 and after that trying out to ping the destination with no results.

Edit note: corrected IP to 10.0.1.41

[syadav]

Try running a sniffer for the ICMP traffic on both Fortigates and see if the traffic is making it to the other side or not.
diag sniffer packet any "host 10.0.0.41 and icmp" 4 0 l

[calvarado]

I tried to run the commands, sadly we only have control over one of the fortigates. When running it to reach the local host (10.0.1.41), ping does not reach that machine.

PING 10.0.1.41 (10.0.1.41): 56 data bytes

--- 10.0.1.41 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

A2G-Fortigate # diag sniffer packet any "host 10.0.1.41 and icmp" 4 0 l
Using Original Sniffing Mode
interfaces=[any]
filters=[host 10.0.1.41 and icmp]
2022-01-09 20:32:41.800204 port2 out 10.0.1.147 -> 10.0.1.41: icmp: echo request
2022-01-09 20:32:42.800129 port2 out 10.0.1.147 -> 10.0.1.41: icmp: echo request
2022-01-09 20:32:43.800234 port2 out 10.0.1.147 -> 10.0.1.41: icmp: echo request
2022-01-09 20:32:44.800338 port2 out 10.0.1.147 -> 10.0.1.41: icmp: echo request
2022-01-09 20:32:45.800450 port2 out 10.0.1.147 -> 10.0.1.41: icmp: echo request

The machine itself is a VM that is on the same subnetwork as the Fortigate Interface 2 (Private network 10.0.1.0/24). The EC2 instance on 10.0.1.41 can ping the fortigate on 10.0.0.59 (public interface) and 10.0.1.147 (private interface facing the private subnetwork).

Just to give more info, our architecture is the following.

X.X.X.X/22 --- Customer Fortigate Y.Y.Y.Y --- WAN --- AWS Fortigate --- 10.0.1.0/24

[calvarado]

Ok so to provide more information, we fixed the ping between the Fortigate Instance and the EC2 instance, it was a missing firewall rule on the AWS administration page.

We are trying to understand why we can't get to ping the destination machine from the Fortigate:

Using Original Sniffing Mode
interfaces=[any]
filters=[host 10.Z.Y.X]
2022-01-09 21:28:45.976608 VPN out 10.0.1.41 -> 10.Z.Y.X: icmp: echo request
2022-01-09 21:28:46.976708 VPN out 10.0.1.41 -> 10.Z.Y.X: icmp: echo request
2022-01-09 21:28:47.976806 VPN out 10.0.1.41 -> 10.Z.Y.X: icmp: echo request
2022-01-09 21:28:48.976926 VPN out 10.0.1.41 -> 10.Z.Y.X: icmp: echo request

[syadav]

Looks like the traffic is going out via the VPN tunnel, You might wanna look at the remote FortiGate.
Check the reverse route and firewall policy, Try to take the flow trace debugs on the remote side.

diag deb flow filter addr x.x.x.x  <-- ip you are pinging

diag deb flow filter proto 1

diag deb flow trace start 999

diag deb enable

[calvarado]

Hi,

We ran the diag deb flow on our end for now, this is the output that we are getting (destination IP is masked)

2022-01-09 22:20:42 id=20085 trace_id=1001 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 10.0.1.41:1->X.Y.W.Z:2048) from port2. type=8, code=0, id=1, seq=31326."
2022-01-09 22:20:42 id=20085 trace_id=1001 func=init_ip_session_common line=5955 msg="allocate a new session-0000fe65"
2022-01-09 22:20:42 id=20085 trace_id=1001 func=vf_ip_route_input_common line=2605 msg="find a route: flag=04000000 gw-A.B.C.D via VPN"
2022-01-09 22:20:42 id=20085 trace_id=1001 func=fw_forward_handler line=869 msg="Allowed by Policy-1:"
2022-01-09 22:20:42 id=20085 trace_id=1001 func=ipsecdev_hard_start_xmit line=625 msg="enter IPSec interface VPN"
2022-01-09 22:20:42 id=20085 trace_id=1001 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel VPN"
2022-01-09 22:20:42 id=20085 trace_id=1001 func=esp_output4 line=867 msg="IPsec encrypt/auth"
2022-01-09 22:20:42 id=20085 trace_id=1001 func=ipsec_output_finish line=546 msg="send to 10.0.0.1 via intf-port1"
2022-01-09 22:20:46 id=20085 trace_id=1002 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 10.0.1.41:1->X.Y.W.Z:2048) from port2. type=8, code=0, id=1, seq=31327."
2022-01-09 22:20:46 id=20085 trace_id=1002 func=resolve_ip_tuple_fast line=5864 msg="Find an existing session, id-0000fe65, original direction"
2022-01-09 22:20:46 id=20085 trace_id=1002 func=npu_handle_session44 line=1161 msg="Trying to offloading session from port2 to VPN, skb.npu_flag=00000400 ses.state=00010204 ses.npu_state=0x00000000"
2022-01-09 22:20:46 id=20085 trace_id=1002 func=fw_forward_dirty_handler line=396 msg="state=00010204, state2=00000001, npu_state=00000000"
2022-01-09 22:20:46 id=20085 trace_id=1002 func=ipsecdev_hard_start_xmit line=625 msg="enter IPSec interface VPN"
2022-01-09 22:20:46 id=20085 trace_id=1002 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel VPN"
2022-01-09 22:20:46 id=20085 trace_id=1002 func=esp_output4 line=867 msg="IPsec encrypt/auth"
2022-01-09 22:20:46 id=20085 trace_id=1002 func=ipsec_output_finish line=546 msg="send to 10.0.0.1 via intf-port1"
2022-01-09 22:20:51 id=20085 trace_id=1003 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 10.0.1.41:1->X.Y.W.Z:2048) from port2. type=8, code=0, id=1, seq=31328."
2022-01-09 22:20:51 id=20085 trace_id=1003 func=resolve_ip_tuple_fast line=5864 msg="Find an existing session, id-0000fe65, original direction"
2022-01-09 22:20:51 id=20085 trace_id=1003 func=npu_handle_session44 line=1161 msg="Trying to offloading session from port2 to VPN, skb.npu_flag=00000400 ses.state=00010204 ses.npu_state=0x00000000"
2022-01-09 22:20:51 id=20085 trace_id=1003 func=fw_forward_dirty_handler line=396 msg="state=00010204, state2=00000001, npu_state=00000000"
2022-01-09 22:20:51 id=20085 trace_id=1003 func=ipsecdev_hard_start_xmit line=625 msg="enter IPSec interface VPN"
2022-01-09 22:20:51 id=20085 trace_id=1003 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel VPN"
2022-01-09 22:20:51 id=20085 trace_id=1003 func=esp_output4 line=867 msg="IPsec encrypt/auth"
2022-01-09 22:20:51 id=20085 trace_id=1003 func=ipsec_output_finish line=546 msg="send to 10.0.0.1 via intf-port1"
2022-01-09 22:20:56 id=20085 trace_id=1004 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 10.0.1.41:1->X.Y.W.Z:2048) from port2. type=8, code=0, id=1, seq=31329."
2022-01-09 22:20:56 id=20085 trace_id=1004 func=resolve_ip_tuple_fast line=5864 msg="Find an existing session, id-0000fe65, original direction"
2022-01-09 22:20:56 id=20085 trace_id=1004 func=npu_handle_session44 line=1161 msg="Trying to offloading session from port2 to VPN, skb.npu_flag=00000400 ses.state=00010204 ses.npu_state=0x00000000"
2022-01-09 22:20:56 id=20085 trace_id=1004 func=fw_forward_dirty_handler line=396 msg="state=00010204, state2=00000001, npu_state=00000000"
2022-01-09 22:20:56 id=20085 trace_id=1004 func=ipsecdev_hard_start_xmit line=625 msg="enter IPSec interface VPN"
2022-01-09 22:20:56 id=20085 trace_id=1004 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel VPN"
2022-01-09 22:20:56 id=20085 trace_id=1004 func=esp_output4 line=867 msg="IPsec encrypt/auth"
2022-01-09 22:20:56 id=20085 trace_id=1004 func=ipsec_output_finish line=546 msg="send to 10.0.0.1 via intf-port1"

[Toshi_Esumi]

It's showing only one way: AWS->600C. Nothing is coming back. Whatever the problem is you can't know until your customer runs the same debug on their end as syadav says.

Toshi

[AlexC-FTNT]

if the tunnel is showing up on both FG and AWS FG, make sure the routing is correct for return traffic on customer FortiGate and that correct policies are in place:

- get router info routing table detail 10.0.1.41 (this should point only to the tunnel)

- check if policy exists to allow ICMP from 10.0.1.41 to XYWZ network

- check debug flow next