question for troubleshooting experts ;-)

[Sylvia]

Hi there,

I am wondering if anybody has an idea how to troubleshoot ARP problems...

[ul]

We have a dialup IPsec VPN, the vpn client is getting a virtual IP (eg. 10.10.10.50).

Now the clients pings somebody within an internal routed network (eg. 172.16.10.10, reachable through an internal router (10.10.10.200)).

Echo request is ok, echo reply come back to the internal router.

Now the router is searching for 10.10.10.50 and broadcasts an ARP request for 10.10.10.50 - but the firewall is not answering this ARP request...[/ul]

Normally this setup is not a problem - but I have one installation where the firewall behaves as described. I suspect there is something wrong within the configuration (big one, 34000 lines) and I do not want to build it up from scratch.

So are there any clever debugging commands - something like a "diag deb flow" for the ARP protocol? To get a hint what might be wrong?

Cheers,

Sylvia

[Toshi_Esumi]

If the route's subnet is 10.10.10.0/24, it wouldn't work. You should change the IP address range for VPNs to different subnet.

[ede_pfau]

hi,

well, it can be set up to work, even if the VPN client uses an IP address from the subnet's range it's connecting to.

The FGT needs to provide proxy arp on behalf of the remote client as the server on the LAN assumes it can reach the remote client locally, using arp to get the MAC address.

From this KB article: http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=11060

"Using proxy-ARP for VPN dial-in FortiClients"

"A remote VPN user can now be configured to use an IP address within the same subnet that he is attempting to connect to. This requires that the main FortiGate unit perform proxy-ARP responses on behalf of these remote dial-in clients"

This was introduced in FOS v2.80MR5 (remember? Oct 2009).

The point is: the client's IP needs to be issued by DHCP (DHCP-over-IPsec) so that the FGT can create an entry in the internal proxy table when the remote client connects. If you just configure the client with a fixed address the FGT will not proxy arp for it.

[Sylvia]

Hi ede_pfau,

good answer, I totally agree :)

I think that this (using the same subnet for virtual client IP and internal network) is working with Mode Config as well - at least it works in several of my installations.

I assume that Mode Config is not mentioned in the KB article because the article has been published before Mode Config was implemented in ForitOS.

Now the question is: how to troubleshoot/verify the internal proxy arp table to make sure that the entry is there?

Cheers,

Sylvia

[ede_pfau]

As you mention yourself, that table is 'internal'...I have no clue how to get this onscreen. But support should know it. I'd open a ticket with support in parallel to this post and hope they come up with a helpful answer.

'diag deb app dhcps' as mentioned in the KB article is a start if you use DHCP-over-IPsec. For mode config, not so much.

You can always resort to 'diag sniffer packet any 'arp and host x.y.z.a' 6 0 l' to get the realtime traffic. arp has to mentioned explicitely here in order to see it.

You probably have already checked one of the working configs with this one - no differences at all? Rebooted the FGT? Different Windows config, like local firewall?

[ede_pfau]

Picking up @Toshi's post...you might consider using a separate subnet for the client and NAT it to the internal interface in the policy 'VPN to internal'. Just to get the routing / arping part straight. Sure, a workaround and not a solution, YMMV.

[ede_pfau]

As you mention yourself, that table is 'internal'...I have no clue how to get this onscreen. But support should know it. I'd open a ticket with support in parallel to this post and hope they come up with a helpful answer.

'diag deb app dhcps' as mentioned in the KB article is a start if you use DHCP-over-IPsec. For mode config, not so much.

You can always resort to 'diag sniffer packet any 'arp and host x.y.z.a' 6 0 l' to get the realtime traffic. arp has to mentioned explicitely here in order to see it.

You probably have already checked one of the working configs with this one - no differences at all? Rebooted the FGT? Different Windows config, like local firewall?