IPsec VPNs ALWAYS route hop through mgmt interface IP address?

[Jay_Libove]

I have a FortiGate 100D, FortiOS 5.0.3, with an IPsec Aggressive mode VPN configured. A client (MacOSX with FortiClient, in this case) connects from a remote network, and gets an IP address in the configured 192.168.8.97-.119 range. (See configuration details below). The remote client performs a traceroute to ... anything, e.g. 1.2.3.4. Doesn' t matter what. The first hop is ALWAYS the IP address of the FortiGate' s mgmt interface, even though I have the FortiGate' s mgmt interface administratively down. Is this really how IPsec VPNs are supposed to work? (When I last worked with IPsec, fifteen years ago, it wasn' t this way as far as I can recall). Or, is this just yet another very nasty quirk of FortiGate? Read on for why this turned out to be very nasty for me in my specific case today. Configuration details: I created an IPsec aggressive mode VPN, as follows:

Phase 1: SPFGIPsec2 Local Interface: WAN1 (my FG100D, for the moment, is sitting inside my network' s edge router, and I have the FG' s WAN1 connected via VLAN ' directly' to the edge router, which one-to-one NAT' s a public IP address straight through to the FG' s WAN1 port). Mode: Aggressive Authentication Method: Preshared Key Peer Options: Accept any peer ID Advanced: Enable IPsec Interface Mode: checked IKE Version 1 Mode Config: checked (I still don' t understand what this does?) Start IP: 192.168.8.97 end IP: 192.168.8.119 DNS Server: Specify: 192.168.8.34 Local Gateway IP: (I' ve tried it both ways, with the default " Main Interface IP" and explicitly " Specify: 192.168.8.35; it makes no difference to my question below) P1 Proposal - defaults Xauth: Enable as Server, Server Type Auto, User Group ipsecvpn, NAT Traversal enable. Phase 2: SPFGIPsec2b Phase 1: SPFGIPsec2 Advanced: P2 Proposal - defaults Quick Mode Selector - defaults (blanks/zeroes)

It caused me a huge loss of time, because I' d (stupidly?) assumed that, being both physically (no cable) and administratively (in the FG UI) down, it couldn' t be involved in any way. But the mgmt interface had the FortiGate factory default IP address 192.168.1.99/24, which happens to be smack in the middle of my internal LAN' s IP address space ... and that IP address was the last hop I saw on traceroutes through the VPN, which were dying right there; no connections would flow into the LAN through the VPN. (Connections bouncing off the FortiGate IPsec VPN - it' s NOT in split-tunnel mode - to the Internet would work fine). Made no sense at all. Sent me on a wild goose chase after the real 192.168.1.99 on my LAN (which has no fault at all). When I finally tried reconfiguring the mgmt' s IP address to something totally different (10.249.129.248/24), I still see the mgmt interface in all traceroutes which come in over the IPsec VPN but now I can reach nodes on my internal LAN through the IPsec VPN, which before always got stopped at that fake 192.168.1.99 address. Why? What purpose does it serve to have this FortiGate mgmt interface in the middle of IPsec connections? Thank you, -Jay

[rwpatterson]

I don' t have an answer for you, but a rhetorical question: Why is your LAN still in the 192.168.1.x/24 IP space? This won' t be the last problem you run into over your administrative tenure.... CHANGE THAT! My two cents.

[emnoc]

ditto And are you sure that 192.168.1.99 is NOT something inside your local pan? 1st I would address the 1st issue, get out of the 192.168.1.0/24 lan segment 2nd issues, remove the address off the management interface Then run diag debug flow and validate what it' s matching, what it' s hitting and which interface.

[Mr_Kaftan]

It is not related to the 192.168.1.0 numbering.  I am seeing this too and our network is 10.x.x.x.

So what I am hearing from the rest of this thread is, "Yeah it does that" don't worry about it, it might be fixed later when you upgrade.

I am trying to backup my FGT box to a tftp server across the VPN tunnel.  The source IP the packets get is 192.168.1.99 and the backup is failing.  There is no 'set source-ip' option for the auto backup so I am stuck.  I opened a ticket with them.  We shall see.

[Rick_H]

The 100Ds I used to manage were running 4.3.x and I never saw this particular behavior. This sounds like a bug in the way the FortiGate is reporting the hop information or perhaps in the internal routing engine. Do you see any other addresses in your traceroute output that belong to the FortiGate? What happens when you denumber the MGMT interface as emnoc suggested? If you have VDOMs enabled what happens if you move the MGMT interface to a separate VDOM?

[Jay_Libove]

Hi, several replies, Bob, I inherited the network. Changing the whole IP address range is simply not high on my priority list right now. Nor, given the realities of how we work, are collisions anything but rare-to-nonexistent (we have almost nothing hosted internally - mostly the VPN is so we can access things on the Internet " from" the office LAN' s static Internet IP addresses), despite the very common reality of home networks overlapping this range. And although it would be a better practice to get off the 192 range, it' s simply not relevant to the problem at hand. emnoc, I did get the Mgmt interface off of the 192.168.x.x space, and that resolved the problem of packets simply blackholing. But it doesn' t answer the question about why that Mgmt interface should be in the trace at all. Rick, the Mgmt interface' s IP address shows up in the traceroute output run on a client. So it' s not just a display bug on the FortiGate, that IP address really is appearing as a network hop. I just realized that I hadn' t yet tried denumbering the Mgmt interface entirely. I' d tried leaving the field blank, but the FortiGate won' t accept that. I hadn' t gone back to look at this since I learned that the way to put NO address on a FortiGate interface is to put 0.0.0.0/0.0.0.0 (just another undocumented FortiGate quirk). Indeed, setting up the Mgmt interface with 0.0.0.0/0.0.0.0 causes traceroutes to show the proper exiting interface' s IP address, rather than an IP address of the Mgmt interface. Clearly, this is more than just show - and I assert that it is a bug or design flaw in the FortiGate, since it caused packets to blackhole. So, work-around found, but I' m still curious why the FortiGate insists on putting the Mgmt interface in the path, when it has no purpose being there. And for FortiGate to fix that, so it doesn' t cause future users a similar problem.

[PIDDLAW]

I believe this is a known issue. We asked about it with our 100D. There is syntax for traceroute to use a specific interface (do not remember it offhand) but we always get the extra management hop on ours.

[Jay_Libove]

Thanks PIDDLAW. I' m pretty sure that the traceroute option to choose a specific interface (PING has it also) only applies to the initial sending machine. Since the FortiGate is somewhere in the middle, the client could have no control over that. Does FortiNet monitor these forums? I guess not. I' ve opened a support case for this issue, pointing to this forum thread. -Jay

[Rewanta_FTNT]

Hi, As you have the tunnel-all mode(no split-tunnel) one of the ip address from FGt will act as the hop in the traceroute, you are sending all the traffic to FGT first then it decides based on the dst addr where to send the traffic. its not obvious here why mgmt address appears as the next hop when interface is down. this could be known/unknow bug. HTH.

[Jay_Libove]

I did get a technical answer from FortiNet, although they refuse to demonstrate that the situation which PIDDLAW and I have both encountered has been worked out of newer firmware versions. The technical answer is that the interface with the lowest configuration index (diagnose netlink interface list) will win, if more than one interface would be valid to reach the route next hop. What they left unanswered is why the FortiGate permitted (under FortiOS 5.0.2) two interfaces to have overlapping subnets. In 5.0.4 both the GUI and the CLI prohibit creating this situation, but enough time and changes have gone by that I can' t swear that you couldn' t re-create this situation out of the box.