Fortigate 80C and I lost VPN capability for SSH and Web

[JBruyet]

Hey all, in the past I've been able to VPN into work from home and SSH to my Linux servers and access my web-based programs but not any more -- when I try to access these things the connection times out.  I haven't had to do anything like this for a while so I'm not sure when I lost this capability. I can still RDP into my Windows servers and workstations without any problems so I'm guessing it's configuration issue but no one has touched it - it's behind a locked door with badge access only. The guy who was in charge of the FortiGate 80C has moved on so now it's my responsibility to get it working again. Any ideas on what would have changed and how to get that access restored? I'm not sure where I should even start looking. I was going to start by power-cycling the FortiGate but I was told that power-cycling it could introduce new issues so I'm holding off on that.

Thanks,

Joe B

[ede_pfau]

hi,

sounds funny.

I assume your side (the client's) is via software VPN client.

So the only place you have to check are:

- on the HQ FGT the policy from tunnel to internal (i.e. the interface your servers are connected to), especially the 'service' entry

- whether there are VIPs defined, and if so, if they could interfere with the port used (std is 22 but that may be any)

Visual inspection of the policy ruling the traffic from tunnel to LAN should suffice to spot the misconfig. If that doesn't help you can always diagnose the traffic flow (diag deb flow ...) as described here in the forums a hundred times (search for "debug flow" and "emnoc" :)

But I'd start with the easier part.

[JBruyet]

Hi ede_pfau,

- on the HQ FGT the policy from tunnel to internal (i.e. the interface your servers are connected to), especially the 'service' entry

[ul]

I found 17 entries, Policy Objects > Policy > IPv4, & every entry’s “service” field says ALL

Also, Policy & Objects > Objects > addresses, the Pptp address shows a Subnet / IP Range of x.x.x.120-x.x.x.121. Those addresses are for two hosts in my VMware cluster. What’s up with that???[/ul]

- whether there are VIPs defined, and if so, if they could interfere with the port used (std is 22 but that may be any)

[ul]

I found Policy & Objects > Virtual IPs but these are just standard port forwarding configurations [/ul]

But I'd start with the easier part.

Well, I guess I'm going to have to go to the next level because I didn't see anything here that would help me. The comment about "Visual inspection of the policy ruling the traffic from tunnel to LAN should suffice to spot the misconfig" wasn't very much help because I don't know what to look for. I'll move on to diagnosing the traffic flow and see if I can find something there.

Thanks,

Joe B

[ede_pfau]

Joe,

sorry, no offense intended. The info about your config is so thin that I'm afraid help could be very difficult. If I interpret your last post correctly, "VPN" is not IPsec VPN nor SSL VPN but PPTP??

Crucial information like that cannot be left out if you expect substantial help.

My remark about a glance over the policy table is quite serious and, as I see now, feasable. It's not 17 policies that you need to check but the one or two which rule the traffic flow between the tunnel and your LAN. From that summary statement you made I assume that you're very fresh with FortiOS and in need of the basics: how traffic flow is structured, how policies are made and in which sequence, the different kinds of VPN etc. etc.

Of course you can take the shortcut and debug something. Without some basic understanding of FortiOS it probably won't tell you much. And without a (more) complete view of your configuration we can't tell much either. Go for it anyway.

For more background: docs.fortinet.com , esp. the Handbook (complete reference with examples), the CLI Reference, the Cookbook (most common example "recipes"). And of course the Knowledge Base (kb.fortinet.com).

[rwpatterson]

Also, with regard to your power cycle comment, how long has this box been running since last reboot? If over a year, I would gracefully power cycle it AFTER making a complete backup to quell the worries of those that think you will introduce more problems. Unless you have a hardware issue (and I seriously doubt you do), a power cycle is usually a very good thing, on occasion.

My two cents

[JBruyet]

Ede,

sorry, no offense intended.

No worries; none taken. Like I said the guy that was handling our Fortigate devices is no longer here and it has fallen to me to get this figured out and working.

The info about your config is so thin that I'm afraid help could be very difficult. If I interpret your last post correctly, "VPN" is not IPsec VPN nor SSL VPN but PPTP?? Crucial information like that cannot be left out if you expect substantial help.

I'm afraid I'm not sure what "crucial" information you need about my config. I went back to confirm the PPtP option and found it in the ssl.root (sslvpn tunnel interface) - Subnet2 policy.

My remark about a glance over the policy table is quite serious and, as I see now, feasible. It's not 17 policies that you need to check but the one or two which rule the traffic flow between the tunnel and your LAN.

I hope this isn't overkill but here are the 17 policy names:

CSVPN - Subnet1 <-- Static vpn to our remote facility

CSVPN - Subnet2 <-- Static vpn to our remote facility

Guest Network - wan1 <-- Provides wifi to non-business personnel (webinar attendees, meeting attendees, etc.)

Subnet1 - CSVPN <-- First production subnet connection to remote facility

Subnet1 - Subnet2 <-- First production subnet to second production subnet

Subnet1 - Name <-- First production subnet to, I believe, an interface named after the previous guy

Subnet1 - wan1 <-- First production subnet to, I believe, the internet

Subnet2 - CSVPN <-- Like the previous Subnet1 group

Subnet2 - Subnet1 <-- Like the previous Subnet1 group

Subnet2 - Name <-- Like the previous Subnet1 group

Subnet2 - wan1 <-- Like the previous Subnet1 group

ssl.root (sslvpn tunner interface) -Subnet2 <-- I'm guessing THIS is the policy that rules them all

name - Subnet1 <-- Previous guy's name to Subnet1

name - Subnet2 <-- Previous guy's name to Subnet2

wan1 - Subnet1 <-- Internet to Subnet1?

wan1 - Subnet2 <-- Internet to Subnet2?

Implicit - I'm guessing this means everything that isn't explicitly allowed is denied

From that summary statement you made I assume that you're very fresh with FortiOS and in need of the basics: how traffic flow is structured, how policies are made and in which sequence, the different kinds of VPN etc. etc.

LOL, yeah if I'm going to take this over I'm going to have to throw it onto the heap with SQL, VMware, Server 2012R2, Exchange and anything else that pops up.

  Of course you can take the shortcut and debug something. Without some basic understanding of FortiOS it probably won't tell you much. And without a (more) complete view of your configuration we can't tell much either. Go for it anyway. I'll give that a shot. I know that looking through log files usually can't break anything. 

For more background: docs.fortinet.com , esp. the Handbook (complete reference with examples), the CLI Reference, the Cookbook (most common example "recipes"). And of course the Knowledge Base (kb.fortinet.com).

Thanks for your help Ebe. One thing that makes me uncomfortable is that Name, the previous guy, didn't leave on his own; he was let go. I changed passwords just in case he had any malicious moments. And the 10.0.0.1 and .2 have me wondering why they would be there. We don't have anything here in either of those IP ranges. I think this Fortigate/FortiOS project is percolating up the stack.

Thanks again,

Joe B

[JBruyet]

Thanks rwpatterson, I'll probably do that this weekend when everyone is gone. Some of the locals get a little aggressive when their connection to what they were working on drops.

Thanks,

Joe B

[rwpatterson]

JBruyet wrote:

And the 10.0.0.1 and .2 have me wondering why they would be there. We don't have anything here in either of those IP ranges. I think this Fortigate/FortiOS project is percolating up the stack.

When delivered from the factory, 10.0.0.1 is the default IP on one of the interfaces. Which one, I can't recall.

Looking into the quick start guide here (http://docs.fortinet.com/uploaded/files/833/FortiGate-80C-LENC-QuickStart.pdf), I see the DMZ IP has been left out. My guess is that's the one. I recall it being in there, and it's not a scheme I use either. (I have seen it on all of the boxes I set up in the not too recent past)

Correction: No worries. Looking through old configs: 10.0.0.1-10.0.0.10 is the IP range for the SSL VPN clients on the firewall.

[ede_pfau]

Joe,

thanks for taking the time to answer so throughly and quick.

Actually, I've got the feeling that you should call in a Fortinet partner and have this set straight. For an experienced professional refactoring the configuration would probably take 1-2 hours, things would be settled afterwards, data flows documented and security concerns addressed. If you were located somewhere in Germany I'd come around (in a few days, that is)...but maybe there is a fellow FTNT pro in your vicinity.

Just my 2 cents.

Some more hints intended to help you clarify this:

1. Non-generic interface names like "Name" ("Dick", "Tom", "Harry") can only be created for

[ul]

IPsec VPN (phase1)

VLAN

zones (comprising multiple physical ports)

SSID (WiFi)[/ul]

Of these, I suspect an IPsec VPN to Name's home. You can look up interfaces in System > Network > Interfaces. VPNs will be labeled "tunnel", likewise VLANs and SSID.

Look up IPsec VPNs in VPN > IPsec > Tunnels. To disable, either change the Pre-shared Key (in phase1), or disable the ruling policy.

2. You are right, "wan1" is commonly connected to a modem or router for internet access. Note that with FGTs port names do not convey any special features - you can use any port for any task. Port names are pre-assigned for convenience.

3. I see that one can reach Subnet2 via the SSL-VPN. If the servers you try to connect to are not in Subnet2 but in Subnet1, create a new policy from 'ssl.root' to 'Subnet1' with identical settings.

4. A reboot is nowhere 'dangerous' if done properly. I recommend rebooting from the WebGUI (pulling the plug is never a good idea with electronic gear). Downtime with a FG-80C will be around 2 minutes. Generally one should not wait until internal memory leaks have eaten so much of the (limited) RAM of the FGT that a reboot won't be possible, and, there's been a bug around kicking in after 497 days (convert that into seconds...). So regular reboots every couple of months is good practice.

5. Just curious: the remote location has access to both production LANs, but Subnet2 does not have access to Subnet1 locally. Probably nobody asked for this before...

6. All policies with "wan1" as Destination Interface need to have the NAT box checked.

If the reason for not being able to connect to servers is not in the policies then it could be the routing. Can you provide the routing table (System > Network > Routing > Monitor)? Just mask the external public IPs and leave the internal ones intact before posting.

Please provide the version of FortiOS that is in use (from the GUI, "Status" widget) next time. And how do you VPN into the company, do you use the Forticlient, and if so, for SSL-VPN or IPsec VPN? Does your version of FC match the FGT's version of FortiOS (at least somewhat)?

[JBruyet]

Hi Ede,

[ol]

My manager and I suspected this but didn't want to believe it. I hope he wasn't helping himself to our software inventory and license keys.

I was pretty sure but thanks for confirming that.

I can do this but I'd like to know why it changed. Previously I had access to all computers/servers/switches with RDP/SSH/Telnet/Web-based GUI interfaces.

I've looked for the Web GUI but haven't found it anywhere I've looked. I thought it would be under Dashboard > Status > Information but no joy. I even Googled it and didn't get anything useful back.

Subnet 1 and Subnet 2 both have access to each other locally. If there were any connectivity problems between 1 and 2 I'd be screamin' and scramblin' to get it working. Which would be tough because I'm not a router guy.

All connections with a wan1 destination have the NAT box checked.[/ol]

I'll look for a Forti-competent tech that's close by and see what it would cost to get these annoyances taken care of.

Thanks for your time,

Joe B