Skip to main content
NickBurns
NickBurns
Visitor III
August 21, 2019
Question

Configure FortiAnalyzer over IPSEC with NAT

  • August 21, 2019
  • 1 reply
  • 5836 views

I have a situation trying to get a branch FortiGate to send logs to FortiAnalyzer behind a hub FortiGate across an IPsec tunnel.  Setting the system 'source-ip' of the branch FortiGate doesn't resolve the problem in this particular case due to some unavoidable, additional complexity.

 

FortiAnalyzer (10.1.1.10) ---

LAN (10.1.1.0/24) --- Hub FortiGate (Ins. 10.1.1.1, Outs. 1.2.3.4)

((( --- IPsec VPN TUNNEL ---)))

Branch FortiGate (Outs. 5.6.7.8, Ins. 172.20.0.1) --- LAN (172.20.0.0/24)

 

The complexity is that I am required to translate the Branch LAN IPs from 172.20.0.0/24 to 172.10.0.0/24.  All traffic sent from the Hub LAN to the Branch LAN is destined for 172.10.0.x and is translated by the Branch FortiGate to 172.20.0.x with DNAT.  All traffic sent from the Branch LAN to the Hub LAN is destined for 10.1.1.x and appears to be sent by 172.10.0.x (not 172.20.0.x).

 

The translations work correctly and in both directions.  The problem is getting the Branch FortiGate (172.20.0.1) to talk to FortAnalyzer (10.1.1.10).  I have set the internal 'source-ip' for FortiAnalyzer on the Branch FortiGate to 172.20.0.1 - works on my other FortiGates NOT USING NAT, but doesn't work here.  All pings fail from CLI to 10.1.1.0/24.  I have tried setting it to 172.10.0.1, but the change results in a CLI error.  I can access the Branch FortiGate's GUI at 172.10.0.1 from 10.1.1.0/24, so the DNAT config is doing its job there.

 

How do I get the system 'source-ip' to use the NAT config I have in place?

(Removing NAT is not an option).

 

(On an additional note, I've also found that SNMP requests from the HUB's LAN are failing to reach the Branch's LAN over the VPN tunnel.  SSH and ICMP work fine between the LANs, and my policies allow any/all services across the VPN tunnel.  Not sure if this is related, or a completely separate problem.)

    1 reply

    orani
    orani
    New Member
    August 22, 2019

    Did you set the proper routing for those subnets on both sides?

    NickBurns
    NickBurnsAuthor
    Visitor III
    August 22, 2019

    I assume so, but not sure if there are extra routes/settings that I'm not familiar with for having to use NAT.

    - I have a route on the Branch FortiGate with Destination 10.1.1.0/24 on the IPsec VPN interface.

    - I have a route on the Hub FortiGate with Destination 172.10.0.0/24 (the NAT'd LAN) on the IPsec VPN interface.

    Again, traffic between clients on these LANs is flowing bi-directionally with no issues.  The only issue is the ability of the Branch FortiGate device itself talking to anything on 10.1.1.0/24.

     

    I have experienced the same issue without NAT in play, and the solution in that case was to simply specify the 'source-ip' setting for the log/FortiAnalyzer.  Not working in this case though.

     

    NickBurns
    NickBurnsAuthor
    Visitor III
    September 5, 2019

    I've been running debug traces on the traffic from the Branch FortiGate to the FortiAnalyzer and found the following results:

    # id=20085 trace_id=718 func=print_pkt_detail line=5430 msg="vd-root:0 received a packet(proto=17, 172.20.0.1:2290->10.1.1.10:514) from local. " id=20085 trace_id=718 func=resolve_ip_tuple_fast line=5510 msg="Find an existing session, id-0072d16a, original direction" id=20085 trace_id=718 func=ipsecdev_hard_start_xmit line=759 msg="enter IPsec interface-VPN_to_HUB" id=20085 trace_id=718 func=ipsec_common_output4 line=802 msg="No matching IPsec selector, drop"

     

    It is being dropped because my Phase 2 Selector uses the NAT'd subnet of 172.10.0.0/24, and the traffic coming from the device is not being NAT'd from 172.20.0.1 to 172.10.0.1.

     

    Using a different device on the LAN network, the traffic flows over the VPN correctly:

    id=20085 trace_id=1022 func=print_pkt_detail line=5430 msg="vd-root:0 received a packet(proto=1, 172.20.0.7:2->10.1.1.10:2048) from lan. type=8, code=0, id=2, seq=4." id=20085 trace_id=1022 func=resolve_ip_tuple_fast line=5510 msg="Find an existing session, id-007925e2, original direction" id=20085 trace_id=1022 func=__ip_session_run_tuple line=3234 msg="SNAT 172.20.0.7->172.10.0.7:2" id=20085 trace_id=1022 func=ipsecdev_hard_start_xmit line=759 msg="enter IPsec interface-VPN_to_HUB" id=20085 trace_id=1022 func=esp_output4 line=904 msg="IPsec encrypt/auth" id=20085 trace_id=1022 func=ipsec_output_finish line=622 msg="send to 5.6.7.9 via intf-wan1"

     

    Based on these results, I believe the problem is that the firewall's traffic is being labeled as originating from the "local" interface rather than the "lan" interface, and therefore, my NAT policy does not get applied.  My NAT policy is applied to the entire subnet 172.20.0.0/24, and the lan interface.  I have also tried applying it to "any" interface - no difference.  If the firewall's source-ip and lan interface IP are both set as 172.20.0.1, then why isn't the traffic being NAT'd?  Or, what do I need to do so that my NAT policy is applied to the "local" interface?  "local" is not an option in the GUI.

    Terms & ConditionsAccessibility statement