Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
rbross
New Contributor

Bizarre IPSec routing issue

I have 2 Fortinet 30e firewalls connecting 2 sites via IPSec VPN.   It's always worked great.  One subnet is 192.168.0.0/24 and the other is 192.168.2.0/24.

 

As I said - no problems for months, now suddenly, from the 192.168.0.0/24 subnet I can ping some hosts on 192.168.2.0/24 but not others.  If I ssh into a remote host that responds, I can ping hosts on the local network that don't respond over the VPN connection.

 

I'm at a bit of a loss.  Has anyone ever experienced something like this?  

5 REPLIES 5
m0j0
New Contributor III

Probably need a bit more information to be able to help. 

a) Can you run a packet capture on the inside interface of you 192.168.2.0/24 firewall to see if the packets are exiting that firewall.

b) If they are, does a packet capture on this same interface see returning packets.

c) If yes to 'a' and no to 'b' can you run a tcpdump/wireshark capture on the target machine to see what it's doing with this traffic.

d) Do the working and non-working targets have the same gateway set? 

e) Check the subnet mask on the non-working targets.  Are they definitely set to /24?  If they've been set to something like /22 or /16 then that would explain the behaviour you're seeing.  Are these machines getting their IP from DHCP?  If so, maybe someone has introduced a rogue DHCP server onto the network that has the incorrect subnet mask.

 

There could be many other reasons, but this is a start.

ede_pfau
Esteemed Contributor III

I'd suspect either you have 2 WAN lines, or the subnet mask settings (somewhere) are incorrect.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
rbross

Ok, not time this morning for packet capture, but:

 

1) To start with for context, all machines are Linux

2) There is only a single WAN at each endpoint

3) Pinging the other end using the CLI on the Fortinets provides the same results as from the machines themselves.

4) The Linux machines (Debian or Ubuntu server) all use static IPs and the /etc/network/interfaces configs are identical (except for the "address" of course) - see below.

5) The gateways are set to the Fortinets - 192.168.0.1 at one end and 192.168.2.1 at the other.

 

auto eth0     iface eth0 inet static      address 192.168.2.29     netmask 255.255.255.0     gateway 192.168.2.1

 

Ricardo_Tomas
New Contributor III

Wild guess

Check routes, if you have some type of dynamic routing protocol (BGP OSPF RIP) you may being route poisoned with a sub net. 

Other thing you can do it's create another local network and see if you can ping locally between networks

 

rbross

Solved.  It wasn't even as complex as dynamic routing.  There had been a power outage and 2 machines weren't responding.  One I had determined didn't come back up properly (still looking into the issue).

 

The one that was responding locally is running Debian Stretch.  Although the "/etc/network/interfaces.d/eth0" file was absolutely correct, the routing table showed a default gateway of 0.0.0.0.

I ensured that NetworkManager was not managing the interface, and that there were not other conflicts.

 

For now I simply set the gateway in the routing table manually (and persistently) and it's working fine.  Finding the root cause will have to wait until I an onsite.  The local DHCP server is down.  Basically, I think that for some reason although the IP is being set correctly and statically, the gateway and DNS settings need the DHCP server, since it works fine when they're up.

 

Labels
Top Kudoed Authors