Unable to Ping fortigate across ipsec tunnel

[Westcana]

I have an IPSec tunnel established between two Fortigate 50e's. One is at our head office and the other at a branch site. The tunnel has been up for several weeks and traffic crosses the tunnel fine. Clients on one side are able to ping clients on the other network, or the firewall on the other side without issue. 

I discovered that, from one of the firewalls, I can't ping the firewall on the other side. In fact I can't ping any device on the other network. Clients on either side can ping the other side without issue.

I'm thinking this has to be a routing issue. However I would think that the route that successfully moves traffic from the local network across to VPN tunnel to the other side would apply to the fortigate itself as well as devices on the connected networks.

ANy suggestions?

Thanks everyone!

[Toshi_Esumi]

It's about the source IP when you ping from the FGT and if your setting (phase2-selectors, routes, policies) on both sides is proper to allow the ping request and reply packets for both directions.

By default ping packets from an FGT over a VPN picks up the VPN interface IP you configured. If you're not sure what you configured, check it with CLI below:

  # show system interface "PHASE1_NAME"

  config system interface

      edit "PHASE1_NAME"

        set vdom "root"         set ip X.X.X.X 255.255.255.255         set allowaccess ping https ssh snmp         set type tunnel         set remote-ip Y.Y.Y.Y 255.255.255.255         set snmp-index ZZ         set interface "INTERFACE_NAME"     next end

The source IP for your pinging is X.X.X.X. You need to set the tunnel environment properly to let it go/come through the tunnel.

Alternatively, you can always specify the ping source IP with:

  # execute ping-options source "LAN_INTERFACE_IP"

So that you can ping from the user subnet, which is working.

[Westcana]

So currently the IP is showing as 0.0.0.0 255.255.255.255.

Do I change that to the IP address of the lan interface (192.168.60.1)?

If I make that change, will that affect all communication from the fortigate across the tunnel?

The reason this comes up is because I'm trying to get the DNS service running on the branch office to slave to the active directory dns server at the head office. It appears that the fortigate at the remote office can't reach the dns server on the head office network.

[Toshi_Esumi]

I would do that kind of change in a maintenance window. Because remote-IP changes on the other end. You need to change the set; local IP and remote-IP on both ends at the same time.

For a best practice, don't use any IP in existing subnets. Pick a /30 subnet in RFC 1918 range, which doesn't exist on either side. Let's say 10.10.10.0/30. Then assign 10.10.10.1 on one end and 10.10.10.2 on the other end. When you configure it on the tunnel interface, as you saw already, subnet mast is supposed to be 255.255.255.255. Then you need to adjust those IPsec environment to allow it to reach the destination (DNS server) subnet.

[Westcana]

Why is it not possible to just allow the remote fortigate to communicate across the existing tunnel to the local network?

The tunnel already passes traffic for all ip's on both networks, except from the fortigate's themselves.

The method you specify above seems unnecessarily complex. I'm sure that there are other fortigate users out there that have branch offices that need to lookup to the main office active directory dns. Do they all have to use the method that you outline above?

[Toshi_Esumi]

If you don't configure a tunnel IP, I'm not sure what IP address the DNS request packet picks up as the source. Have you try sniffing what the source IP in those packet? There might be a way to specify the source IP manually for the DNS request. But I don't know it.

This way is the base of interface mode/route-base IPsec tunnel set up, including any L3 routers not only FWs. I agree that there is a way to do it even with a policy-based IPsec. You can wait other members inputs, or open a ticket with TAC to ask.

[Westcana]

It looks like the fortigate that is running the dns server is forwarding the dns query out the wan interface, instead of across the tunnel. I have the dns server on the fortigate configured to slave the dns for the ad domain to the ip of the dns server at the head office.

It's almost as though the dns server on the fortigate is not attempting to reach the dns server specified in the config, but is using the dns settings from the fortigate it's self.

Or perhaps since the fortigate doesn't know that the IP for the master is across the tunnel so is using the default route? The destination for the dns query is a root server.

[Toshi_Esumi]

I'm wondering if you really configured an interface-mode IPSec, and you actually have a route in the routing table for the AD server's subnet.

[sw2090]

The question I ask myself here is which IP soes the FGT itself use when it tries to ping the opposite FGT?

The Tunnel Interface itself does not have an IP.

So when pase2 id is set to 0.0.0.0/255.255.255.255 all traffic that matches policies will be allowed but what happens to traffic coming form the FGT itself?

is that using the loopback interface 127.0.0.1 or something like that? That would then explain it as that don't match any policy...

[Westcana]

Both networks can reach each other just fine. I already have clients at the remote office using drive mappings on the file servers at the main office. I am also able to RDP into clients on the remote office network from the head office.

The problem is that everything has to be done with IP's.  Without AD DNS, I'm going to have problems if I start deploying AD windows desktops at the remote offices.

I'm using this document as a reference setting this up.

https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/960561/fortigate-dns-server Also, I have the AD DNS server configured to allow zone transfers.

I have a fortigate 60e on the head office network and it's working fine looking up the the AD dns server using this config. I just can't get the branch office working and it appears to be that the FGT at the branch office can't reach the main office network.

Perhaps I need to create a static route or a policy route for the FGT ip to the tunnel?

It is a good question about what IP the FGT uses when it tries to do the DNS lookup. I would assume it would use the IP on the lan network, but as I think of it, the system DNS lookup goes to the wan dns server. However this is the same config on the FGT on the head office network and it looks up without issue. But then the IP it is looking up to is a locally attached network.

In any case, you can't ping any of the branch offices FGT from the main office FGT. Devices within each of the networks can reach each other, it's just the gateways that can't reach each other across the tunnel.