Skip to main content
steveballantyne
steveballantyne
New Member
September 15, 2017
Solved

My ISP's cable modem is "exposing itself" between LAN workstations, and VPN destinations.

  • September 15, 2017
  • 1 reply
  • 8005 views

I have a FortiGate 61E at a remote site with a VPN tunnel back to my main site. I have had a problem where my Windows clients will detect a new network, and will identify it as "Network 3". That is, when you choose a type of Network in Windows 7, you choose from Home, Public, or Work, and then it gives the network a name. So it's almost as if the Windows machine thinks that the network has changed. This happens rather randomly throughout the day, several times a week, with different computers. Yesterday I was doing some troubleshooting and I discovered that it's selectively unable to reach *certain* networks through the VPN tunnel. If I do a traceroute, it's picking up an address of 192.168.0.1 between the local gateway (the FortiGate) and the remote end of the VPN tunnel. The packets are dropping at 192.168.0.1. I do not use this IP address anywhere in my network! Oddly enough, I can browse to this IP address, and it loads a Ubee Modem DOCSIS page. I called my ISP, Spectrum (formerly Time Warner) and asked for an explanation. They said that everything is configured properly, but agreed that I should not be able to see that page or reach that address. In fact - I don't see how it's possible. The source address was 10.2.20.153 and the gateway (the FortiGate) is 10.2.20.1. How is it able to reach 192.168.0.1?  Perhaps there is something I am doing wrong in my configuration that is allowing that address to sneak into the routing path? Or do I need to contact the ISP and demand a different make/model of modem?

    Best answer by steveballantyne

    Turns out, it was the FortiGate that was to blame for this one. Spectrum is off the hook!

     

    After battling this issue for months - I called into support and opened a new case for this issue (I believe that makes three times I have done this). Got someone new from the UK looking at the issue, and the guy was a real whiz. In the middle of explaining the issue, he knew exactly what the problem was.

     

    The gist of the issue is this: when FortiGate is sending packets via a VPN tunnel, and the tunnel is presently inaccessible (for that very brief moment in time) it will go fishing for a new route. Since the tunnel is inaccessible many times a day (cable modem glitches, it's rebuilding after a timeout, etc) there are random clients who end up with the FortiGate "browsing for a new route". It's go to route when this happens, is the WAN interface (0.0.0.0/0). The cable modem is probably making the connection that private range IP's shouldn't be headed to the Internet on their public IP address. So it's getting in the way and eating packets.

     

    The solution was very easy. It's called "blackhole routing". So you go Network > Static Routes. In there you will see some routes where the destination is your VPN taffic, and the Interface is your VPN tunnel. You simply add a new additional route where the destination is your VPN traffic, but the Interface is "Blackhole" (it's in the dropdown list). Then you set the Distance to something far out and unreachable (the tech set it to 250). FIXED!

     

    Now if the client should happen to try and hit a host at the worst possible time, the traffic dies. The retry that is occurring in the background gets things going again, and the client never skips a beat.

     

    Not sure why the first few techs didn't recognize this issue. But MEGA GOOD FEEDBACK is in order to the guy that caught it.  ;)

     

     

    1 reply

    rwpatterson
    rwpatterson
    New Member
    September 15, 2017

    Welcome to the forums.

     

    Do you have static IP addresses with Specturm or dynamic? If dynamic, I would set the cable modem in bridge mode. This would make the Fortigate the edge device. I'm not a fan of TW/Spectrum at all.

    steveballantyne
    steveballantyneAuthor
    New Member
    September 15, 2017

    rwpatterson wrote:
    If dynamic, I would set the cable modem in bridge mode.

     

    Funny you should say that. We always put in our own firewall, ask for a static IP address, and request that the cable modem be put in bridged mode. But as much as I tried, I couldn't get the tech on the phone to say *bridged mode* ("say car Ramrod"). So I don't know if maybe they don't call it that any more, or they just don't like saying it? He did offer to blank out the modem and reconfig it from scratch. I am not opposed to doing that, but generally speaking - rebuilding a device the same exact way gives you the same exact results.  :)

     

    rwpatterson wrote:
    I'm not a fan of TW/Spectrum at all.

     

    SAME! Sadly, our options in this area are very limited. It's the lesser of the *TWO* evils. The other evil being the local telco's DSL (which is absolute unreliable garbage)!

    steveballantyne
    steveballantyneAuthorAnswer
    New Member
    October 13, 2017

    Turns out, it was the FortiGate that was to blame for this one. Spectrum is off the hook!

     

    After battling this issue for months - I called into support and opened a new case for this issue (I believe that makes three times I have done this). Got someone new from the UK looking at the issue, and the guy was a real whiz. In the middle of explaining the issue, he knew exactly what the problem was.

     

    The gist of the issue is this: when FortiGate is sending packets via a VPN tunnel, and the tunnel is presently inaccessible (for that very brief moment in time) it will go fishing for a new route. Since the tunnel is inaccessible many times a day (cable modem glitches, it's rebuilding after a timeout, etc) there are random clients who end up with the FortiGate "browsing for a new route". It's go to route when this happens, is the WAN interface (0.0.0.0/0). The cable modem is probably making the connection that private range IP's shouldn't be headed to the Internet on their public IP address. So it's getting in the way and eating packets.

     

    The solution was very easy. It's called "blackhole routing". So you go Network > Static Routes. In there you will see some routes where the destination is your VPN taffic, and the Interface is your VPN tunnel. You simply add a new additional route where the destination is your VPN traffic, but the Interface is "Blackhole" (it's in the dropdown list). Then you set the Distance to something far out and unreachable (the tech set it to 250). FIXED!

     

    Now if the client should happen to try and hit a host at the worst possible time, the traffic dies. The retry that is occurring in the background gets things going again, and the client never skips a beat.

     

    Not sure why the first few techs didn't recognize this issue. But MEGA GOOD FEEDBACK is in order to the guy that caught it.  ;)

     

     

    Terms & ConditionsAccessibility statement